10 האיומים המובילים על אפליקציות אינטרנט ב-OWASP

מוצג התיעוד של Apigee Edge.
נכנסים למסמכי התיעוד של Apigee X. מידע

במסמך הזה מתוארות גישות שונות שניתן להשתמש בהן ב-Apigee כדי לטפל בנקודות חולשה באבטחה שמזוהות על ידי OWASP. למידע על גישות נוספות שתועדו לגבי Apigee, ראו אפשרויות המיטיגציה המובילות של OWASP לשנת 2021 ב-Google Cloud.

סקירה כללית

סביבות עסקיות של API חווים התקפות שונות מצד לקוחות חיצוניים ופנימיים. השימוש בממשקי API יוצר הזדמנויות עצומות לספקי השירות, אבל גם טמונים בו סיכוני אבטחה מסוימים. המפתחים צריכים להיות מודעים לאתגרים האלה ולטפל בהם כשהם יוצרים ממשקי API ומשתמשים בהם.

OWASP היא קהילה פתוחה שמטרתה לעזור לארגונים לפתח, לרכוש ולתחזק אפליקציות וממשקי API מהימנים. באמצעות פרויקט אבטחת OWASP API, ארגון OWASP מפרסם את סיכוני האבטחה הקריטיים ביותר לאפליקציות אינטרנט ולממשקי API ל-REST, ומספק המלצות לטיפול בסיכונים האלה.

באמצעות Apigee, שכבת ה-API של שרת ה-API יכולה לזהות, לחסום ולדווח על בקשות API שגויות מהלקוח לפני עיבוד הבקשות במערכות הקצה העורפי, וכך לצמצם סיכונים ולהגן על השירותים שלך. בקשות בפורמט שגוי יכולות לכלול כל רכיב שמרכיבים את הפרוטוקול ברמת האפליקציה ב-HTTP:

  • כתובת URL
  • כותרות
  • נתיב
  • מטען ייעודי (payload)

בקשות API שגויות יכולות להגיע מלקוחות מוכרים או לא ידועים שפותחו על ידי מפתחים חיצוניים, מפתחים פנימיים או בוטים זדוניים. סוגי הבקשות האלה מהווים את רוב איומי OWASP, אבל יש רכיבים נוספים בשכבת ה-API הבסיסית של שרת proxy שיכולים לצמצם סיכונים, כמו אנונימיזציה של נתונים, רישום ביומן, ניהול וכו'.

הפלטפורמה החכמה של Apigee לניהול ממשקי API מאפשרת לטפל בנקודות החולשה המובילות באבטחה של OWASP API כדי לנקוט גישה ממוקדת-צריכה לתכנון ממשקי ה-API ולחיבור שלהם למערכות הקצה העורפי. בהמשך מופיעה רשימה של כללי מדיניות או הגדרות אישיות שמומלצות על ידי Apigee לאיומי REST OWASP.

הפתרונות של Apigee ל-10 המובילים של OWASP לשנת 2017

יש חששות אבטחה רבים בכל הנוגע לבנייה ואבטחה של יישומי אינטרנט. ארגון OWASP פרסם את הרשימה של 10 איומי האבטחה המובילים ב-OWASP ב-2017 לאפליקציות אינטרנט. באפליקציית אינטרנט יש הרבה חלקים, אבל רוב אפליקציות האינטרנט המודרניות מסתמכות במידה רבה על ממשקי API ל-REST. Apigee לא נועד לטפל בכל צורכי האבטחה של אפליקציות אינטרנט, אבל יכול להיות לו תפקיד מרכזי באבטחה של ממשקי API ל-REST. בהמשך מפורטים איומי האבטחה המובילים ב-OWASP, ובתיאורים שמתארים איך אפשר להשתמש ב-Apigee כדי לטפל באיומים האלה.

A1:2017 – הזרקה

