Understanding Request Smuggling: A Hidden Web Vulnerability (K-Edition)

What is Request Smuggling?

Request smuggling is a web vulnerability that allows attackers to manipulate the way web servers handle HTTP requests. By sending specially crafted requests, attackers can trick servers into processing requests in unexpected ways, which can lead to unauthorized access to data or other malicious actions.

Why is Request Smuggling Hard to Detect?

Complex to Spot: Request smuggling exploits subtle differences in how servers process HTTP requests. These differences are not always obvious, making the vulnerability hard to detect with standard tools.

Server Configuration Matters: The vulnerability relies on how front-end and back-end servers communicate. Different server setups can affect whether the vulnerability is present, leading to inconsistent detection during tests.

Limited Testing: Regular security testing might not cover all possible scenarios or server interactions, meaning some cases of request smuggling can go unnoticed.

Real-Time Exploitation: Exploiting request smuggling often requires a deep understanding of the target server’s behavior and real-time interaction, making it less likely to be spotted during automated scans.

Examples of Request Smuggling

Example 1: Content-Length vs. Transfer-Encoding

An attacker sends a request to a front-end server that supports the Transfer-Encoding header but sends it to a back-end server that uses the Content-Length header.

1. Request Sent by Attacker:

POST / HTTP/1.1
Host: example.com
Content-Length: 13
Transfer-Encoding: chunked

POST /evil HTTP/1.1
Host: example.com
Content-Length: 4

data

2. Front-End Server Interpretation:
The front-end server processes the request using Transfer-Encoding: chunked` and forwards only the body `0\r\n\r\nPOST /evil HTTP/1.1\r\nHost: example.com\r\nContent-Length: 4\r\n\r\ndata to the back-end server.

3. Back-End Server Interpretation:
• The back-end server processes the forwarded request using Content-Length: 13, misinterpreting it as two separate requests:
• The first part is POST / HTTP/1.1\r\nHost: example.com\r\n\r\n, which is a valid request.
• The second part is POST /evil HTTP/1.1\r\nHost: example.com\r\nContent-Length: 4\r\n\r\ndata, which is also a valid request.

Example 2: HTTP/1.1 vs. HTTP/2

An attacker sends a request to a front-end server that uses HTTP/1.1 and forwards it to a back-end server using HTTP/2.

Request Sent by Attacker:GET / HTTP/1.1
Host: example.com
Content-Length: 48

GET /admin HTTP/2
Host: example.com

2. Front-End Server Interpretation:

The front-end server processes the request as a single HTTP/1.1 request and forwards it to the back-end server.

3. Back-End Server Interpretation:
• The back-end server processes the forwarded request as two separate HTTP/2 requests:
• The first part is GET / HTTP/1.1\r\nHost: example.com\r\nContent-Length: 48\r\n\r\n, which is a valid request.
• The second part is GET /admin HTTP/2\r\nHost: example.com\r\n, which is also a valid request.

Example 3: Multiple Content-Length Headers

An attacker sends a request with multiple Content-Length headers to a front-end server that handles them differently from the back-end server.

Request Sent by Attacker:POST / HTTP/1.1
Host: example.com
Content-Length: 13
Content-Length: 6

POST /evil HTTP/1.1

2. Front-End Server Interpretation:
The front-end server processes the request using the first Content-Length: 13 and forwards it to the back-end server.

3. Back-End Server Interpretation:
• The back-end server processes the forwarded request using the second Content-Length: 6, misinterpreting it as two separate requests:
• The first part is POST / HTTP/1.1\r\nHost: example.com\r\nContent-Length: 13\r\n\r\n, which is a valid request.
• The second part is `POST /evil HTTP/1.1\r\n,` which is also a valid request.

With all this information in mind and understanding how you can manipulate your requests, let’s move on to how to test for request smuggling.

Testing for request smuggling involves sending various crafted requests to a server to see if you can manipulate the server’s request handling. Here are some steps and tools you can use to test for this vulnerability:

Manual Testing:

Create Requests with Conflicting Headers:Craft requests that contain both Content-Length and Transfer-Encoding headers with conflicting values.

2. Send Requests with Multiple Headers:

Construct requests with multiple Content-Length headers to see if the server processes them inconsistently.

3. Use Chunked Transfer Encoding:

Send requests with chunked transfer encoding and observe how the server handles the request boundaries.

4. Modify HTTP Methods:

Test using different HTTP methods (e.g., GET, POST, PUT) to see if the server behaves differently.

Automated Testing with Burp Suite:

HTTP Request Smuggler Extension:Installation: Go to the Burp Suite BApp Store and install the HTTP Request Smuggler extension.Usage: After installation, go to the “HTTP Request Smuggler” tab. Configure the extension to use the target endpoint and select the type of request smuggling attack you want to perform (e.g., CL.TE or TE.CL).

Example:

CL.TE Attack: Configure a request with a Content-Length header indicating a longer body than actually provided and a Transfer-Encoding: chunked header.POST / HTTP/1.1
Host: example.com
Content-Length: 13
Transfer-Encoding: chunked

GET / HTTP/1.1
Host: example.com

TE.CL Attack: Configure a request with a Transfer-Encoding: chunked header and a Content-Length header indicating a shorter body.POST / HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
Content-Length: 3

4
G
ET / HTTP/1.1
Host: example.com
0

2. Analyzing Results:

After sending the crafted requests, review the server’s responses in Burp Suite. Look for anomalies such as unexpected responses, responses meant for other users, or errors indicating improper handling of the requests.

3. Repeat and Refine:

Repeat the tests with slight variations in the requests to cover a broader range of potential vulnerabilities. Adjust the headers, methods, and body content to explore different attack vectors.

Tips for Effective Testing:

Monitor Responses:Pay close attention to the responses from the server, especially status codes and headers.

2. Check for Anomalies:

Look for unexpected behaviors such as duplicate responses, responses out of order, or responses meant for another user.

3. Test on Different Endpoints:

Test various endpoints within the application to ensure comprehensive coverage.

Automation tools — Located on Bounty Hunter server

Thanks for reading and understanding.