בדיקת באגים נפוצים בווב בעזרת AI

עם רשימה מאומתת של endpoints מתוך קריאת ה-JavaScript, אתה יכול להתחיל לבדוק באגים אמיתיים. הפוסט הזה מכסה ארבע מחלקות שמתחיל מוצא מוקדם: IDOR, cross-site scripting, server-side request forgery ו-authentication שבור. המודל עוזר לך לקרוא responses ולהחליט על הבדיקה הבאה. אתה מריץ כל request ומאשר כל finding ביד. שמור את כל הבדיקות על ה-hosts שהתוכנית מפרטת, והשתמש בעותק מקומי של האפליקציה לכל דבר רועש.

#איך להשתמש במודל בזמן בדיקה

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

מחלקה	השאלה שאתה שואל	איך אתה מאמת
IDOR	אפשר להגיע לאובייקט של משתמש אחר?	שני חשבונות, להחליף את ה-id, להשוות responses
XSS	הקלט שלי רץ כקוד?	input שמשתקף רץ בדפדפן אמיתי
SSRF	השרת ימשוך URL שאני בוחר?	host שבשליטתך מתעד את ה-request של השרת
Broken auth	אפשר לפעול בלי ה-session הנכון?	request בלי token או עם תפקיד שגוי מצליח

#IDOR: שינוי המזהה, קריאת ה-response

insecure direct object reference הוא הבאג הידידותי ביותר למתחיל. מצא request עם מזהה בתוכו, כמו /api/orders/1051, ושנה את המספר. אם אתה מקבל בחזרה הזמנה של משתמש אחר, האפליקציה לא בודקת מי הבעלים שלה. הדרך הנקייה להוכיח זאת היא עם שני חשבונות שבשליטתך: משוך את האובייקט שלך, אחר כך נסה את המזהה של החשבון השני מתוך ה-session שלך, והשווה. המודל עוזר לך לזהות אילו שדות הם מזהים ואילו responses נבדלים בצורה שחשובה.

#XSS: איפה קלט חוזר כקוד

cross-site scripting קורה כשקלט שאתה שולח מוחזר לעמוד בלי encoding, כך שהדפדפן מריץ אותו כ-script. התפקיד שלך בבדיקה הוא למצוא מקום שבו קלט משתקף לתוך ה-response ולבדוק אם הוא נשאר נתון או הופך לקוד. מחרוזת סימון לא מזיקה אומרת לך אם, ואיך, הקלט שלך עובר encoding. הסבר על cross-site scripting מחזיק את הפרטים. המודל שימושי לקריאה של איך ערך משתקף ואיפה חסר encoding, אבל רק דפדפן אמיתי מוכיח הרצה, אז אשר שם.

#SSRF: איפה השרת מושך URL

server-side request forgery קורה כשהאפליקציה מקבלת ממך URL והשרת מושך אותו. חפש פיצ׳רים שמושכים משאב מרוחק: תמונה לפי URL, webhook, תצוגה מקדימה של קישור. כדי לבדוק בבטחה, הפנה את הפיצ׳ר ל-host שבשליטתך וצפה בלוגים שלך אחרי ה-request של השרת. אם השרת פונה החוצה, אישרת את ההתנהגות, וההשפעה תלויה במה שהרשת של השרת יכולה להגיע אליו. תאר רק את מה שהוכחת, ואל תצא לציד שירותים פנימיים מעבר למה שהתוכנית מתירה.

#authentication שבור ובקרת גישה

המחלקה הזו מכסה requests שאמורים לדרוש session תקף או תפקיד מסוים ולא דורשים. קח request מאומת, הסר את ה-token או החלף לחשבון עם הרשאה נמוכה יותר, וראה אם הוא עדיין עובד. באגים של בקרת גישה נפוצים, לעיתים קרובות בעלי השפעה גבוהה, וקל להוכיח אותם עם שני חשבונות. המודל יכול לעזור לך למנות אילו פעולות לנסות שוב בלי session, מתוך רשימת ה-endpoints שבנית קודם.

#אימות לפני שמאמינים

רוב הזמן המבוזבז בחודש הראשון של מתחיל הולך ל-false positives שהמודל עודד. שלושה הרגלים מונעים את זה. שחזר את הבאג ממצב נקי כדי לדעת שהוא אמיתי ולא קוריוז של cache. שנה משתנה אחד בכל פעם כדי לדעת מה גרם לתוצאה. שמור את ה-request וה-response המדויקים שמוכיחים אותו, כי זה מה שהדוח צריך ומה שה-triager יריץ שוב. אם אתה לא יכול לשחזר אותו מתי שתרצה, הוא עדיין לא finding.

#הבא במסלול

ל-APIs מגיעה שיטה משלהם. בדיקת API בעזרת AI מכסה OpenAPI ו-GraphQL. OWASP Top 10 ו-PortSwigger Web Security Academy הן האסמכתאות שכדאי לעבור עליהן לכל מחלקה.