עם קצב גידול של מעל 200% בשנה וכשהם מהווים תפקיד חשוב בכל תשתית מודרנית, עולם ה-API מתפתח כל הזמן ועימו גם הסיכונים. כמענה על כך, ארגון OWASP פרסם מהדורה שניה של ה-API Security top 10 risks. נצלול לכל העדכונים, התוספות ולמה שנשאר הסיכון הגדול ביותר.

טל קפיטולניק, ארכיטקט פתרונות אבטחת מידע, NessPRO

ארבע שנים אחרי שיצאה בפעם הראשונה ,ארגון OWASP הוציא מהדורה חדשה של עשרת הסיכונים הגדולים באבטחת API (API Security top 10 risks), שמהווה קו מנחה בתחום.

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

קודם כל, מה לא השתנה

הסיכון ל- Broken Object Level Authorization, או בקיצור BOLA, שמר על מקומו בפסגת הרשימה. הסיכון מדבר על גורם שמצליח לגשת לאובייקטים שהוא אינו מורשה אליהם, למשל לקוח שניגש לחשבון בנק של לקוח אחר.
API חשוף ל-BOLA אם אינו מבצע בדיקת הרשאות באופן מספק בעת הגישה למשאב. ברוב המקרים לא נדרש האקינג מתוחכם כדי לנצל את החולשה ומספיק רק לבצע בקשת GET פשוטה.

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

גם המקום החמישי, Broken Function Level Authorization, נשאר ללא שינוי. הסיכון מדבר על גישה ל-API מסוים שהוא אינו מורשה אליו, למשל לקוח שמצליח לגשת ל- Administrative APIs.

הסיכון האחרון שנשאר זהה מ-2019 הוא המקום השמיני, Security Misconfiguration, שירד מקום אחד. דוגמאות לסיכון הן APIs רגישים שאינם מוגנים ב- Transport Layer Security(TLS) או הודעות שגיאה שמחזירות מידע עודף לקליינט.

אז מה כן השתנה?

קודם כל ניתן לראות שהסיכונים של Injection (#8) ושל Insufficient logging & Monitoring (#10) ירדו מלפני 4 שנים, וזאת משום שהם סיכונים פחות שכיחים שנפתרו כבר ברוב הארגונים. Injection ניתן למניעה בקלות על ידי WAF או API Gateway, שכבר נהיו "Commodity".
מוצרים אלו גם מתממשקים בצורה טובה לכלי ניטור, כך שכל בקשה מנוטרת ומתועדת.

אלו הם השינויים בגרסה החדשה:

1. סיכון חדש – Broken Object Property Level Authorization

סיכון חדש שנכנס למקום השלישי, ומורכב מאיחוד של שני סיכונים מ-2019:

• Excessive Data Exposure- API שחושף מאפיינים של אובייקט שהמשתמש לא מורשה אליהם.
• Mass Assignment – API שמאפשר למשתמש לשנות, להוסיף או למחוק מאפיינים של אובייקטים ללא הרשאה מתאימה.

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

2. עדכון – Unrestricted Resource Consumption

המקום הרביעי הוא אינו סיכון חדש, אלא עדכון ל-Lack Of Resources And Rate Limit מגרסת 2019. השם שונה לאחד שמשקף את שורש הבעיה, כשהסיכון נשאר זהה.

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

3. סיכון חדש – Unrestricted Access to Sensitive Business Flows

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

4. סיכון חדש – Server Side Request Forgery

סיכון חדש במקום השביעי הנו ה-SSRF. חשופים אליו APIs שמקבלים URL בקלט מהמשתמש מבלי לוודא אותו.
ניתן דוגמה לאתר המאפשר להעלות אליו תמונה באמצעות הכנסת לינק לתמונה. תוקף יכול להזין קישור למשאב פנימי ב-URL, לדוגמה http://localhost/admin, וכך לקבל גישה למשאבים פנימיים שהוא אינו מורשה אליהם.

5. עדכון סיכון – Improper Inventory Management

במקום התשיעי ישנו שינוי שם – Improper Inventory Management במקום Improper Assets Management, שמדגיש את החשיבות לתחזק API Inventory מעודכן ושלם.
נראות של כלל המידע שהארגון חושף והפעולות שהוא מאפשר לבצע דרך תשתית ה-API שלו היא קריטית כדי לאתר בעיות אבטחת מידע.

מסקנות

פערים בהרשאות גישה הם הסיכון הגדול ביותר לתשתית ה-API של הארגון, כשלושה מחמשת המקומות הראשונים מתייחסים ל-Authorization בשלוש רמות שונות (Object, Object Property ו-Function) ניהול הרשאות לכלל ה-APIs שהארגון חושף, בצורה חכמה ובמיקום מרכזי ונגיש היא קריטית לאבטחת המידע של הארגון.

באופן כללי יותר, כל חמשת המקומות הראשונים שייכים לתחום ה-Access Control, כשאימות זהות המשתמש והגבלת גישה מתווספים לנושא ההרשאות.
שימוש בכלי API Management עוזר להגדיר מדיניות אבטחה לכל API שהארגון חושף.

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

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

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