כדי להגן מפני החדרת נתונים לא מהימנה כמו SQL, NoSQL, LDAP ו-JavaScript, שעלולה לגרום להפעלה של פקודות לא מכוונות או גישה לא מורשית לנתונים, Apigee מספקת מספר כללי מדיניות לאימות קלט כדי לאמת שהערכים שהלקוח מספק תואמים לציפיות לפני שמאפשרים עיבוד נוסף. Apigee Edge, שמשמש כשרת לבקשות ה-API הנכנסות, בודק שמבנה המטען הייעודי (payload) נמצא בטווח המקובל, שנקרא גם 'בדיקת מגבלות'. אפשר להגדיר שרת proxy ל-API על מנת שהתרחיש של אימות הקלט ישנה את הקלט, כדי להסיר רצפי תווים מסוכנים ולהחליף אותם בערכים בטוחים.

יש כמה גישות לאימות קלט באמצעות פלטפורמת Apigee:

אימות סוגי התוכן:

A2:2017 – אימות לא תקין וניהול הפעלות לא תקין

תוקפים יכולים לגשת לסיסמאות, לאסימוני סשן ולמפתחות כדי להתחזות למשתמשים אחרים על ידי ניצול הפגמים בהטמעה באפליקציות. מדובר בבעיית הטמעה ולא בבעיה במוצר. Apigee מספקת מדיניות ValidApiKey , OAuth ו-JSON Web Token (JWT) שמסייעת להגן מפני נקודת חולשה זו.

אימות מפתח API

אימות מפתח API הוא אמצעי האבטחה הפשוט ביותר לאפליקציות שאפשר להגדיר ל-API. אפליקציית לקוח פשוט מציגה מפתח API עם הבקשה שלה, ולאחר מכן Apigee Edge, באמצעות מדיניות שמצורפת לשרת proxy של API, בודקת שמפתח ה-API נמצא במצב מאושר של המשאב המבוקש.

Apigee מספקת תמיכה ביצירה ובאימות של מפתחות API. Apigee יוצרת מפתח API וסוד כשנוצרת ומאושרת אפליקציית פיתוח שמקושרת למוצר API אחד או יותר.

למונח 'מפתחות API' יש לפעמים משמעויות שונות. ב-Apigee, כשנוצרת הקשר בין האפליקציה והמוצר, Apigee יוצר מזהה לקוח וסוד לקוח. חלק מהם מתייחסים גם למזהה וגם לסוד כמפתח ה-API. בחלק מהמקרים, המערכת מתייחסת רק למזהה הלקוח בתור מפתח ה-API. בממשק המשתמש של Edge יופיעו האפשרויות 'מפתח צרכן' ו'סוד צרכן'.

רק מזהה הלקוח או 'מפתח הצרכן' מאומתים במדיניות שלVerifyAPIKey. המפתחים מקבלים מפתח צרכן כשהם רושמים את האפליקציה ב-Apigee ומשייכים את האפליקציה למוצר API. המפתחים כוללים את מפתח הצרכן בקריאות שהאפליקציה מבצעת לשרתי proxy של API שכלולים במוצר ה-API.

ב-Apigee יש גם תמיכה באפשרות לייבא מפתחות API קיימים ממקורות חיצוניים.

כשמדובר בסוגים של הרשאות OAuth, המערכת משתמשת גם במזהה הלקוח וגם בסוד.

OAuth 2.0

מסגרת ההרשאה OAuth 2.0 מאפשרת לאפליקציות של צד שלישי לקבל גישה מוגבלת לשירות HTTP, בין אם בשם הבעלים של המשאב באמצעות ניהול אינטראקציה לאישור בין בעלי המשאב לבין שירות ה-HTTP או על ידי מתן אישור לאפליקציית הצד השלישי לקבל גישה בשמה.

מדיניות OAuth 2.0 של Apigee מאפשרת להטמיע ולהתאים אישית את ארבעת סוגי ההרשאות של OAuth 2.0. ניתן לבצע אכיפה של אסימון גישה ל-OAuth באמצעות מדיניות OAuthv2. הצרכן צריך להיות רשום ולקבל אישור מאפליקציה שהעניקה לו גישה ל-API. בתמורה, הם יקבלו מזהה לקוח ב-API וסוד לקוח. הצרכן צריך לעבור אחד מהאישורים של OAuth כדי לעבור אימות, שמעניק לו אסימון גישה אטום. ניתן להשתמש באסימון הזה כדי לשלוט בגישה ל-API.

אסימון JWT

