8.1 HTTP Protocol Fundamentals & Burp Suite Interception

8.1 HTTP Protocol Fundamentals & Burp Suite Interception

Web applications constitute one of the most prevalent and accessible attack surfaces encountered during penetration testing engagements. Unlike low-level network services that adhere to rigid binary protocols, web applications rely on the Hypertext Transfer Protocol (HTTP) to facilitate dynamic, asynchronous communication between client browsers and back-end application servers. To assess, audit, and exploit web vulnerabilities effectively, a penetration tester must understand the fundamental architecture of HTTP transactions and possess mastery over interception proxies—most notably Burp Suite.

Without an interception proxy, a security tester is constrained by client-side browser controls, such as JavaScript input validation, disabled HTML form fields, hidden inputs, and automatic redirection. By inserting an interception proxy directly between the client browser and the target web server, penetration testers gain full control over every byte of transmitted data, transforming standard web interactions into granular, manipulable security assessments.

---

HTTP Protocol Architecture & Lifecycle

HTTP is an application-layer protocol operating primarily over TCP port 80 for unencrypted plaintext transmission and TCP port 443 for Transport Layer Security (HTTPS). Standard HTTP operates according to a strict client-server request-response lifecycle.

+--------------------+            HTTP Request             +--------------------+
|                    | ----------------------------------> |                    |
|   Client Browser   |                                     |     Web Server     |
|    / Burp Proxy    | <---------------------------------- |  (Apache / Nginx)  |
+--------------------+            HTTP Response            +--------------------+

The Stateless Nature of HTTP

HTTP is inherently stateless. The web server does not inherently maintain persistent state, memory, or context between consecutive requests from the exact same client. Each request is evaluated independently in complete isolation.

To simulate state and track user identity across multi-page workflows (such as authentication, user sessions, and shopping carts), web applications implement state-management abstractions on top of HTTP. These mechanisms rely on:

• Session Identifiers: Random cryptographic tokens passed via the Cookie request header or URL parameters.
• JSON Web Tokens (JWT): Cryptographically signed tokens transmitted within the Authorization: Bearer <token> header.
• Hidden Form Inputs: Data elements embedded directly within HTML forms to persist identifiers across sequential submissions.

Understanding how state is maintained allows penetration testers to identify critical session vulnerabilities, including session fixation, broken authentication, and improper access controls.

Anatomical Structure of an HTTP Request

An HTTP request generated by a client conforms to a strict three-part syntactic structure:

