איך כותבים דוח פנטסט טוב

#מה זה דוח פנטסט

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

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

#למה הדוח חשוב

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

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

#חלקי הדוח

מבנה מעשי כולל שישה חלקים:

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

#כתיבת ממצא אחד

כל ממצא עונה על אותן שאלות, באותו סדר.

• כותרת. מה החולשה ואיפה היא. "Reflected cross-site scripting בפרמטר החיפוש" אומר לקורא יותר מ-"חולשת XSS". המאמר על cross-site scripting מסביר את סוג החולשה שמאחורי הדוגמה.
• נכס מושפע. ה-URL, ה-endpoint, הפרמטר, הרכיב או הגרסה המדויקים.
• שלבי שחזור. שלבים ממוספרים שאדם זר יכול לעקוב אחריהם מ-session נקי בדפדפן. בכל שלב שתלוי בבקשה, צריך לכלול את הבקשה המדויקת.
• ראיות. הוכחה שהשלבים עבדו: צילום מסך, או הפלט של curl -i, בלי סודות. כדאי למספר כל ראיה כדי שהשלבים יוכלו להפנות אליה.
• השפעה. מה תוקף יכול לעשות בתנאים שאומתו.
• חומרה. וקטור CVSS v4.0 והדירוג שלו, מחושבים ממה שאומת.
• תיקון. תיקון ספציפי, ובדיקה שמראה שהוא עובד.

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

#לתאר השפעה בלי להגזים

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

#פלט של סורק הוא כיוון לבדיקה, לא ממצא

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

#דירוג חומרה עם CVSS v4.0

מפרט CVSS v4.0 מגדיר קבוצת מדדי Base עם שני צדדים. מדדי הניצול הם attack vector (AV), attack complexity (AC), attack requirements (AT), privileges required (PR) ו-user interaction (UI). מדדי ההשפעה מכסים את המערכת הפגיעה (VC, VI, VA) ואת המערכות העוקבות (SC, SI, SA). מחרוזת וקטור מתחילה בערך CVSS:4.0 ומפרטת כל מדד בסיס.

טווחי החומרה האיכותיים הם None ב-0.0, Low מ-0.1 עד 3.9, Medium מ-4.0 עד 6.9, High מ-7.0 עד 8.9, ו-Critical מ-9.0 עד 10.0.

יש ארבעה סוגי ציונים, לפי קבוצות המדדים שבהן השתמשו: CVSS-B ל-Base בלבד, CVSS-BT ל-Base ו-Threat, CVSS-BE ל-Base ו-Environmental, CVSS-BTE לשלושתם. דוח ראשון נושא בדרך כלל ציון Base, ולכן צריך לסמן אותו CVSS-B ולא להציג אותו כדירוג סיכון מלא.

משתמשים במחשבון הרשמי בכתובת https://www.first.org/cvss/calculator/4.0 כדי לבנות את הווקטור ולקבל את הציון. בדוח צריך להופיע הווקטור ולא רק המספר, כדי שהקורא יראה אילו הנחות נעשו. המחרוזת למטה מדגימה רק את הפורמט. זה לא ציון של אף ממצא במעבדה שלך:

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

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

#להשחיר סודות לפני ששולחים

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

Cookie: session=<REDACTED>
Authorization: Bearer <REDACTED>

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

#תרגול מעשי: ממצא אחד ממעבדת ה-Juice Shop שלך

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

#1. לוודא שהמעבדה מקומית

להריץ:

docker ps

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

docker run -d -p 127.0.0.1:3000:3000 bkimminich/juice-shop

אחר כך לבדוק שהמעבדה עונה:

curl -i http://127.0.0.1:3000

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

#2. לבחור בעיה אחת שאפשר לשחזר

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

#3. ללכוד את הראיות

להריץ מחדש את הבקשה עם curl -i כדי שהכותרות ייראו. להחליף את הנתיב בנתיב של הממצא שלך ולשמור את הפלט לקובץ:

curl -i "http://127.0.0.1:3000/<path-you-tested>" > evidence-01.txt

הדגל -i מדפיס את כותרות התשובה לפני הגוף. לקרוא את שורת הסטטוס, את הכותרת Content-Type וכל כותרת שהממצא שלך תלוי בה. אחר כך להשחיר כל טוקן או עוגייה בקובץ לפני ה-commit.

#4. למלא את התבנית

ליצור את הקובץ report.md במאגר המעבדה שלך ולהשתמש בתבנית הזו. להחליף כל placeholder במה שנצפה בפועל:

## Scope

- Target: http://127.0.0.1:3000, my own OWASP Juice Shop container
- Permission: I run this lab on a machine I own
- Dates: <start date> to <end date>
- Out of scope: everything else

## Finding title

<Flaw> in <exact location>

## Steps to reproduce

1. <Start from a clean browser session at http://127.0.0.1:3000>
2. <Exact action or request>
3. <What you see>

## Evidence

<Screenshot file name, or the redacted curl -i output file, matched to the steps>

## Impact

<What you verified. What you did not verify, and the test that would check it.>

## CVSS vector

<CVSS:4.0 vector from the calculator, and its rating>

## Remediation

<The specific fix, and how to check that it works>

#5. לעשות commit לדוח

לפני ה-commit כדאי לבדוק מה Git עומד לרשום, כדי שקובץ לא מושחר לא יחמוק פנימה:

git add report.md
git status
git commit -m 'First lab finding'

לוודא את ה-commit עם git log --oneline -1. השורה צריכה להציג את ההודעה שלך. בסיום, לעצור את קונטיינר המעבדה עם docker stop <container-name>, ואז להריץ docker ps כדי לוודא שהוא כבר לא ברשימה.

#טעויות נפוצות

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

#איך ממשיכים

• לקרוא את NIST SP 800-115 במלואו. הפרסום זמין בחינם מ-NIST.
• לקרוא את פרק ה-Reporting של WSTG, החל ממבנה הדיווח ושיטות השמות.
• לקרוא את מפרט CVSS v4.0, מדד אחר מדד, לפני שמדרגים ממצא שבאמת משנה משהו.
• לתת את הממצא למישהו שלא כתב אותו ולבקש ממנו לשחזר אותו מהשלבים בלבד. אם זה לא מצליח, הממצא לא גמור.
• לקרוא את כללי ההתנהלות לפני בדיקה של כל מערכת שאינה בבעלותך. המאמר על כללי ההתנהלות בבאג באונטי מסביר איך תוכניות קובעות את המגבלות האלה.

#מקורות

• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment
• OWASP Web Security Testing Guide, Reporting
• Penetration Testing Execution Standard, Reporting
• FIRST, CVSS v4.0 Specification Document
• FIRST, CVSS v4.0 Calculator