קריאת JavaScript בעזרת AI כדי למצוא endpoints

אפליקציית single-page שולחת את ה-front end שלה כ-JavaScript, והקוד הזה מחזיק את רשימת ה-endpoints שהאפליקציה מדברת איתם. קריאת ה-bundles האלה היא אחת ממשימות ה-recon בעלות הערך הגבוה ביותר למתחיל, והיא משימת קריאה, ששם מודל עוזר. הפוסט הזה ממשיך את הקמת ה-toolkit ומזין את בדיקת באגים בווב. ל-recon רחב יותר, מה זה OSINT מכסה את הרעיון בלי להפוך למדריך כלים.

#למה ה-JavaScript חשוב

הדפדפן חייב לדעת כל URL שהוא קורא לו, ולכן ה-paths, הפרמטרים, ולפעמים feature flags ושמות של תפקידים חיים בקוד שנשלח. bundle מוקטן מסתיר את זה מאדם שקורא במהירות, אבל המחרוזות כולן שם. שליפת endpoints מתוך JavaScript מוצאת לעיתים קרובות routes שלא מקושרים בשום מקום באפליקציה הגלויה, ושם בדיוק מתחבאים באגים של בקרת גישה.

#איסוף ה-bundles

טען את האפליקציה כש-dev tools פתוחים והסתכל בלשונית ה-network על קבצים שמסתיימים ב-.js. שמור את אלה שהאפליקציה טוענת. אתה יכול גם למשוך קובץ ישירות ברגע שיש לך את ה-URL שלו.

curl -s https://example.com/static/app.min.js -o app.min.js
wc -c app.min.js

שמור את הקבצים בתיקיית ההערות שלך לתוכנית. הישאר על ה-hosts שה-scope מפרט; bundle שמוגש מדומיין צד שלישי יכול להיות מחוץ ל-scope גם כשהאפליקציה שב-scope טוענת אותו.

#קריאת bundle עם המודל

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

grep -oE '"/[a-zA-Z0-9_/-]+"' app.min.js | sort -u > paths.txt

תן למודל את paths.txt ואת קריאות ה-fetch או axios שלידן, ובקש ממנו לקבץ את ה-paths ל-API routes סבירים, לנחש את ה-HTTP method, ולרשום את הפרמטרים שכל אחד נראה מקבל. NotHoly CLI יכול לקרוא את הקובץ ולעשות את זה בטרמינל, או שאתה יכול לשלוח אותו דרך chat completions API. המודל הופך קיר של מחרוזות לרשימה קצרה שאפשר לבדוק.

#ממחרוזות ל-endpoints שאתה מאמת

הרשימה של המודל היא אוסף ניחושים. אתה הופך כל ניחוש ל-request אמיתי דרך ה-proxy שלך וצופה במה שחוזר. path שמחזיר 401 בלי token ו-200 עם token הוא endpoint חי ששווה לבדוק. path שמחזיר 404 בכל מקום יכול להיות קוד מת שנשאר ב-bundle. אשר את ה-method ואת הפרמטרים על ידי שליחת ה-request בעצמך, כי המודל הסיק אותם מטקסט ויכול לטעות בשניהם.

#source maps כשהם קיימים

יש אפליקציות ששולחות source maps, שממפים את ה-bundle המוקטן בחזרה למקור קריא. הערת //# sourceMappingURL= בסוף bundle או קובץ .map תואם מצביעים על אחד. כש-map קיים ונמצא ב-scope, הוא עושה את הקוד קל בהרבה לקריאה, והמודל יכול לסכם לך מודולים שלמים. MDN מסביר source maps. התייחס לכל מה שאתה לומד מהם כאל רמז לאמת מול האפליקציה הרצה, כמו קודם.

#היזהר מהמצאת endpoints על ידי המודל

מודל שמתבקשים ממנו endpoints יפיק לפעמים כאלה סבירים שאינם בקובץ, כי המצאת path שנראה סביר היא בדיוק סוג הניחוש השוטף שהוא בנוי לייצר. ה-OWASP Top 10 for LLM Applications מונה את זה תחת הזיה והסתמכות יתר. הגן על עצמך בהרגל אחד: כל path שאתה בודק הגיע ממחרוזת שאתה יכול להצביע עליה ב-bundle, וכל method ופרמטר מאומתים על ידי response אמיתי. אם המודל נוקב ב-endpoint שאתה לא מוצא בקובץ, זרוק אותו.

#הבא במסלול

עכשיו יש לך רשימה מאומתת של endpoints ופרמטרים. בדיקת באגים נפוצים בווב בעזרת AI לוקחת את הרשימה הזו ועוברת על IDOR, XSS, SSRF ו-auth שבור. OWASP Web Security Testing Guide מחזיק את השיטה המלאה לכל מחלקה.