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

אתם צופים במסמכי העזרה של Apigee Edge.
כניסה למסמכי העזרה של Apigee X. info

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

סקירה כללית

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

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

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

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

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

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

פתרונות של 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 הנכנסות, בודק שהמבנה של עומס העבודה נמצא בטווח הקביל. הבדיקה הזו נקראת גם בדיקת מגבלות. אפשר להגדיר שרת proxy ל-API כך שתוכנית האימות של הקלט תשנה את הקלט כדי להסיר רצפי תווים מסוכנים ולהחליף אותם בערכים בטוחים.

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

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

A2:2017 – אימות וניהול סשנים פגומים

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

אימות של מפתח API

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

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

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

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

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

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

OAuth 2.0

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

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

JWT

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

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

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

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

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

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

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

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

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

ב-Apigee Hybrid, TLS זמין ב-ingress דרך כתובת חלופית של מארח, שזהו מושג דומה למארח וירטואלי.

ריכזנו כאן הנחיות לאבטחת מידע אישי רגיש:

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

A4:2017 – ישויות חיצוניות של XML

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

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

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

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

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

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

אמצעי בקרת גישה לממשק המשתמש של Edge

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

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

אמצעי בקרת גישה לגישה ל-API בסביבת זמן הריצה של Apigee

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

A6:2017-Security Misconfiguration

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

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

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

A7:2017-Cross-Site Scripting (XSS)

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

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

A8:2017 – דה-סריאליזציה לא מאובטחת

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

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

A9:2017 – שימוש ברכיבים עם נקודות חולשה ידועות

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

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

A10:2017 – רישום ביומן ומעקב לא מספיקים

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

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

רישום ביומן

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

מעקב

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

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

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

יומני ביקורת

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

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

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

A8:2013 – Cross-Site Request Forgery‏ (CSRF)

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

הנחיות:

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

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

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

הנחיות:

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