POST /api/v1/auth/login HTTP/1.1
Host: target.corp.local
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: application/json, text/plain, */*
Content-Type: application/x-www-form-urlencoded
Content-Length: 39
Cookie: session_id=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
Connection: close

username=admin&password=SuperSecretPassword123

1. The Request Line: The initial line containing three distinct tokens separated by spaces:
   • Method: The action to be performed (e.g., GET, POST, PUT, DELETE).
   • Request-URI: The resource path on the target server (e.g., /api/v1/auth/login).
   • HTTP Version: The protocol specification utilized (most commonly HTTP/1.1 or HTTP/2).
2. Request Headers: Key-value pairs formatted as Header-Name: Header-Value followed by a Carriage Return and Line Feed (\r\n / CRLF). Headers convey operational context, client attributes, encoding preferences, cache controls, and authentication tokens.
3. CRLF Separator: A mandatory empty line (\r\n) explicitly signaling the termination of the header block.
4. Message Body: The raw data payload. In GET requests, the body is typically absent; in POST or PUT requests, it carries URL-encoded form parameters, JSON objects, XML trees, or multipart binary files.

Anatomical Structure of an HTTP Response

Upon receiving and processing the request, the web server returns an HTTP response structured identically in concept:

HTTP/1.1 200 OK
Date: Mon, 06 Oct 2026 12:00:00 GMT
Server: Apache/2.4.52 (Ubuntu)
Set-Cookie: auth_token=a1b2c3d4e5f6; Path=/; HttpOnly; Secure; SameSite=Strict
Content-Type: application/json; charset=UTF-8
Content-Length: 48
Connection: close

{"status":"success","message":"Authenticated"}

1. The Status Line: Specifies the HTTP protocol version, a 3-digit numeric Status Code indicating transaction outcome, and a human-readable Reason Phrase (e.g., HTTP/1.1 200 OK or HTTP/1.1 404 Not Found).
2. Response Headers: Server-supplied metadata detailing server software (Server), response formatting (Content-Type), payload byte size (Content-Length), and cookie assignment directives (Set-Cookie).
3. CRLF Separator: The mandatory empty line.
4. Response Body: The requested data payload rendered to the user, including HTML source code, CSS stylesheets, client-side JavaScript, images, or REST API data representations.

---

HTTP Methods in Penetration Testing

HTTP methods instruct the server on the operational intent of the incoming request. While web browsers typically emit only GET and POST, modern RESTful APIs and poorly configured servers support a broader method repertoire.

+-------------+---------------------------------------+------------------+-----------------+
| HTTP Method | Core Operational Purpose              | Idempotent?      | Primary Risk    |
+-------------+---------------------------------------+------------------+-----------------+
| GET         | Retrieve data from server             | Yes              | URL Parameter   |
|             | Parameters exposed in URL query string|                  | Logging / Leak  |
+-------------+---------------------------------------+------------------+-----------------+
| POST        | Submit data to be processed by server | No               | Injection / CSRF|
|             | Parameters carried in message body    |                  | Logic Flaws     |
+-------------+---------------------------------------+------------------+-----------------+
| PUT         | Replace or upload resource at URI     | Yes              | Arbitrary File  |
|             | Overwrites target file content        |                  | Upload / Shell  |
+-------------+---------------------------------------+------------------+-----------------+
| DELETE      | Remove specified resource from server | Yes              | Unauthorized    |
|             | Deletes target file from filesystem   |                  | Data Deletion   |
+-------------+---------------------------------------+------------------+-----------------+
| HEAD        | Retrieve headers only (no body)       | Yes              | Header / Cache  |
|             | Identical to GET but suppresses payload|                 | Enumeration     |
+-------------+---------------------------------------+------------------+-----------------+
| OPTIONS     | Query supported communication methods | Yes              | Verb Tampering  |
|             | Returns Allow header with method list |                  | Info Disclosure |
+-------------+---------------------------------------+------------------+-----------------+

GET Requests

GET requests are intended exclusively for data retrieval without causing state changes on the server. Parameters are appended directly to the URL string following a question mark (?) as key-value pairs separated by ampersands (&):

GET /search.php?query=penetration+testing&category=books HTTP/1.1

Because parameters reside directly inside the URL, they are stored in browser navigation histories, proxy logs, web server access logs (access.log), and outbound Referer headers. Sensitive parameters (such as passwords, credit card numbers, or session tokens) must never be transmitted via GET.

POST Requests

POST requests submit entity payloads to the server for processing. Parameters reside inside the message body rather than the URL. This prevents sensitive data from leaking into server access logs and browser histories. Penetration testers frequently target POST handlers during login brute-forcing, SQL injection, cross-site scripting (XSS), and command injection audits.

PUT & DELETE Requests

PUT requests instruct the web server to take the entity enclosed in the request body and store it directly at the specified URL path. If a web server enables PUT without strict authentication controls (frequently observed on misconfigured WebDAV endpoints or test servers), an attacker can upload arbitrary server-side executable files—such as a PHP or ASP webshell—directly to the web root. DELETE requests remove resources at the targeted path; improper authorization can allow malicious file elimination.

HEAD & OPTIONS Requests

• HEAD requests ask the server to return the exact headers that a GET request would produce, while completely omitting the response body. Penetration testers use HEAD during web content discovery because it verifies resource existence and extracts headers (Content-Length, ETag, Last-Modified) without the network overhead of downloading large files.
• OPTIONS queries the server for supported communication capabilities. The server returns an Allow header:

  HTTP/1.1 200 OK
  Allow: GET, HEAD, POST, PUT, DELETE, OPTIONS
  

  If dangerous methods like PUT or DELETE are listed, testers immediately verify whether those methods can be invoked without credentials (HTTP Verb Tampering).

---

Critical HTTP Headers for Security Auditing

HTTP headers govern caching, routing, parsing, and security enforcement. Testers inspect and manipulate several high-impact headers during assessments.

1. Host

The Host header is mandatory in HTTP/1.1 and specifies the target domain name and port number (e.g., Host: int-portal.corp.local). Because modern web servers use virtual hosting (vhosts) to serve dozens of websites from a single physical IP address, the web server evaluates the Host header to route the incoming connection to the appropriate application directory. Manipulating or brute-forcing the Host header enables penetration testers to discover unlisted internal virtual hosts or trigger Host Header Injection attacks (such as password-reset poisoning).

2. User-Agent

The User-Agent header identifies the client application, operating system, and rendering engine. Developers frequently implement routing logic based on User-Agent—for instance, serving distinct mobile interfaces when a smartphone agent is detected. Penetration testers alter User-Agent strings to simulate mobile devices, evaluate bot-mitigation rules, or test for SQL injection and XSS vulnerabilities in logging mechanisms that store user agent strings in administrative dashboards.

3. Cookie and Set-Cookie

The server transmits Set-Cookie to assign state to a client browser. The browser subsequently echoes these key-value pairs back via the Cookie header on every outbound request. Security testers analyze Set-Cookie directives for critical protective flags:

• Secure: Instructs the browser to transmit the cookie exclusively over encrypted TLS (HTTPS) channels, preventing plaintext interception across unencrypted networks.
• HttpOnly: Restricts client-side scripts (such as JavaScript) from accessing the cookie through document.cookie. This mitigates session hijacking through Cross-Site Scripting (XSS).
• SameSite: Controls whether cookies are sent with cross-site requests (Strict, Lax, or None), providing defenses against Cross-Site Request Forgery (CSRF).

4. Content-Type

Content-Type specifies the MIME media type of the enclosed payload body. If the Content-Type does not match the actual data formatting, the back-end parser may fail to process the request or trigger an unhandled exception:

• application/x-www-form-urlencoded: Standard format for HTML forms. Keys and values are encoded in URL-safe syntax (key1=val1&key2=val2).
• multipart/form-data: Used for file uploads and mixed binary submissions. Data parts are separated by defined boundary strings (boundary=----WebKitFormBoundary...).
• application/json: Used by modern REST APIs and Single Page Applications (SPAs). Transmits serialized JSON payloads ({"user":"admin","pass":"secret"}).
• application/xml or text/xml: Transmits XML payloads, presenting attack surfaces for XML External Entity (XXE) injection.

5. Authorization

The Authorization header conveys authentication credentials to the server. Under HTTP Basic Authentication, credentials take the format Basic <base64_encoded_string>, where the string represents username:password encoded in Base64 (e.g., Basic YWRtaW46cGFzc3dvcmQ=). Under token-based systems, Authorization: Bearer <jwt_token> carries signed authentication tokens.

---

HTTP Status Codes & Penetration Testing Significance

HTTP status codes provide real-time feedback regarding the operational state of the web application. Interpreting these codes accurately allows penetration testers to distinguish between active endpoints, authentication barriers, and exploitable back-end errors.

---

Burp Suite Setup & Interception Proxy Architecture

Burp Suite, developed by PortSwigger, is the industry-standard integrated graphical platform for web application security testing. While command-line utilities like curl and gobuster provide targeted automation, Burp Suite serves as the primary workbench for intercepting, analyzing, and tampering with application traffic.

+------------------+         Plain HTTP / Decrypted TLS        +------------------+
|                  | ========================================> |                  |
|  Web Browser     |                                           |    Burp Suite    |
|  (FoxyProxy)     | <======================================== |    Proxy Engine  |
+------------------+         Intercept & Manual Tamper         +------------------+
                                                                        ||
                                                                        || Raw Network
                                                                        || Packets
                                                                        \/
                                                               +------------------+
                                                               |                  |
                                                               |    Target Web    |
                                                               |      Server      |
                                                               +------------------+

Proxy Listener Architecture

Burp Suite's core engine functions as an HTTP/HTTPS forward proxy listener. By default, Burp initializes a listener bound to loopback interface address 127.0.0.1 on TCP port 8080.

To route browser traffic through Burp:

1. Configure Browser Proxy Settings: Manually configuring browser network proxy settings to 127.0.0.1:8080 routes all outbound requests to Burp. To streamline this workflow during assessments, penetration testers utilize browser extensions like FoxyProxy Standard for Mozilla Firefox or Google Chrome. FoxyProxy allows one-click switching between direct internet access and the Burp Suite proxy listener.
2. Burp Embedded Browser: Modern versions of Burp Suite include a pre-configured Chromium browser accessible under the Proxy -> Open Browser button. The embedded browser is automatically configured to route traffic through the proxy listener and bypasses certificate trust issues without manual setup.

Decrypting HTTPS Traffic: CA Certificate Installation

When a browser accesses an encrypted HTTPS website (e.g., https://target.corp.local), the connection is protected by TLS encryption. If an intermediary tool intercepts this connection without proper cryptographic credentials, the browser detects a man-in-the-middle (MITM) condition and halts the connection with severe security warnings (SEC_ERROR_UNKNOWN_ISSUER or MOZILLA_PKIX_ERROR_MITM_DETECTED).

To decrypt, inspect, and modify HTTPS traffic seamlessly, Burp Suite acts as an authorized MITM proxy:

1. Burp dynamically generates an SSL/TLS certificate for every targeted website browsed.
2. These dynamic certificates are cryptographically signed by Burp Suite's private Root Certificate Authority (CA).
3. Because the client browser does not inherently trust PortSwigger's custom CA, the tester must export Burp's root CA certificate and import it into the browser's permanent trust store.

Step-by-Step CA Certificate Installation Workflow:

1. Ensure Burp Suite is running with its proxy listener active on 127.0.0.1:8080.
2. With browser traffic proxied through Burp, navigate to the internal portal URL: http://burp/.
3. Click on the CA Certificate button in the upper-right corner of the web interface to download the file cacert.der.
4. Open Mozilla Firefox settings and navigate to Privacy & Security -> Certificates -> View Certificates.
5. Select the Authorities tab and click Import.
6. Select the downloaded cacert.der file from your filesystem.
7. In the prompt dialog, check the box: "Trust this CA to identify websites" and click OK.
8. Restart the browser. All subsequent HTTPS sessions routed through Burp will now be decrypted and inspected transparently without certificate warnings.

---

Intercepting and Modifying In-Flight Traffic

The primary interface for inspecting and tampering with web requests is the Proxy -> Intercept tab in Burp Suite.

The Intercept Workflow

• Intercept is on: Burp halts every outbound HTTP request generated by the browser before it reaches the network. The request is rendered in the text editor, allowing the penetration tester to review parameters, headers, and cookies.
• Forward: Transmits the currently displayed request (including any modifications made by the tester) across the network to the destination web server.
• Drop: Discards the request immediately. No packet is sent to the target server, and the browser displays a connection closed notification. This is useful for stopping accidental logging requests or malicious scripts.
• Intercept is off: Burp operates in passive pass-through mode. All requests and responses flow freely between the browser and target server without pausing, while continuing to be recorded in the HTTP History log.

Practical Request Tampering Scenarios

In-flight interception allows testers to bypass client-side security controls effortlessly:

1. Hidden Field Modification: Web forms often embed hidden values such as <input type="hidden" name="role" value="user"> or <input type="hidden" name="price" value="199.99">. Browsers do not display these fields to the user, but submit them upon form submission. With interception active, the tester edits role=user to role=admin or changes price=199.99 to price=0.01 before clicking Forward.
2. Parameter Tampering & IDOR: When clicking a profile link, the browser may request /account?id=105. The tester intercepts the request and alters the parameter to /account?id=1 to test for Insecure Direct Object References (IDOR).
3. Bypassing Client-Side Validation: If client-side JavaScript restricts form input to numbers only or enforces length limits, the tester enters valid data into the browser to satisfy JavaScript validation, intercepts the resulting request in Burp, replaces the data with a malicious SQL injection or XSS payload, and forwards it directly to the server.

The HTTP History Log

The HTTP History tab records a complete, chronological audit log of every request and response transmitted through the proxy. Even when interception is disabled, the history captures all endpoints, parameters, status codes, and payload sizes. Clicking any row in the history table displays the exact raw request and response pair. The history can be filtered by file extension, HTTP status code, search keyword, or MIME type to locate target interactions quickly.

---

Burp Repeater: Manual Parameter Manipulation

While the Proxy Intercept tab is ideal for intercepting traffic during interactive site exploration, testing complex injection payloads through the browser is slow and cumbersome. The browser automatically manages caching, reloads entire page DOMs, executes client-side scripts, and triggers unwanted background requests.

To conduct rigorous, repeatable manual testing, penetration testers send requests to Burp Repeater.

Sending Requests to Repeater

A request can be sent to Repeater from virtually anywhere in Burp Suite:

• From the Proxy -> Intercept tab or Proxy -> HTTP History log, right-click the request and select Send to Repeater (or press the global hotkey Ctrl+R on Linux/Windows or Cmd+R on macOS).
• The Repeater tab header will highlight, indicating a new numbered sub-tab has been created containing the captured request.

The Repeater Workflow

+---------------------------------------+---------------------------------------+
| BURP REPEATER: REQUEST PANE           | BURP REPEATER: RESPONSE PANE          |
+---------------------------------------+---------------------------------------+
| POST /api/user/update HTTP/1.1        | HTTP/1.1 500 Internal Server Error    |
| Host: target.corp.local               | Date: Mon, 06 Oct 2026 12:05:00 GMT   |
| Content-Type: application/json        | Server: Apache/2.4.52 (Ubuntu)        |
| Content-Length: 32                    | Content-Type: text/html               |
|                                       | Connection: close                     |
| {"username":"admin' OR '1'='1"}       |                                       |
|                                       | <h1>Database Error: syntax error</h1> |
+---------------------------------------+---------------------------------------+
| [ Send ] (Ctrl+Space)                 | Status: 500 | Length: 1420 | Time: 42ms|
+---------------------------------------+---------------------------------------+

1. Targeted Payload Editing: The tester directly edits headers, cookies, or body parameters in the left-hand Request pane.
2. Instant Transmission: Clicking the Send button (or pressing Ctrl+Space) transmits the raw request over a fresh TCP socket directly to the server.
3. Response Inspection: The server's unrendered response appears immediately in the right-hand Response pane. The tester observes the exact HTTP status code, response time (in milliseconds), payload byte length, and raw response body.
4. Iterative Fuzzing: The tester can adjust a single quote, add a comment delimiter (-- -), change an authorization token, and hit Send again within seconds. Repeater maintains a local history (navigable via the < and > arrow buttons) of all modifications and responses sent during that session.

Response Display Views in Repeater

Burp Repeater provides several viewing modes to examine response bodies:

• Pretty: Formats raw HTML, XML, or JSON with syntax highlighting and collapsible blocks for rapid human readability.
• Raw: Displays the exact byte stream returned by the server, including raw CRLF line endings.
• Hex: Renders the response in a hexadecimal editor view, allowing analysis of non-printable binary characters, compressed streams, or subtle byte offsets.
• Render: Utilizes an internal lightweight rendering engine to display the visual web page as a browser would see it, without executing outbound script calls.

---

Target Scope & Core Burp Suite Modules

During a penetration test, modern web applications generate substantial ambient network noise. Browsers constantly execute background requests to third-party CDNs, analytics providers (Google Analytics, Cloudflare), advertising networks, and telemetry servers. Permitting these out-of-scope requests to flood your Burp history clutters your workspace and introduces legal risk if automated testing modules inadvertently probe unauthorized third-party infrastructure.

Defining Target Scope

1. In the Target -> Site map tab, locate the target domain (e.g., http://target.corp.local).
2. Right-click the host node and select Add to scope.
3. Burp will display a prompt asking whether to stop sending out-of-scope items to the history. Selecting Yes configures the suite to filter noise automatically.
4. In the Target -> Scope tab, you can view, edit, and define granular scope rules using prefix matching or regular expressions (e.g., restricting scope strictly to ^https://.*\.corp\.local(:443)?/.*).
5. In the Proxy -> HTTP History tab, click the filter bar above the table and select the checkbox "Show only in-scope items". All third-party telemetry and out-of-scope requests will immediately disappear from your view.

Overview of Core Burp Suite Tabs