בדרך כלל, אסימוני האינטרנט JSON, או JWT, משמשים לשיתוף הצהרות או טענות נכונות (assertions) בין אפליקציות מקושרות. ב-Apigee יש תמיכה ב-JWT לפי שלושה כללי מדיניות.

  • יצירת אסימוני JWT (תמיכה בחתימת HS256 ו-RS256)
  • אימות של אסימוני JWT
  • אסימוני פענוח קודJWT ללא אימות

A3:2017 – חשיפה למידע אישי רגיש

התוקפים מטרגטים מידע אישי רגיש כמו פרטי כרטיסי אשראי, מספרי תעודת זהות, פרטי התחברות, פרטים אישיים מזהים (PII) ומזהי מס כדי לבצע גניבת זהות, גניבת כספים, הונאות ופשעים אחרים. כדי להבטיח הגנה על מידע אישי רגיש באפליקציות אינטרנט, צריך להטמיע הצפנה, גם במנוחה וגם במעבר, וגם אסטרטגיות אחרות.

TLS (Transport Layer Security, שקודמה הוא SSL) היא טכנולוגיית האבטחה הסטנדרטית ליצירת קישור מוצפן בין שרת אינטרנט ללקוח אינטרנט, כמו דפדפן או אפליקציה. ב-Apigee יש תמיכה ב-TLS חד-כיווני וגם ב-TLS דו-כיווני.

אפשר להשתמש ב-TLS (אבטחת שכבת התעבורה) לכיוון צפון (לקוח שמתחבר ל-API כשרת) באמצעות הגדרה של מארח וירטואלי. אפשר להגדיר מארח וירטואלי ל-TLS (אבטחת שכבת התעבורה) חד-כיווני או דו-כיווני.

יש תמיכה ב-TLS (אבטחת שכבת התעבורה) כלקוח שמתחבר לשירות לקצה העורפי באמצעות שימוש בהגדרות של שרת יעד. אפשר להגדיר שרת יעד ל-TLS (אבטחת שכבת התעבורה) חד-כיווני או דו-כיווני.

ב-Apigee יש תמיכה באפשרויות הגדרה רבות של TLS.

אכיפת TLS דו-כיוונית מבטיחה שהלקוח משתמש באישור שכבר צורף ל-Apigee. OWASP מספק גם שיטות מומלצות לשימוש ב-TLS (אבטחת שכבת התעבורה).

ב-Apigee היברידי, TLS זמין בתעבורת הנתונים הנכנסת דרך כינוי מארח, שזה דומה למארח וירטואלי.

בהמשך מפורטות הנחיות לאבטחת מידע אישי רגיש:

  • משתמשים בפלטפורמה שתומכת ב-TLS (אבטחת שכבת התעבורה) חד-כיווני ודו-כיווני, שמגן ברמת הפרוטוקול.
  • כדי להסיר מידע אישי רגיש לפני שהוא מוחזר ללקוח, אפשר להשתמש בכללי מדיניות כמו המדיניות של assignMessage ומדיניות JavaScript.
  • כדאי להשתמש בטכניקות OAuth סטנדרטיות ולשקול להוסיף HMAC, גיבוב (hash), מצב (State), חד-פעמי (nonce), PKCE, או שיטות אחרות כדי לשפר את רמת האימות לכל בקשה.
  • אפשר להשתמש בהגדרות של אנונימיזציה של נתונים כדי לבצע אנונימיזציה של מידע אישי רגיש בכלי Edge Trace.
  • חשוב להיזהר מאחסון מידע אישי רגיש במטמון (או להצפין מידע אישי רגיש שנשמר במטמון). ב-Edge, אפשר להצפין מידע אישי רגיש במפות של ערכי מפתח.

A4:2017 - ישויות חיצוניות מסוג XML

מערכות או יישומים שמעבדים XML צריכים לטפל ב "הפניות לישויות חיצוניות" ב-XML - הפניות לקבצים או לנתונים שמוחלפים בנתונים עצמם במהלך עיבוד ה-XML. אם האפליקציות או מעבדי ה-XML ישנים או לא מיושמים בצורה טובה, תוקפים יכולים לפרוץ לנתונים ולהשתמש בהם כדי לגנוב מידע או לבצע התקפות מסוגים שונים על המערכת, כמו התקפת מניעת שירות (DoS).

