Metasploit (07-02) gave us command of network and system exploitation, but a large part of the TechNova S.L. audit revolved around its web application: the store tienda.technova.lab. In Module 4 we found a SQL injection there in producto.php?id= and tested parameters and headers in passing, mentioning an intercepting proxy as the instrument that made it possible. That instrument, the industry standard for web testing, is Burp Suite, and now we study it in depth.

This lesson covers Burp's architecture (Proxy, Target, Repeater, Intruder, Decoder, Comparer, and the Pro edition's Scanner), how to configure the browser and the CA certificate to intercept HTTPS traffic, and a workflow for testing the TechNova store: intercept a request, replay it modified, and fuzz a parameter such as producto.php?id=. We compare Community vs. Professional and, in passing, against OWASP ZAP (which we will study in depth in 07-04). We do not repeat the theory of web vulnerabilities here (that was Module 4): we focus on operating the tool. As always, everything is done against authorized targets or your lab.

1. What Burp Suite is and what it is for
2. Architecture: the tools in the suite
3. Configuration: browser and CA certificate
4. Workflow against the TechNova store
5. Repeater and Intruder: replay and fuzz
6. Community vs. Professional
7. Common Mistakes and Tips
8. Exercises
9. Conclusion

Burp Suite (PortSwigger) is an integrated platform for testing the security of web applications. Its centerpiece is an intercepting proxy: it sits between your browser and the server, so that all requests and responses pass through Burp, where you can view them, halt them, modify them, and forward them.

That "in the middle" position is what makes Burp the scalpel of web testing: it lets you manipulate hidden parameters, headers, cookies, and request bodies that the browser does not expose. It is the tool with which almost everything we studied in web exploitation is discovered and manually confirmed.

Burp is not a single program, but a set of tools that share the captured traffic.

The natural flow is: the Proxy captures the traffic, which appears in Target as a sitemap; you send interesting requests to Repeater (manual testing) or Intruder (automated testing); you use Decoder and Comparer as support. The Scanner (Pro only) automates discovery, but manual analysis with the other tools is the heart of the work.

For Burp to see the traffic, you have to do two things: point the browser at Burp's proxy and install its CA certificate to be able to intercept HTTPS.

a) Point the browser at the proxy. Burp listens by default on 127.0.0.1:8080. You configure the browser (or Burp's embedded browser) to use that proxy.

The simplest approach is to use Burp's embedded browser (Proxy tab → Intercept → "Open Browser"), which comes preconfigured and does not interfere with your normal browsing.

b) Install Burp's CA certificate. HTTPS traffic is encrypted; to read it, Burp acts as a consented man-in-the-middle, presenting certificates signed by its own certificate authority (CA). If the browser does not trust that CA, you will see certificate errors. You fix it by installing Burp's CA:

Security note: that CA certificate gives Burp the ability to decrypt your HTTPS. Install it only on your work/lab machine and remove it when you stop using Burp on that profile. Never install it on someone else's device without permission: that would be enabling a non-consented interception.

We reproduce the web work from Module 4, now operating Burp fluently, against our lab's store (tienda.technova.lab, resolved to an isolated VM).

Step 1 — Define the scope. In Target → Scope, add tienda.technova.lab. This way Burp focuses on the authorized target and does not clutter the sitemap with unrelated traffic (analytics, CDNs). Working within scope is also ethical discipline: you only touch what you have permission to touch.

Step 2 — Browse and map. With the proxy active, browse the store: categories, product pages, login, cart. Each action fills in Target's sitemap. When you open a product page you will see the key request:

Step 3 — Intercept and observe. In Proxy → Intercept you enable interception to freeze a request before it leaves. You see and can edit each part: the URL, the id parameter, the cookies, the headers. This is where the id=14 parameter reveals itself as a candidate for manipulation.

Step 4 — Send to Repeater. Right-click the request → Send to Repeater. From here on, the manual testing.

Repeater is for fine, manual work: you edit the request, send it, read the response, adjust, and repeat. It is the tool for confirming a vulnerability by hand. Against producto.php?id=, you would try variations of the parameter and watch how the response changes:

A single quote triggering a database error is the same sign of SQL injection we detected in Module 4. Repeater lets you verify that behavior request by request, without reloading the browser or losing context.

Intruder automates the above: you define payload positions in the request and a list of values, and Burp tries them in a loop. It is the suite's fuzzing.

With a list of values (1, 2, 3, ... , 1 OR 1=1, ' OR '1'='1), Intruder sends one request per value and tabulates status code, length, and response time. Differences in those columns give away anomalous behavior: an id that returns more data than usual, a payload that triggers an error, a suspiciously sized response.

