Detailed Explanation of HTTP Request Smuggling Attacks

Detailed Explanation of HTTP Request Smuggling Attacks

1. Attack Description

HTTP Request Smuggling is an attack technique that exploits discrepancies in HTTP protocol parsing, primarily occurring when multiple servers (e.g., reverse proxy servers and backend application servers) interpret HTTP requests inconsistently. By crafting a specially formatted HTTP request, an attacker can cause one server to misinterpret part of the request content as a separate, independent request, thereby bypassing security controls, stealing data, or tampering with requests.

2. Attack Principle

Key Background: Discrepancies in HTTP Request Boundary Parsing

  • The HTTP/1.1 protocol allows the request body length to be indicated by either the Content-Length (CL) header or the Transfer-Encoding (TE) header.
  • If both headers are present in the same request, different servers may prioritize one over the other, leading to disagreements about where the request body ends.
  • Common scenario: Different parsing logic between a reverse proxy (e.g., Nginx) and a backend server (e.g., Apache, IIS).

Two Main Attack Types

  1. CL-TE Smuggling: The frontend proxy uses Content-Length, while the backend uses Transfer-Encoding.
  2. TE-CL Smuggling: The frontend proxy uses Transfer-Encoding, while the backend uses Content-Length.
  3. TE-TE Smuggling: Both frontend and backend support Transfer-Encoding, but parsing discrepancies are triggered by obfuscating the encoding format (e.g., varying case, duplicate headers).

3. Attack Step Example (Using CL-TE)

Step 1: Craft the Malicious Request
The attacker sends the following request, where:

  • Content-Length: 44 indicates the request body is 44 bytes long.
  • Transfer-Encoding: chunked indicates the backend should parse using chunked encoding.
POST /api HTTP/1.1  
Host: example.com  
Content-Length: 44  
Transfer-Encoding: chunked  

0  

GET /secret HTTP/1.1  
Host: example.com

Step 2: Frontend Proxy Parsing

  • The frontend proxy reads 44 bytes (from 0 to the end of the second Host line) based on Content-Length: 44, forwarding the entire content as a single request to the backend.

Step 3: Backend Server Parsing

  • The backend prioritizes Transfer-Encoding: chunked and parses according to chunked encoding:
    • First chunk: 0 (length 0, indicating end).
    • The remaining content (GET /secret...) is mistakenly treated as the next request and sent to the backend application.

Step 4: Attack Impact

  • The second request (GET /secret) may bypass authentication and directly access sensitive endpoints.
  • If concurrent with other users' requests, it may tamper with their requests (e.g., stealing cookies).

4. Defense Measures

  1. Disable Protocol Ambiguity:
    • Configure servers to strictly reject requests containing both CL and TE headers.
  2. Standardize Parsing Logic:
    • Ensure the entire request chain (proxy + backend) uses the same parsing priority (e.g., prioritize TE).
  3. Use HTTP/2:
    • HTTP/2 fundamentally avoids smuggling issues by using a framing mechanism that clearly delineates request boundaries.
  4. Secure Configuration:
    • Configure reverse proxies (e.g., Nginx) with chunked_transfer_encoding off to force the use of CL.
    • Enable strict modes on backend servers (e.g., Apache's MergeSlashes On).

5. Detection Methods

  • Send test requests and observe response delays, abnormal status codes, or data leaks.
  • Use automated detection tools (e.g., http-request-smuggling scanners).

By understanding parsing discrepancies, crafting specific payloads, and implementing defensive configurations, HTTP request smuggling attacks can be effectively mitigated.