חקירת API ומיפוי אנדפוינטים - איך מוצאים את מה שהתיעוד לא מראה לכם

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

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

למה בכלל יש אנדפוינטים "חבויים"

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

מאיפה מתחילים לחפש

יש כמה מקורות עיקריים לגילוי אנדפוינטים:

• ניתוח קוד JavaScript. קוד הקליינט חושף כמעט תמיד את כל כתובות ה-API שהאפליקציה קוראת להן, כולל כאלה שמוצגות רק במצבים מסוימים או לתפקידי משתמש מסוימים. זו הסיבה שניתוח JS סטטי הוא שלב כמעט תמיד קודם לחקירת API.
• תיעוד API חשוף. לפעמים קובץ Swagger או מפרט OpenAPI נשאר נגיש בכתובת ציבורית - /swagger.json, /api-docs, /openapi.yaml - ומספק בעצם רשימה מלאה ומוכנה של כל האנדפוינטים, כולל הפרמטרים שכל אחד מהם מצפה לקבל.
• דפוסי שמות צפויים. API-ים נבנים לרוב לפי מוסכמות עקביות - אם קיים /api/v1/users/123, סביר שקיים גם /api/v1/users/123/orders או /api/v2/users. חוקר מנוסה לומד לנחש דפוסים כאלה ולבדוק אותם.
• יירוט תעבורה מאפליקציית מובייל. אם למטרה יש אפליקציית מובייל, היא מתקשרת מול אותו שרת API, ולרוב חושפת אנדפוינטים שלא קיימים בגרסת הווב בכלל. הרצת האפליקציה דרך proxy מאפשר לראות את כל התעבורה הזאת.
• חיפוש שיטתי עם רשימות מילים - Wordlist Brute-Forcing. כשיש דפוס ידוע, אפשר להריץ כלי שמנסה באופן שיטתי שמות אנדפוינטים נפוצים מתוך רשימה מוכנה, ולראות אילו מהם מחזירים תגובה שונה מ-404. זו טכניקה חזקה במיוחד כשמשלבים אותה עם הבנה של המוסכמות הפנימיות של המערכת.

למה אנדפוינטים פחות שימושיים נוטים להיות פחות מוגנים

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

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

איך מתעדים את הממצאים

מיפוי בלי תיעוד מסודר שווה מעט. שווה לשמור טבלה של כל אנדפוינט שנמצא, יחד עם השיטה שלו (GET, POST וכו'), האם הוא דורש אימות, ואילו פרמטרים הוא מקבל. הטבלה הזאת הופכת בהמשך לרשימת עבודה מסודרת במקום זיכרון מפוזר של "איפה בדיוק ראיתי את זה".

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

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

הצטרפו לקהילה בדיסקורד

לסיכום

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