מדיניות extracts של Apigee מאפשרת לחלץ את התוכן מבקשה או תגובה ומקצים את התוכן הזה למשתנה. אפשר לחלץ כל חלק מההודעה, כולל כותרות, נתיבי URI, מטענים ייעודיים (payloads) של JSON/XML, פרמטרים של טפסים ופרמטרים של שאילתות. המדיניות הזו פועלת על ידי החלת תבנית טקסט על תוכן ההודעה, והגדרת משתנה עם תוכן ההודעה שצוין לאחר מציאת ההתאמה.

ב-Apigee יש מנתח XML מובנה כחלק מהפלטפורמה שמשתמשת ב-XPath לחילוץ נתונים. יש בו גם מדיניות XMLThreatProtection להגנה מפני מטענים ייעודיים (payloads) זדוניים של XML.

A5:2017 – בקרת גישה לא תקינה

אחרי שהמשתמשים יתחברו ויקבלו גישה למערכת, יש להגדיר אמצעי בקרה מתאימים כדי שהמשתמשים יוכלו לראות ולעשות רק את מה שמותר להם. ללא אמצעי בקרת גישה חזקים, תוקפים יכולים לראות מידע לא מורשה ולעיתים קרובות רגיש או להשפיע באופן זדוני על הנתונים ועל התנהגות המערכת.

ב-Apigee יש תמיכה בגישה רב-שכבתית להטמעת בקרת גישה כדי למנוע מהגורמים הזדוניים לבצע שינויים לא מורשים או לגשת למערכת.

בקרות גישה לממשק המשתמש של Edge

בקרות גישה ל-Apigee Developer Portal

  • מגדירים כניסה יחידה (SSO) אצל ספק הזהויות של החברה.
  • מגדירים בקרת גישה מבוססת-תפקיד (RBAC) כדי לאפשר למשתמשים לגשת רק לפונקציונליות ולהגדרות שהם צריכים בפורטלים למפתחים שמבוססים על Drupal.
  • צריך להגדיר פורטלים למפתחים כדי להציג מוצרים ספציפיים של API בהתאם לתפקיד המשתמש.
  • הגדרת הפורטל להצגה או להסתרה של תוכן בהתאם לתפקיד המשתמש.

בקרות גישה לגישת API בזמן ריצה של Apigee

  • אפשר לאכוף את הגישה לממשקי API באמצעות מפתחות API, אסימוני OAuth, היקפי הרשאות של OAuth, אישורים וטכניקות אחרות.
  • ספק ה-API מגדיר אילו משאבים יהיו זמינים באמצעות הגדרת מוצר API. הגישה מוענקת באופן ידני בממשק המשתמש, דרך ה-Management API או דרך הפורטל למפתחים. כשאפליקציה של מפתח מקבלת גישה למוצר API, היא מקבלת מזהה לקוח וסוד שמשמשים בתהליך האימות.
  • Apigee יכול להשתלב עם כל ספק זהויות כדי לבצע OAuth.
  • Apigee יכול ליצור אסימוני JWT או שיטות אחרות כדי לשלוח זהות משתמש לשירותי יעד. שירותי היעד יכולים להשתמש בזהות הזו כדי להגביל את הגישה לשירותים ולנתונים, לפי הצורך.

A6:2017-הגדרה שגויה באבטחה

קל להתעלם מהגדרות שגויות של אבטחה, לרוב מפני שאדמינים ומפתחים סומכים בטעות שהמערכות שבהן הם משתמשים מאובטחות מטבען. קביעת תצורה שגויה של אבטחה יכולה להתרחש בדרכים שונות. למשל, מהימנות על הגדרות ברירת מחדל או יצירת הגדרות חלקיות שעשויות להיות לא מאובטחות, מתן אפשרות להודעות שגיאה להכיל פרטים רגישים, אחסון נתונים בענן ללא אמצעי אבטחה מתאימים, הגדרה שגויה של כותרות HTTP וכו'. פלטפורמת Apigee מספקת מספר מנגנונים המאפשרים לשלוט בהגדרות האבטחה, לנהל אותן ולעקוב אחריהן, כולל תהליכים משותפים לשימוש חוזר.