• Community: Intruder works but is throttled, enough for learning.
• Professional: Intruder at full speed and with the automatic Scanner.

Responsible use: fuzzing generates many requests and can degrade a service. In a real engagement you control the rate and respect the agreed window; in your lab you can practice without limits because the server is yours. Defensive angle: a WAF and good logging detect and stop exactly this kind of burst; practicing them also teaches you to defend against them.

To train and do manual testing, Community is more than enough. The jump to Professional is justified when you work professionally and need the Scanner and unlimited Intruder. Its free and complete alternative is OWASP ZAP, which we will study in the next lesson: where Burp Pro costs a license, ZAP offers free active scanning and a better fit for automation. Each has its place; we will see this in detail in 07-04.

• Forgetting the CA certificate. Without installing Burp's CA, HTTPS throws certificate errors and you do not see the encrypted traffic. Install it on your work machine (and only there).
• Interception always on. Leaving Intercept "on" freezes every request and makes it look like "the browser is not loading." Leave it off except when you want to capture something specific.
• Not defining scope. Without scope, the sitemap fills up with third-party domains and you risk testing outside what is authorized. Define the scope at the start.
• Fuzzing production without control. Intruder can saturate a real service. Control the speed, respect the window, and practice thoroughly in your lab.
• Installing the CA on other people's devices. That is enabling a non-consented interception. Only on your own machine/profile, and remove it when you finish.
• Tip: learn to move requests with "Send to Repeater/Intruder." The Proxy → Repeater → Intruder flow is 80% of the daily work with Burp.

Exercise 1. Describe the steps to get Burp ready to intercept the HTTPS traffic of your lab store: proxy configuration, CA certificate, and scope definition. Explain why the CA certificate is essential and what precaution you would take with it.

Exercise 2. You have the request GET /producto.php?id=14 in the sitemap. Explain how you would use Repeater to look for signs of SQL injection by hand and what response would make you suspicious. Then indicate how you would automate it with Intruder.

Exercise 3. A colleague wants to buy Burp Professional to "practice at home." Argue whether they need it to learn and what alternatives they have, mentioning Community and OWASP ZAP.

Solution 1. (1) Start Burp and use its embedded browser, or configure the browser to use the proxy 127.0.0.1:8080. (2) With the proxy active, visit http://burpsuite, download the CA Certificate, and import it into the browser/OS trusted authorities store. (3) In Target → Scope, add tienda.technova.lab to limit the work to the authorized target. The CA certificate is essential because HTTPS traffic is encrypted; without trusting Burp's CA, the browser rejects the interception with certificate errors. Precaution: install it only on my lab machine and remove it when I finish, since it grants Burp the ability to decrypt HTTPS.

Solution 2. With Repeater: I send the request to Repeater, change id=14 to id=14' (a single quote), and observe the response; if a SQL error or an HTTP 500 appears where there was a product before, it is a sign of SQL injection. I would refine it with id=14 AND 1=1 (normal) vs. id=14 AND 1=2 (different) to confirm the behavior. With Intruder: I mark the position id=§14§, load a payload list (1, 2, ' OR '1'='1, 1 AND 1=2, ...), and launch the attack; I compare the status code, length, and time of each response: the anomalous rows give away the injection. In Community I would do it throttled, which is enough for the lab.

Solution 3. To learn, they do not need Burp Professional: the Community edition includes Proxy, Target, Repeater, Decoder, Comparer, and Intruder (throttled), which amply covers the manual testing of a home lab. If they want free automatic scanning or unlimited Intruder, the alternative is OWASP ZAP, free and complete, with active scanning included. Buying Burp Pro is justified for professional work, not for practicing at home.

Burp Suite is the standard for web security testing, and its strength comes from a simple idea: place itself between the browser and the server to see and manipulate every request. We reviewed its architecture (Proxy, Target, Repeater, Intruder, Decoder, Comparer, and the Pro Scanner), how to configure the proxy and the CA certificate to intercept HTTPS, and a complete workflow against the TechNova store: define scope, map, intercept producto.php?id=, replay the request in Repeater to confirm the SQL injection by hand, and fuzz the parameter with Intruder. We saw that Community is enough to learn and that Professional adds Scanner and unlimited Intruder, always within the framework of working only against authorized targets.

Burp Pro has a licensing cost, and it is not always the right choice when the goal is to integrate web testing into automated pipelines. For that terrain there is a free, complete alternative built for automation. In the next lesson we study it: OWASP ZAP, and we compare it against Burp to know when to choose each one.