בחירת תוכנית ה-bug bounty הראשונה שלך

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

#מה זו תוכנית

תוכנית bug bounty היא הצעה ציבורית. ארגון נוקב בנכסים שהוא רוצה שייבדקו, קובע את הכללים לבדיקתם ומגדיר פרסים על דוחות תקפים. המדיניות היא החוזה. כל מה שאתה עושה נשאר בתוך מה שהיא מפרטת, ודוח שחורג נסגר לא משנה כמה הבאג טוב. יש אתרים שמפרסמים גם קובץ security.txt תחת /.well-known/security.txt עם איש קשר וקישור למדיניות, שאומר לאן הדוחות הולכים.

#בתוך ה-scope ומחוץ לו

כל מדיניות מחלקת את העולם לנכסים שמותר לבדוק ולנכסים שאסור. ב-scope יש בדרך כלל אוסף דומיינים, wildcard domains, אפליקציות מובייל או APIs. מחוץ ל-scope נמצא כל השאר, ולעיתים קרובות הוא כולל שירותי צד שלישי שהארגון משתמש בהם אך לא בבעלותו. רשימת מה שמחוץ ל-scope חשובה למתחיל יותר מהרשימה שבתוך ה-scope, כי שם קורות התאונות. wildcard כמו *.example.com עדיין יכול להחריג hosts מסוימים, אז קוראים את שתי הרשימות יחד.

#הכללים שסוגרים דוחות

מעבר לרשימות הנכסים, מדיניות קובעת כללי התנהלות: מגבלות קצב, אם סריקה אוטומטית מותרת, אילו מחלקות באגים לא מזכות בפרס, ומה מותר לעשות בכל נתון שהגעת אליו. מחלקות נפוצות שמחוץ ל-scope עבור מתחילים הן self-XSS, חוסר ב-security headers בלי exploit, ודוחות מסורקים אוטומטיים בלי הוכחה ידנית. כללי ההתנהלות ב-bug bounty מסביר אותם במלואם.

#קריאת scope עם המודל, ואז בדיקה שלו

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

אות	ידידותי למתחיל	התחלה קשה יותר
גודל ה-scope	כמה דומיינים ברורים	wildcard נרחב
בשלות	תוכנית חדשה, פחות חוקרים	תוכנית בשלה, מסוקרת לעייפה
כללים	סריקה מותרת, מחלקות ברורות	מגבלות קצב הדוקות, הרבה החרגות
יעדים	אפליקציית ווב שאפשר להריץ גם מקומית	חומרה או אפליקציות native בלבד

#בחירת נכס שאפשר באמת לבדוק

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

#רישום ה-scope לפני שנוגעים בו

רשום את ה-scope במקום שהכלים שלך יכולים לבדוק, לא רק בזיכרון. NotHoly CLI יכול להחזיק את ה-scope להרצה עם notholy engage, והוא קורא את היעד מכל פקודה לפני שהפקודה רצה, כך ש-host שמחוץ ל-scope מבקש אישור שני. הפוסט על ה-toolkit מקים את זה. רישום ה-scope הופך כלל שאתה צריך לזכור לבדיקה שהטרמינל עושה בשבילך.

#בחירת הפלטפורמה

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

#הבא במסלול

אחרי שיש לך תוכנית ונכס, הקם את ה-toolkit ואת הטרמינל. החזק את OWASP Web Security Testing Guide ואת התנאים של disclose.io בהישג יד כאסמכתאות לאיך נראית בדיקה בתום לב.