בדיקה חוזרת אחרי בדיקת חדירות: איך מאמתים שהממצאים תוקנו

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

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

מה ההבדל בין Retest לבדיקת חדירות חדשה?

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

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

איזה מידע מכינים לפני הבדיקה החוזרת?

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

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

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

איך מנהלים סטטוס שאפשר לפעול לפיו?

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

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

דוגמה לניהול תיקון בלי לאבד את ההקשר

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

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

מתי נכון להרחיב את הבדיקה?

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

שאלות על אימות תיקונים