Burp Suite

Overview

Burp Suite is PortSwigger's web application security testing platform. Its intercepting proxy captures and modifies HTTP/HTTPS traffic between browser and server. Includes: Scanner (automated vulnerability detection), Intruder (parameter fuzzing), Repeater (manual request modification), Sequencer (token randomness analysis), and Decoder (encoding/decoding). Burp Suite Community Edition is free and has no Scanner; Burp Suite Professional adds the Scanner and advanced automation; the former Enterprise Edition is now sold as Burp Suite DAST for CI/CD scanning at scale. PortSwigger also sells Burp AT, an agentic AI layer on top of Professional/DAST — none of the steps below depend on it.

Instructions

Step 1: Proxy Setup and Traffic Interception

1. Start Burp Suite → Proxy tab → Intercept is On
2. Configure browser proxy: 127.0.0.1:8080
3. Install Burp CA certificate for HTTPS interception:
   - Browse to http://burpsuite
   - Download CA certificate
   - Import into browser trust store

4. Browse the target application normally
   → Burp captures every request in HTTP History
   → Site map builds automatically from crawled pages

# Proxy → HTTP History shows all captured requests:
# Method  URL                              Status  Length
# GET     /api/v1/users/me                 200     1,247
# GET     /api/v1/projects                 200     8,432
# POST    /api/v1/projects                 201     523
# GET     /api/v1/projects/123/tasks       200     15,891
# PUT     /api/v1/tasks/456                200     312
# DELETE  /api/v1/tasks/789                403     89

# Right-click any request → Send to Repeater / Intruder / Scanner

Step 2: Repeater — Manual Testing

# Send a request to Repeater to modify and resend manually

# Test IDOR: Change user ID in the request
GET /api/v1/users/123/profile HTTP/1.1
→ Change to: GET /api/v1/users/124/profile HTTP/1.1
→ If 200 OK with different user's data → IDOR vulnerability

# Test privilege escalation: Use a captured regular-user session token on an admin endpoint
GET /api/v1/admin/users HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzQ0MiIsInJvbGUiOiJtZW1iZXIifQ.3fK9pQ2sL0xVYwZqJmR8NcT1uEoIhGaB4dWn7yXqP0M
→ If 200 OK → Broken access control

# Test input validation: Inject payloads
POST /api/v1/search HTTP/1.1
Content-Type: application/json

{"query": "' OR 1=1--", "limit": 10}
→ If different response → possible SQL injection

{"query": "<script>alert(1)</script>"}
→ If reflected in response → possible XSS

Step 3: Intruder — Automated Fuzzing

# Send request to Intruder → mark injection points with §

# IDOR enumeration: Fuzz user IDs
GET /api/v1/users/§1§/transactions HTTP/1.1
→ Payload: Numbers 1-1000
→ Filter: responses with status 200 and different lengths
→ Every 200 = accessible user's transactions

# Directory brute force
GET /§admin§/ HTTP/1.1
→ Payload: wordlist (common-dirs.txt)
→ Filter: status != 404

# Credential stuffing (authorized testing only)
POST /api/v1/auth/login HTTP/1.1
{"email": "§user@beacontowersecurity.com§", "password": "§Spr1ng2026!§"}
→ Payload type: Pitchfork (parallel lists)
→ Payload 1: email list, Payload 2: password list
→ Filter: status 200 or different response length

# Parameter fuzzing for injection
POST /api/v1/products HTTP/1.1
{"name": "§Wireless Mouse§", "category": "electronics"}
→ Payload: SQL/XSS/SSTI fuzzing wordlist
→ Monitor: response time (time-blind), errors (error-based), content changes

Step 4: Scanner (Professional Edition)

# Active scan crawls and tests automatically
# Target → Right-click → Scan

# Scanner checks for:
# - SQL injection (all techniques)
# - Cross-site scripting (reflected, stored, DOM)
# - Server-side request forgery (SSRF)
# - Server-side template injection (SSTI)
# - XML external entity injection (XXE)
# - Path traversal
# - OS command injection
# - Authentication flaws
# - Session management issues
# - Information disclosure

# Configure scan scope to stay within authorized targets:
# Target → Scope → Include: *.staging.beacontowersecurity.com

Step 5: Automation with Burp Extensions

# BApp Store extensions (essential for pentesting):

# Autorize — automatic authorization testing
# Tests every request with a different user's session
# Finds IDOR and privilege escalation automatically

# Logger++ — advanced request logging with filters
# Filter by regex, response codes, content types

# Param Miner — discovers hidden parameters
# Finds unlinked parameters that accept input

# Turbo Intruder — high-speed fuzzing (Python scripted)
# 10-100x faster than built-in Intruder

# JWT Editor — decode, modify, and forge JWT tokens
# Test: algorithm confusion, expired tokens, signature bypass

# Hackvertor — encoding/decoding in-line within requests
# Nest encodings: <@base64><@url>payload<@/url><@/base64>

Step 6: Export for Reporting

# Export findings:
# Target → Issues → Right-click → Report selected issues
# Format: HTML or XML
# Includes: severity, confidence, evidence, remediation

# Export requests for sqlmap or other tools:
# Right-click request → Copy to file → Save as .txt
# sqlmap -r saved-request.txt --batch

# Export sitemap for documentation:
# Target → Site map → Right-click → Save selected items

Examples

Example 1: "Check whether this API leaks other users' order history (IDOR)"

1. Log in as a low-privilege account, browse to GET /api/v1/orders/8842, and confirm it returns your own order.
2. Send the request to Repeater, change 8842 to a neighboring ID (8841), and resend.
3. If the response is 200 OK with another account's order data, send the request to Intruder, mark 8842 as an injection point (§8842§), and sweep a numeric range (1–10000) to measure how many IDs are exposed, filtering for 200 responses.

Result: a 200/404 split across the swept range shows exactly which order IDs are reachable without authorization — evidence for an IDOR finding, with the Intruder results table as supporting data for the report.

Example 2: "Find hidden parameters on a login endpoint before fuzzing it"

1. Send POST /api/v1/auth/login to the Param Miner extension (BApp Store → install → right-click the request → "Guess params" → "Guess JSON params").
2. Param Miner replays the request with candidate parameter names and flags any that change the response (for example, a hidden debug or bypass_mfa field).
3. Confirm a hit manually in Repeater by adding the discovered parameter and resending.

Result: Param Miner reports the parameter name it found a response difference for; manual confirmation in Repeater turns that signal into a reproducible finding before it goes into Intruder for further fuzzing.

Guidelines

• Scope your proxy — only intercept traffic to authorized targets. Exclude third-party domains.
• Repeater is your best friend for manual testing — modify one parameter at a time and observe responses.
• Intruder with wordlists finds IDOR, directory traversal, and injection points faster than manual testing.
• Always check authorization: send regular-user requests to admin endpoints (test with Autorize extension).
• Save your Burp project frequently — losing a 4-hour testing session is painful.
• Use macros for authenticated scanning — configure session handling rules to auto-login when session expires.
• Burp Scanner produces false positives — always manually verify findings before reporting.
• Combine with sqlmap: export the exact request from Burp (-r request.txt) for targeted injection testing.