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

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

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

סקירה כללית

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

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

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

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

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

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

פתרונות Apigee ל-OWASP Top 10 משנת 2017

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

‫A1:2017 - Injection (הזרקה)

כדי להגן מפני הזרקת נתונים לא מהימנים כמו SQL,‏ NoSQL,‏ LDAP ו-JavaScript, שעלולה לגרום להרצת פקודות לא מכוונות או לגישה לא מורשית לנתונים, Apigee מספקת כמה כללי מדיניות לאימות קלט כדי לוודא שהערכים שסופקו על ידי לקוח תואמים לציפיות לפני שמאפשרים עיבוד נוסף. ‫Apigee Edge, שפועל כשרת לבקשות API נכנסות, בודק כדי לוודא שמבנה המטען הייעודי (payload) נמצא בטווח מקובל, שנקרא גם בדיקת מגבלה. אתם יכולים להגדיר 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, יופיעו הערכים טוקן צרכן ו-consumer secret.

במדיניות VerifyAPIKey, מאומת רק ה-Client-ID, או 'טוקן צרכן'. מפתחים מקבלים טוקן צרכן כשהם רושמים את האפליקציה שלהם ב-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, משמשים בדרך כלל לשיתוף טענות או הצהרות בין אפליקציות מקושרות. ‫Apigee מספק תמיכה ב-JWT באמצעות שלוש מדיניות.

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

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

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

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

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

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

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

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

ב-Apigee hybrid, ‏ TLS זמין ב-ingress דרך כינוי מארח, שהוא מושג דומה למארח וירטואלי.

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

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

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

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

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

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

A5:2017 - Broken Access Control

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

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

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

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

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

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

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

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

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

‫A8:2017 – ביטול סדרות לא מאובטח

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

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

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

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

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

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

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

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

רישום ביומן

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

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

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

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

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

הנחיות:

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

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

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

הנחיות:

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