תהליך משותף מאפשר למפתחי API לשלב מדיניות ומשאבים בקבוצה לשימוש חוזר. תהליך משותף שמתעד פונקציונליות לשימוש חוזר במקום אחד עוזר לשמור על עקביות, לקצר את זמן הפיתוח ולנהל את הקוד יותר בקלות. אפשר לכלול תהליך משותף בתוך שרתי proxy ספציפיים של API, או להתקדם עוד צעד אחד ולשלב תהליכי עבודה משותפים בקטעי הוק (hooks) לזרימה כדי להפעיל באופן אוטומטי לוגיקת זרימה משותפת עבור כל שרת proxy של API שנפרס באותה סביבה כמו תהליך משותף.

גרסאות מוצרי Apigee מבטיחות הגנה מפני ספריות המכילות נקודות חולשה. Apigee עשויה לפרסם תיקונים או עדכונים נוספים אם יימצאו נקודות חולשה חדשות. הענן הציבורי של Edge תוקן באופן אוטומטי. לקוחות Edge לענן פרטי (מקומי) צריכים להחיל בעצמם את התיקונים של המוצרים.

A7:2017-Cross-Site Scripting (XSS)

סקריפטים חוצי-אתרים (XSS) מאפשרים לתוקפים להפעיל סקריפטים בדפדפני אינטרנט של משתמשים כדי לשלוט בסשנים של משתמשים, לבצע מניפולציות באתרים או להשפיע על משתמשים בדרכים אחרות. בעיות XSS לא בהכרח קשורות לממשקי API, אבל ב-Apigee יש מדיניות הגנה מפני איומים שאפשר להשתמש בה כדי להגן מפני XSS ב-API. באמצעות ביטויים רגולריים, באמצעות regularExpressionProtection או המדיניות של JavaScript, תוכלו לבדוק את המטען הייעודי (payload) ואת ערכי הפרמטרים עבור JavaScript והתקפות אחרות מסוג הזרקה.

CORS, אחד מהפתרונות הנפוצים ביותר למדיניות המקור הזהה שנאכפת על ידי כל הדפדפנים, אפשר להטמיע באמצעות מדיניות הקצאה.

A8:2017 – פעולת deserialization לא מאובטחת

תוקפים יכולים להשתמש בפגמים בפעולת deserialization לסוגים שונים של התקפות, כמו הפעלה מחדש, הסלמת הרשאות (privilege escalation) והזרקה. פעולת deserialization לא מאובטחת יכולה גם לאפשר ביצוע קוד מרחוק.

ב-Apigee לא מומלץ לבצע פעולת deserialization. עם זאת, המדיניות JSONThreatProtection ו-regularExpressionProtection יכולות להגן מפני מטענים ייעודיים (payloads) זדוניים של JSON. ניתן להשתמש במדיניות JavaScript גם כדי לסרוק מטענים ייעודיים (payloads) לאיתור תוכן זדוני. המטמון וכללי מדיניות נוספים יכולים לשמש לצורך הגנה מפני התקפות שליחה מחדש. ברמת התשתית, בפלטפורמת Apigee יש גם שכבות הגנה מובנות כדי להגן על תהליכים פועלים.

A9:2017 - שימוש ברכיבים עם פגיעויות ידועות

מאחר שמסגרות, ספריות ומודולים פועלים עם הפעלה מלאה וגישה ל-CRUD, תוקפים יכולים למנף נקודות חולשה של רכיבים למערכות תקיפה.

גרסאות המוצרים הרגילות של Apigee מבטיחות הגנה מפני נקודות חולשה ברכיבים, במיוחד כשמתגלות נקודות חולשה ספציפיות. הענן הציבורי של Apigee תוקן באופן אוטומטי, ו-Apigee מודיעה ללקוחות Edge for Private Cloud כשיש תיקונים מקומיים זמינים להתקנה.

A10:2017 – בעיות ברישום ביומן ובניטור

אם לא תבצעו כראוי רישום ביומן, מעקב וניהול אירועי אבטחה במערכות שלכם, תוקפים עלולים לבצע התקפות עמוקות וממושכות יותר על נתונים ותוכנות.

