Burp Suite: A Practical Introduction for Web Application Testing

Tools & Defense
2025.12.31
Time it takes to read this article 6 minutes.

Introduction / Overview

Burp Suite, built by PortSwigger, is the de-facto intercepting proxy for web application security testing. If you have done any web pentesting, taken the OSWE, or worked through the PortSwigger Web Security Academy, you have used it. This article is a practical walkthrough of the five capabilities you will use on almost every engagement: the proxy, Repeater, Intruder, Scanner, and extensions. By the end you should be able to capture and modify traffic, replay and tweak individual requests, automate fuzzing, run automated scans, and extend Burp with the BApp Store and custom code.

Legal & ethical disclaimer: Everything below is for education and for testing systems you own or are explicitly authorized to test under a signed scope/rules of engagement. Intercepting, fuzzing, or scanning third-party applications without written permission is illegal in most jurisdictions (e.g., the US CFAA, the UK Computer Misuse Act 1990). Use a deliberately vulnerable target for practice.

How it works / Background

Burp sits as a man-in-the-middle HTTP/HTTPS proxy between your browser and the target server. Your browser is configured to send traffic to Burp's listener (default 127.0.0.1:8080), Burp records and optionally pauses each request, and then forwards it upstream. For HTTPS, Burp terminates TLS locally using its own certificate authority (CA), then re-encrypts to the server. To avoid certificate errors, you install Burp's CA certificate (http://burp/cert, file name cacert.der) into your browser/OS trust store.

Burp Suite: A Practical Introduction for Web Application Testing diagram 1

Text description: the browser trusts Burp's CA, so Burp decrypts traffic, lets you inspect or modify it, then re-encrypts it to the real server and returns the response.

This same MITM pattern underpins many tooling decisions in offensive work, similar to how you tunnel and pivot traffic in network pivoting and tunneling.

Prerequisites / Lab setup

  • Burp Suite Community (free) or Professional (paid; Scanner and saved sessions are Pro-only).
  • A test target: OWASP Juice Shop or DVWA running locally.
  • A browser. Burp ships with an embedded Chromium ("Open Browser") that is pre-proxied and pre-trusts Burp's CA, so for a lab you can skip manual proxy config entirely.

Spin up Juice Shop in Docker:

docker run --rm -p 3000:3000 bkimminich/juice-shop
# now browse http://localhost:3000
Bash

Launch Burp and use Proxy > Open Browser. If you prefer your own browser, set its proxy to 127.0.0.1:8080 and install the CA:

# Export Burp's CA, then trust it (Linux example using the system store)
curl -s --proxy http://127.0.0.1:8080 http://burp/cert -o burp_ca.der
openssl x509 -inform der -in burp_ca.der -out burp_ca.pem
sudo cp burp_ca.pem /usr/local/share/ca-certificates/burp_ca.crt
sudo update-ca-certificates
Bash

Attack walkthrough / PoC

1. Proxy: capture and modify a request

In Proxy > Intercept, toggle "Intercept is on", then log in to Juice Shop. Burp pauses the POST /rest/user/login request so you can edit the JSON body before forwarding. Proxy > HTTP history keeps a searchable log of every request/response pair — this is where you spend most of your reconnaissance time. Right-click any request to Send to Repeater (Ctrl+R) or Send to Intruder (Ctrl+I).

2. Repeater: iterate on a single request

Repeater is for manual, surgical testing — change one parameter, resend, read the response. Classic use: probing for SQL injection in the login endpoint.

POST /rest/user/login HTTP/1.1
Host: localhost:3000
Content-Type: application/json
Content-Length: 44

{"email":"' OR 1=1--","password":"x"}
HTTP

Send it with Ctrl+Space (send) and watch for an authentication bypass or a verbose error. Repeater keeps a tab history so you can A/B test payloads. For deeper injection theory, see SQL injection fundamentals.

3. Intruder: automate fuzzing and enumeration

Intruder automates a request with payload positions marked by § symbols. Send a login request to Intruder, then in the Positions tab clear auto-markers and wrap the field you want to fuzz.

Attack types:

  • Sniper — one payload set, one position at a time (password spraying a single field).
  • Battering ram — same payload in all positions simultaneously.
  • Pitchfork — parallel payload sets (e.g., username[i] + password[i]).
  • Cluster bomb — every combination of multiple sets (credential brute force).

For a password-spray against a list of usernames using one common password, mark only the username field, choose Sniper, load a wordlist in Payloads, and Start attack. Sort the results by Status code or Length to spot the outlier response that signals success. Note that Community Edition throttles Intruder heavily; for real brute force at speed, ffuf or hydra is faster:

ffuf -w users.txt:USER -X POST -u http://localhost:3000/rest/user/login \
  -H "Content-Type: application/json" \
  -d '{"email":"USER@juice.sh","password":"Password1!"}' \
  -mc 200 -fr "Invalid"
Bash

4. Scanner: automated vulnerability discovery (Pro)

Burp Scanner (Professional only) crawls and audits an application for issues like XSS, SQL injection, SSRF, and misconfigurations. Start it with Dashboard > New scan, supply the target URL and scope, and optionally provide authenticated session handling so the crawler stays logged in. Configure Target > Scope carefully — an out-of-scope crawl can hit hosts you are not authorized to test. Results land in Dashboard and Target > Issues, each with a confidence rating and evidence. Treat Scanner output as a starting point: confirm every finding manually in Repeater before reporting it, because automated scanners produce false positives.

5. Extensions: BApp Store and custom code

The Extensions tab loads add-ons. The BApp Store has community extensions; high-value ones include:

  • Logger++ — richer, filterable request logging across all tools.
  • Autorize — automated authorization/IDOR testing by replaying requests with a low-privilege session.
  • JWT Editor / JSON Web Tokens — decode, tamper, and re-sign JWTs.
  • Active Scan++ — extra scan checks.
  • Param Miner — discovers hidden parameters and headers (web cache poisoning, host-header attacks).

Extensions run via the Montoya API (Java/Kotlin) or via Jython/JRuby for Python/Ruby. A minimal Montoya extension registers itself and can mutate every proxy request:

package example;

import burp.api.montoya.BurpExtension;
import burp.api.montoya.MontoyaApi;

public class HeaderTagger implements BurpExtension {
    @Override
    public void initialize(MontoyaApi api) {
        api.extension().setName("Header Tagger");
        api.proxy().registerRequestHandler(new TagRequestHandler(api));
    }
}
Java

Load it via Extensions > Add, type Java, and point at the built JAR.

Detection & Defense (Blue Team)

Burp itself is benign tooling, but the traffic it generates while testing — and while an attacker abuses it — has clear signatures. Defenders should focus on detecting MITM proxying and automated probing.

Detect interception and tampering

  • TLS pinning. Mobile and thick clients should pin the expected server certificate or public key. A pinned client rejects Burp's CA outright, breaking interception. (Pinning is a control for your own clients, not the test browser.)
  • Server-side validation only. Never trust client-side checks. Anything Burp can edit (hidden fields, price values, role flags, JS validation) must be re-validated on the server. Mass-assignment and IDOR bugs that Autorize finds are server-side authorization failures — enforce object-level access control on every request.

Detect fuzzing and scanning

  • Rate limiting and lockout. Intruder/ffuf brute force produces bursts of requests to one endpoint. Enforce per-account and per-IP rate limits, exponential backoff, and account lockout. CAPTCHAs after N failures blunt password spraying.
  • WAF and anomaly rules. A WAF (ModSecurity with the OWASP CRS, AWS WAF, Cloudflare) flags scanner payloads and abnormal request rates. Watch for tell-tale scanner artifacts: canary/collaborator domains, sequential payload patterns, and identical requests differing by one parameter.
  • Log the signals. In access logs, alert on: a single source IP generating thousands of 4xx/5xx responses, high request rate to login/search endpoints, and User-Agent or header anomalies. This maps to MITRE ATT&CK T1190 (Exploit Public-Facing Application) and T1110 (Brute Force).

Operational hardening

  • Set Burp Collaborator awareness: out-of-band SSRF/XXE detection relies on DNS/HTTP callbacks to a Collaborator domain. Egress filtering and DNS monitoring catch these callbacks — block outbound traffic from app servers to arbitrary internet hosts.
  • Maintain an inventory of authorized testing source IPs during engagements so the SOC can distinguish sanctioned pentest traffic from a real attacker. For broader monitoring strategy, see building a detection lab.

Conclusion

Burp Suite's power comes from a small, composable toolkit: the proxy captures everything, Repeater lets you reason about one request at a time, Intruder automates the repetitive cases, Scanner gives breadth (in Pro), and extensions close the gaps. Master the proxy and Repeater first — they cover the majority of manual testing — then layer in Intruder and extensions as the engagement demands. From the defensive side, almost every Burp-discovered bug traces back to a missing server-side control: validate on the server, enforce authorization per object, rate-limit aggressively, and monitor for the burst-and-probe patterns that automated tooling leaves behind.

References

Comments

Copied title and URL