כל pull request שמוסיף או משנה נקודת קצה משנה את משטח התקיפה של ה-API שלך. רוב כלי אבטחת ה-API לא שמים לב לכך עד שנקודת הקצה הזו פעילה וכבר מקבלת תעבורה. עד אז, התיקון כבר אינו שינוי בשורה אחת בסקירת קוד, אלא שיחת תגובה לאירוע.
אבטחת API היא הנוהג של מציאת וסגירת הסיכונים באופן שבו יישום חושף את נקודות הקצה שלו: מי יכול לקרוא אליהן, אילו נתונים הן מחזירות, והאם הן עושות את מה שהתיעוד אומר שהן עושות.
רוב הכלים שנבנו עבור בעיה זו בודקים את ה-API בזמן ריצה, מבחוץ, באותו אופן שבו תוקף היה עושה זאת. גישה זו עובדת, אך היא פועלת רק לאחר פריסת ה-API. קסיגני לוקח את הנתיב הקודם: הוא קורא את קוד המקור שלך ואת מפרט ה-API שלך לפני שבקשה אחת מגיעה לנקודת הקצה.
ארבע הדרכים לבדיקת API, ומה כל אחת מהן עונה עליהן
רוב התוכניות למבוגרים מפעילות יותר מאחד מאלה:
- בדיקה סטטית מנתח את קוד המקור ומפרטי ה-API לפני הפריסה. הוא עונה על השאלה "מה בדיוק חשפנו?". זוהי הגישה שמאמר זה מתמקד בה.
- בדיקות דינמיות (DAST) שולח תעבורה אמיתית ל-API פעיל וצופה כיצד היא מגיבה. הוא עונה על "מה באמת ניתן להשגה וניתן לניצול כרגע?"
- מבולבל זורק קלט פגום או בלתי צפוי בנקודות קצה לקריסות שטח וכשלים בקצה השטח. זה עונה על "אילו תקלות תחת קלט שלא צפינו?"
- בדיקת חדירה ידנית מוסיף שיקול דעת אנושי כדי למצוא פגמים לוגיים שכלים אוטומטיים מפספסים. זה עונה על השאלה "מה תוקף חכם היה מקשר?"
אף אחת מהן לא מחליפה את האחרות. הן עונות על שאלות שונות בנקודות שונות במחזור החיים, והפער שיש ברוב התוכניות הוא הראשון.
מדוע רוב כלי אבטחת ה-API מזהים את הסיכון מאוחר מדי
בדיקות אבטחה של API בזמן ריצה שולחות תעבורה ליישום פעיל וצופות כיצד הוא מגיב. זוהי שכבה לגיטימית והכרחית. היא גם, מעצם מבנהה, אינדיקטור של פיגור: נקודת קצה צריכה להתקיים, להיפרס ולהיות נגישה לפני שסורק בזמן ריצה יוכל לומר משהו עליה. כל מה שהוא מוצא כבר היה חשוף, לא משנה כמה זמן לקח לסריקה להריץ.
יש פער שני מתחת לבעיית התזמון הזו. כלי זמן ריצה יכולים לבדוק רק את מה שהם יודעים שקיים. אם נקודת קצה מעולם לא תועדה, או שמפרט ה-OpenAPI התיישן ברגע שמישהו שלח נתיב חדש, לסורק זמן ריצה אין דרך לדעת שהוא שם. הוא בודק את המפה, לא את הטריטוריה.
בדיקות אבטחה סטטיות של API סוגרות את שני הפערים על ידי העברת הבדיקה למקום שבו מוגדר נקודת הקצה: הקוד שלך ומפרט ה-API שלך, לפני הפריסה. pull request שמציג נקודת קצה הוא ה- pull request שחושף את הסיכון שלו
מהי אבטחת API סטטית בפועל
Xygeni בונה את מלאי ה-API שלך משני מקורות: קוד המקור של האפליקציה שלך ומפרטי ה-API שלך, כולל OpenAPI ו-Swagger.
רשימת מלאי המבוססת על מפרט בלבד מציגה את נקודות הקצה שמישהו זכר לתעד. רשימת מלאי המבוססת על קוד בלבד מראה מה קיים אך לאו דווקא כיצד הוא נועד לשמש. קריאת שניהם נותנת לך את התמונה המלאה: נקודות הקצה שהצוותים שלך תיעדו, ואלה שאף אחד לא תיעדו.
המלאי הזה הוא הבסיס שעליו כל השאר בנוי:
- סך ממשקי API שהתגלו ונכסים בסיכון שנמדדו מול קו בסיס
- נקודות קצה מפורקות לפי שיטת HTTP
- בעיות מקובצות לפי שירות
- כל נקודת קצה עם השיטה, הנתיב, השירות, המודול, מצב האימות וציון הסיכון שלה
ראשי ההנדסה שלכם רואים את צורת פני השטח של ה-API שלכם מבלי לפתוח אפילו כרטיס אחד.
כל נקודת קצה ש-Xygeni מצאה, יחד עם השיטה שלה, מצב האימות וציון הסיכון שלה, בנויה מקוד ומפרט יחד.
Production note חתוך את לוח מיון הבינה המלאכותית מכל צילום מסך של אבטחת ה-API.
ממופה לעשרת המובילים של אבטחת API של OWASP
הממצאים משקפים את המסגרת שבה צוותי האבטחה והמבקרים שלכם כבר משתמשים. Xygeni מזהה סיכונים ברחבי ממשק האבטחה של OWASP API. 10 המובילים (2023):
| OWASP | הסיכון | מה זה אומר בפועל |
|---|---|---|
API1 | הרשאה ברמת אובייקט שבור | נקודת קצה מחזירה או משנה נתונים השייכים למשתמש או דייר אחר |
API2 | נקודות קצה לא מאומתות | ניתן להגיע לנתיב ללא אימות כלל |
API3 | חשיפה מוגזמת לנתונים | תגובה מחזירה יותר שדות ממה שהמתקשר צריך או אמור לראות |
API3 | מטלה המונית | נקודת קצה מקבלת ומפעילה שדות שמעולם לא נועדה לקבל |
API3 / API10 | נתונים רגישים בתגובות | PII, PCI או PHI מגיעים ללקוח מנקודת קצה שלא אמורה לשלוח אותם |
API4 | מגבלות שיעור חסרות | לנקודת קצה אין הגנה מפני שימוש לרעה או קריאות Brute-Force |
API5 | הרשאה ברמת פונקציה שבורה | נקודת קצה מבצעת פעולה מורשית מבלי לבדוק שהמתקשר מורשה |
API7 | SSRF | ניתן להערים על ה-API לבצע בקשות מטעם התוקף |
API8 | תצורה שגויה של JWT | אימות, חתימה או תפוגה של אסימון מוגדרים בצורה שגויה |
API8 | תצורה שגויה של CORS | כללים חוצי-מקורות מתירניים מספיק כדי שניתן יהיה לנצל אותם |
API9 | נקודות קצה של זומבים ויתומים | מסלולים מיושנים או נשכחים שעדיין ניתנים לגישה, ומסלולים שאינם בבעלות אף אחד |
קטגוריה אחת נעדרת במכוון. API6, גישה בלתי מוגבלת לזרימות עסקיות רגישות, דורשת הבנה של מה תהליך עסקי אמור לאפשר, ואף מנתח סטטי לא מזהה זאת בצורה אמינה. כל ספק שטוען אחרת מוכר לכם תיבת סימון. זו נשארת עם מידול האיומים שלכם ועם בודקי החדירה שלכם.
לא כל ממצא שווה: רגישות נתונים ושילובים רעילים
רשימה שטוחה של ממצאים מתייחסת לנקודת קצה לא מאומתת של בדיקת תקינות באותו אופן כמו לנקודת קצה לא מאומתת שמחזירה רשומות לקוחות. אלה לא אותה בעיה, ומודל תעדוף שמדרג אותן באופן זהה מאמן את הצוותים שלכם להתעלם מהרשימה.
Xygeni מסווג את הנתונים שכל נקודת קצה מטפלת בהם, מסמן PII, PCI ו-PHI בפרמטרי בקשה ובתגובות, ומשלב זאת עם מצב האימות של נקודת הקצה.
זה גם מקשר ממצאים שנופלים על אותה נקודת קצה ומעלה את החומרה כאשר הם מצטברים. דליפת מידע אישי מזהה בתגובה היא ממצא חמור בפני עצמו. אותה דליפה בנקודת קצה שאינה דורשת אימות היא קריטית, והפלטפורמה מדרגת אותה כך במקום להשאיר את החיבור למישהו אחר לשים לב אליו באופן ידני.
נקודות קצה של זומבים ויתומים: הסחף בין קוד למפרט
מכיוון ש-Xygeni קורא את הקוד שלך ואת מפרט ה-API שלך זה לצד זה, הוא מזהה היכן הם חלוקים בדעתם. סטייה זו מופיעה כשלושה דפוסים ניתנים לזיהוי:
- נקודות קצה לא מתועדות. הם חיים בקוד ומעולם לא נוספו למפרט.
- נקודות קצה של זומבים. הם מסומנים כמיושנים או שהוצאו משימוש, ועדיין ניתן להגיע אליהם.
- נקודות קצה יתומות. אף אחד בקבוצה הנוכחית לא מחזיק אותם.
אף אחד מאלה לא מופיע במלאי המפרט בלבד, כי המפרט הוא בדיוק מה שחסר בהם.
ראיות שניתן לפעול על פיהן, לא כרטיס לחקירה
כל ממצא מצביע על המטפל המדויק האחראי: הקובץ, המחלקה, המתודה והשורה הספציפית שהציגה את הפגם, כאשר הקוד הפוגע מוצג לצידם. כל אחד מהם נושא גם את חומרתו, את קטגוריית OWASP API Security Top 10 שלו, את CWE שלו, את מצב האימות של נקודת הקצה ואת סיווג הרגישות של הנתונים המעורבים.
ממצא שרק שם נקודת קצה שולח מפתח לחפש בבסיס הקוד עוד לפני שהוא יכול להתחיל לתקן משהו. ממצא ששמה שמה את השורה מציב אותו מיד בפתרון.
ממצאים מיוצאים כ-JSON, CSV, Markdown ו-SARIF 2.1.0, כך שהם מגיעים ל-tהכלים שבהם הצוותים שלך כבר עובדים.
המטפל, השורה והקוד שהכניסו את החשיפה. לא דו"ח לחקירה.
למה זה קיים בפלטפורמה אחת, לא בקונסולה אחרת
Xygeni מפעילה אבטחת API לצד SAST, SCA, סודות אבטחה, IaC ו Dast בתוך פלטפורמה אחת, בקורלציה דרך ASPM, במקום לשלוח אותו ככלי נפרד עם כלי משלו login והצבר שלה.
זה חשוב מכיוון שממצאים סטטיים וממצאים בזמן ריצה עונים על שאלות שונות לגבי אותה נקודת קצה, והם שימושיים יותר יחד מאשר לחוד. סטטי אומר לך שנקודת קצה מסוכנת לפני שהיא נשלחת. DAST מאשר מה באמת ניתן לגשת אליו ומה ניתן לניצול לאחר שהיא פועלת.
פצל את זה בין שתי קונסולות והסיכון המתואם הופך לשני מצבי חסימה שאינם קשורים זה לזה. אף אחד לא מפשר ביניהם, ונקודת הקצה שהיא גם לא מתועדת וגם לא מאומתת לא נמצאת באף אחד מהתורים.
ראה את משטח ההתקפה האמיתי שלך ב-API. אבטחת API זמינה כ- Enterprise תוסף לפלטפורמת Xygeni, וסריקה רצה מול המאגרים שלך בתוך התשתית שלך.
שאלות נפוצות
האם זה יכול לדעת אילו נקודות קצה מטפלות במידע רגיש?
כן. Xygeni מסמן PII, PCI ו-PHI בפרמטרים ובתגובות של נקודות קצה, ומשתמש בסיווג זה כדי לדרג ממצאים לפי חשיפה אמיתית.
האם זה יכול לרוץ על כל אחד pull request?
כן. סריקה מצטברת מנתחת רק את נקודות הקצה שהשתנו, והמניפסט שהיא מייצרת יכול למקד סריקת DAST עוקבת באותן נקודות קצה, כך שבדיקות סטטיות ובדיקות בזמן ריצה יישארו מיושרות למה שהשתנה בפועל.
האם הקוד שלי עוזב את הסביבה שלי?
לא. הסריקות פועלות בתשתית שלך. רק התוצאות מועלות, מוגנות במעבר ובמנוחה.
איך אני משיג אבטחת API?
אבטחת API זמינה כ- Enterprise תוסף. בקשו אישור עתידי (PoC) והוא ייבדק עבורכם.