ב-Apigee יש מספר דרכים לבצע רישום ביומן, מעקב, טיפול בשגיאות ורישום ביומן ביקורת.

רישום ביומן

  • ניתן לשלוח הודעות יומן ל-Splunk או לנקודת קצה אחרת של syslog באמצעות מדיניות MessageLogging.
  • אפשר לשלוף את ניתוח הנתונים של ה-API דרך ה-API של Analytics ולייבא או לייצא אותו למערכות אחרות.
  • ב-Edge for Private Cloud, אתם יכולים להשתמש במדיניות MessageLogging כדי לכתוב בקובצי יומן מקומיים. תוכלו גם לגשת לקובצי יומן מכל אחד מהרכיבים שפועלים.
  • ניתן להשתמש במדיניות JavaScript כדי לשלוח הודעות יומן לנקודת קצה (endpoint) של רישום REST באופן סינכרוני או אסינכרוני.

מעקב

  • אפשר להשתמש ב-API או בממשק המשתמש של API Monitoring כדי לעקוב באופן קבוע אחרי ממשקי ה-API והקצוות העורפיים ולהפעיל יציאות.
  • אפשר להשתמש במעקב אחר מצב הבריאות כדי לעקוב באופן קבוע אחרי הקצוות העורפיים של שרת היעד.
  • ב-Apigee מוצגות המלצות למעקב אחרי Edge עבור ענן פרטי.
  • Apigee מספקת גם שיטות מומלצות שהצוות שלך יכול להשתמש בהן כדי לעקוב אחרי תוכנית ה-API שלך.

טיפול בשגיאות

Apigee מציעה מנגנון רב-תכליתי לטיפול בכשלים בשרתי proxy ל-API. בדומה לאופן שבו תוכנית Java מזהה חריגים, שרתי proxy של API יכולים לאתר שגיאות ולקבוע איך להחזיר תגובות מתאימות ללקוחות. הטיפול בשגיאות בהתאמה אישית ב-Apigee מאפשר להוסיף פונקציונליות כמו רישום הודעות בכל פעם שמתרחשת שגיאה.

יומני ביקורת

פלטפורמת Apigee שומרת יומן ביקורת שעוקב אחר שינויים בשרתי proxy של API, במוצרים ובהיסטוריית הארגון. היומן הזה זמין דרך ממשק המשתמש או דרך Audits API.

פתרונות Apigee לנקודות חולשה של OWASP לשנת 2013

כשרשימת נקודות החולשה של OWASP עודכנה ל-2017, חלק מנקודות החולשה של שנת 2013 הוסרו. הן עדיין איומים תקפים. בקטעים הבאים מוסבר איך לטפל באיומים האלה באמצעות Apigee.

A8:2013 - זיוף בקשה בין אתרים (CSRF)

בקשות זיוף חוצות-אתרים מאפשרות לתוקפים להעביר פרטי אימות, קובץ cookie של סשן ונתונים אחרים של משתמש לאפליקציית אינטרנט פגיעה באמצעות HTTP. בקשות כאלה עלולות להטעות את אפליקציית האינטרנט ולגרום לה להאמין שהבקשות הן בקשות לגיטימיות מהמשתמש.

הנחיות:

  • מדובר בבעיה בדפדפן ולא במוצר API. אפשר לטפל בנקודת החולשה הזו באמצעות OpenID Connect, OAuth ושיטות אחרות.
  • כדאי להשתמש בטכניקות HMAC, state, hash, nonce או PKCE כדי למנוע זיוף והתקפות שליחה מחדש.

A10:2013 - הפניות אוטומטיות והעברות שלא אומתו

אם אפליקציית אינטרנט מבצעת הפניות אוטומטיות אבל לא מאמתת שההפניות שולחות משתמשים לאתרי אינטרנט מהימנים, תוקפים יכולים לשלוח משתמשים ליעדים זדוניים כדי לבצע פישינג, הפעלת תוכנות זדוניות והתקפות אחרות.

הנחיות:

  • שימוש ב-OAuth ואכיפת אימות בכל בקשה.
  • כדי למנוע הפניות 302 לא צפויות, צריך לבדוק אם יש קודי תגובה בלוגיקה של שרת ה-API של שרת ה-API ולטפל בהפניות מחדש בהתאם.