בדיקת API בעזרת AI: OpenAPI ו-GraphQL

אפליקציות מודרניות הן front end דק מעל API, וה-API הוא לעיתים קרובות המקום שבו הבאגים האמיתיים נמצאים. החדשות הטובות לבודק הן שה-APIs נוטים לתאר את עצמם: APIs מסוג REST שולחים OpenAPI specifications, ו-APIs מסוג GraphQL עונים לשאילתות introspection. שניהם נותנים לך מפה שהמודל יכול לקרוא. הפוסט הזה ממשיך את בדיקת באגים נפוצים בווב ומוביל אל בניית hackbot.

#APIs נשברים אחרת

OWASP API Security Top 10 שם את ה-authorization בראש. השניים שכדאי ללמוד קודם הם broken object level authorization, שבו אתה מגיע לאובייקט של משתמש אחר, ו-broken function level authorization, שבו אתה קורא לפעולת admin כמשתמש רגיל. שניהם הגרסה ברמת ה-API של באגי בקרת הגישה מהפוסט הקודם, ושניהם נפוצים כי ל-API יש הרבה endpoints ואחד מהם בדרך כלל שוכח את הבדיקה.

#מציאת ה-OpenAPI spec

הרבה APIs מפרסמים את ה-specification שלהם. מיקומים נפוצים הם /openapi.json, /swagger.json, /v1/openapi.json, או עמוד docs שטוען אחד. משוך אותו ויש לך כל path, method, פרמטר ו-schema בקובץ אחד.

curl -s https://api.example.com/openapi.json -o openapi.json

תן את ה-spec למודל ובקש ממנו לרשום את ה-endpoints, לסמן את אלה שקוראים או כותבים אובייקטים בבעלות משתמש, ולסמן את אלה ששמם מרמז על תפקיד admin או פנימי. מעבר הקריאה הזה הופך מסמך OpenAPI ארוך לרשימה מדורגת של מה לבדוק קודם.

#GraphQL introspection

API מסוג GraphQL בדרך כלל עונה לשאילתת introspection שמחזירה את כל ה-schema שלו: כל type, field, query ו-mutation. כש-introspection דלוק, אתה מקבל את כל משטח התקיפה ב-request אחד.

curl -s https://api.example.com/graphql -H 'Content-Type: application/json' \
  -d '{"query":"{ __schema { queryType { name } mutationType { name } types { name kind } } }"}'

מסור את ה-schema למודל ובקש ממנו לקבץ את ה-queries וה-mutations, לבחור את אלה שנוגעים בנתונים של משתמשים אחרים, ולנקוב בארגומנטים שכל אחד מקבל. מפרט GraphQL מתאר את ה-introspection, ול-OWASP Web Security Testing Guide יש סעיף על בדיקת GraphQL.

#תן למודל לתכנן, ואז בדוק ביד

מכל אחת מהמפות, בקש מהמודל תוכנית בדיקה קצרה: לכל endpoint שמחזיק אובייקט, באילו שני חשבונות להשתמש ואיזה id להחליף; לכל פעולה בעלת הרשאה, מאיזה session עם הרשאה נמוכה לנסות אותה. המודל טוב בהפיכת schema ל-checklist הזה. הוא לא יכול לומר לך אם הבדיקה באמת חסרה, ולכן אתה מריץ כל מקרה דרך ה-proxy שלך עם החשבונות שבשליטתך וקורא את התוצאה. mutation שמאפשר למשתמש רגיל לשנות רשומה של משתמש אחר הוא BOLA נקי, מוכח עם שני sessions.

#אימות ושמירת ראיות

findings ב-API קל להוכיח וקל להגזים בהם. הוכח אותם עם חשבונות שבשליטתך, משתנה אחד בכל פעם, ושמור את ה-request וה-response המלאים לכל אחד. ל-BOLA, הראיה היא שני requests: האובייקט שלך, אחר כך האובייקט של החשבון השני שחוזר ל-session שלך. ל-BFLA, זו הקריאה בעלת ההרשאה שמצליחה מ-session שלא אמור לקבל רשות לבצע אותה. שמור את הנתונים הפנימיים שאתה מגיע אליהם למינימום הדרוש כדי להראות השפעה, ותאר רק את מה שהדגמת.

#הערה על אוטומציה וקצב

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

#הבא במסלול

הרצת עכשיו את כל הלולאה ביד. שלושת הפוסטים הבאים בונים סוכן קטן שמריץ בשבילך את שלבי ה-recon והבדיקה, באישורך. התחל עם הארכיטקטורה של ה-hackbot.