bug bounty עם קופיילוט AI: הלולאה

bug bounty הוא בדיקה בתשלום בתוך הגבולות שתוכנית מגדירה. המסלול הזה לוקח אותך מאפס ועד לדוח תקף ראשון, כשמודל AI עושה את הקריאה ואת הניסוח ואתה מחזיק בשיקול הדעת ובכל דבר שמגיע ליעד. הפוסט הראשון הזה הוא הלולאה שאתה חוזר עליה בכל תוכנית. שאר המסלול נכנס לעומק בכל שלב, ואז בונה סוכן קטן שמריץ חלק מהלולאה בשבילך.

מודל הוא קורא מהיר וכתב סביר, בלי זיכרון של ה-scope שלך ובלי שום דבר לאבד בחשבון שלך. הוא יסכם מדיניות, יסדר רשימת endpoints, יסביר response מוזר וינסח דוח. הוא גם ימציא endpoint, יקרא status code לא נכון וישמע בטוח בזמן שהוא עושה את זה. אתה מתייחס לפלט שלו כאל רמז, אף פעם לא כאל finding.

#הלולאה

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

שלב	מה אתה עושה	איפה המודל עוזר
בחירה	לבחור תוכנית ונכס	לסכם את המדיניות, לסמן סעיפים חריגים
Scope	לקרוא מה בפנים ומה בחוץ	להפוך מדיניות ארוכה ל-checklist קצר
Recon	למפות את המשטח שמותר לגעת בו	לסדר endpoints, לקרוא JS, להציע פרמטרים
בדיקה	לשלוח requests ולקרוא responses	להסביר response, להציע את המקרה הבא
דיווח	לכתוב את הדוח	לנסח את הצעדים בזמן שאתה מאמת כל שורה

#בחירת תוכנית וקריאת ה-scope

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

#Recon בלי לגעת ב-hosts שמחוץ ל-scope

recon ממפה את המשטח שהתוכנית מרשה לבדוק. אתה אוסף subdomains, endpoints ופרמטרים, ואז מחליט איפה באג סביר. המודל שימושי לקריאה, לא ליצירת קשר עם היעד: הוא יכול לקבץ רשימת endpoints מבולגנת, לקרוא bundle של JavaScript מוקטן ולהצביע על פרמטרים ששווה לבדוק. שומרים כל scan וכל request על ה-hosts שה-scope מפרט. לכלים, הפוסט על ה-toolkit מקים טרמינל ששומר אותך בתוך ה-scope.

#בדיקה, ואז אימות לפני שמאמינים

הבדיקה היא המקום שבו מתחילים מאבדים זמן ל-false positives. המודל יגיד ש-response נראה כמו IDOR או XSS. לפעמים הוא צודק. אתה מאשר ביד: משחזר את ה-request, משנה דבר אחד, צופה ב-response ושומר את ה-request ואת ה-response המדויקים שמוכיחים את הבאג. באג שאתה לא יכול לשחזר מתי שתרצה הוא עדיין לא באג. בדיקת באגים נפוצים בווב בעזרת AI עוברת על IDOR, XSS, SSRF ו-auth שבור, כולל איך נמנעים מה-false positives שהמודל מגיש לך.

#כתיבת הדוח

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

#במה המודל טוב, ואיפה הוא משקר

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

#הבא במסלול

קרא איך בוחרים את התוכנית הראשונה, ואז הקם את ה-toolkit ואת הטרמינל. מקרה השימוש של bug bounty ו-OWASP Web Security Testing Guide הם שתי האסמכתאות ששווה להשאיר פתוחות כל הזמן. הפוסטים המאוחרים יותר בונים hackbot שמריץ recon ובדיקות על המחשב שלך, באישורך, בעזרת NotHoly CLI.