הגדרת Burp Suite Enterprise: DAST, CI/CD, OAuth 2.0

הגדרת Burp Suite: היכן הסורק מפספס חולשות

הסורק פרוס, לוח הזמנים מוגדר, הדוחות מגיעים בקביעות — ובכל זאת חולשות ממשיכות לצוף בסביבת העבודה. הסיבה כמעט אף פעם אינה במנוע: הבעיה באופן שבו מוגדרים היעדים, הסשנים ורצף הפעולות. נבחן שלושה מקומות שבהם הגדרת Burp Suite הופכת כלי עבודה למחולל דוחות ירוקים פורמלית.

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

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

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

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

מה נותן Burp Suite מוגדר: כיסוי וניתוח ממצאים

סורק מוגדר נבדל מסורק שמופעל "כפי שהוא" בדבר אחד: הוא עובר באותם נתיבים שמשתמש חי עובר. אנחנו פותחים חשבונות עבור כל תפקיד, מעבירים סשן פעיל אל Burp Suite ומתארים נקודות כניסה — כולל אלה שנפתחות רק לאחר שרשרת מעברים.

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

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

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

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

מצבי סריקה: הרצה חד-פעמית, לוח זמנים, בנייה

הגדרת Burp Suite בסביבת העבודה היא בחירה לא של מצב אחד, אלא של שילוב שלהם. הרצה ידנית של בדיקה נדרשת נקודתית: לנתח תקרית, לבדוק שינוי גדול לפני פריסה, לאשר תיקונים לאחר שדרוג אימות.

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

מגבלות הבדיקות האוטומטיות

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

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

שלבי הטמעה: מתרשים סביבת הבדיקה ועד מסירת נהלים

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

1. ביקורת סביבה. מיפוי שירותים באזור הבדיקה, עותקי נתונים לבדיקה ובעלי יישומים. בפלט — רשימת יעדים ורשימה מפורשת של מה שהסורק לא נוגע בו.
2. תרשים סביבת הבדיקה. קובעים היכן ממוקם הסורק, כיצד הוא רואה את השירותים הנבדקים, האם יש די רוחב פס למצב פעיל. את התרשים מתאמים לפני ההגדרה — אחרת יהיה צורך לשנות נתיבים.
3. הגדרת גישה. חשבון שירות עם הרשאות מינימליות מספיקות, הפרדת נראות לפי פרויקטים, הימנעות מחשבונות אישיים. פרטי ההתחברות — במאגר מאובטח ומחוץ לדוחות.
4. הטמעה בצינור הבנייה. הרצה על הענף הנדרש, ספי חסימה לפי סוגי ממצאים, דוח בפורמט שהמפתח קורא בלי עריכה ידנית.
5. הרצת ניסיון. כיול כללים, סינון התראות שווא, השוואת התוצאה לבדיקה ידנית בשירות אחד.
6. אישור תוצאות הבדיקה. סט ייחוס שסוכם מראש נמצא שוב, הדוח משוחזר, ההרצה נכנסת לחלון. ההחלטה מתקבלת לפי קריטריונים, ולא לפי "נראה בסדר".
7. מסירת נהלים. הוראות הרצה, סדר עדכון כללים, תפקידים ונקודות הסלמה — צוות הלקוח ממשיך להפעיל את הסורק בעצמו.

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

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

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

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

מקרה בוחן: איך קיצרנו את הדרך מהממצא ועד התיקון

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

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

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

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

במה נבדלת סריקה שוטפת מבדיקה בבנייה?

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

הגדרת Burp Suite מתחילה בהפרדה בין המשימות האלה: יש להן מטרות שונות, תקציב זמן שונה וכללי ניתוח תוצאה שונים.

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

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

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

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

התלבטויות לפני התחלה: גישות, ממצאי שווא, עומס

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

האם זה לא יפיל את סביבת הבדיקה?

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

כמה ממצאי שווא יהיו?

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

מה עושים עם אימות לא סטנדרטי?

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

ספרו על המשימה — נחזור עם תוכנית והערכה

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

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

על בסיס זה נבנה תוכנית הטמעה של Burp Suite Enterprise: סדר החיבור לצינור הבנייה, מדיניות סריקה לפי סוגי יישומים, ספים שבהם הבנייה נעצרת, ותרשים ניתוח ממצאים עם אחראים. ההכנה להתחלה תיקח סבב תיאום אחד או שניים — משם נעבוד באיטרציות, ונציג תוצאה בכל שלב. תארו את המשימה בדרך הנוחה לכם, ונחזור עם הערכה ותוכנית.