HTTP Desync Attacks: Smashing into the Cell Next Door

## Overview

James Kettle (PortSwigger, Burp Suite developer) presented HTTP request smuggling attacks—a technique discovered in 2005 but rarely successfully applied to real-world websites until recent research. Motivation: large-scale web infrastructure uses chains of servers (frontend reverse proxies, application servers) connected via persistent TCP/TLS connections reused for performance (HTTP keepalive). These servers must parse ambiguous HTTP messages to determine request boundaries. Vulnerability premise: if frontend and backend servers interpret request boundaries differently, attacker can inject malicious data that frontend treats as part of one request but backend treats as start of next request. Injected data becomes a "prefix" to the next legitimate request from potentially different user. Research scope: practical exploitation of request smuggling against modern real-world websites, demonstration that technique remains viable despite 15-year history, release of automated detection/exploitation tooling (Burp Suite extension), methodology for safe detection without violating bug bounty terms. Key finding: contrary to prior pessimism, successful exploitation is possible and generates bug bounties; most websites remain vulnerable due to HTTP specification ambiguities and inconsistent implementation choices.

## HTTP Keepalive Architecture and Request Desynchronization

**Multi-Server Chain and Persistent Connections**: Modern websites route requests through multiple tiers: frontend server (reverse proxy, WAF, load balancer) receives client request over TLS/TCP, parses HTTP headers, forwards to backend application server over separate persistent connection (TLS/TCP). For performance, both frontend and backend maintain pools of reused TCP connections with HTTP keepalive enabled. HTTP keepalive means requests are streamed sequentially on same connection without delimiters: [Request1-Headers][Request1-Body][Request2-Headers][Request2-Body]... Each server independently parses HTTP request format to determine where request boundaries are: use Content-Length header (expects N bytes of body) or Transfer-Encoding: chunked (parse chunks until zero-length chunk followed by blank line). Assumption: both frontend and backend follow same parsing rules. Reality: servers may implement different rules or have inconsistent configurations.

**Ambiguous Request Exploitation**: Attacker sends message intentionally ambiguous about its length—message frontend parses as one request, backend parses differently. Example: message specifies both "Content-Length: 30" (first header) and "Content-Length: 60" (duplicate header). Frontend uses first header (length 30), forwards first 30 bytes to backend. Backend uses second header (length 60), reads 60 bytes. Bytes 31-60 of original message are interpreted as start of "next request" by backend but remain buffered for future use by frontend. When actual next request arrives from user, bytes 31-60 become prefix to that request at backend. Attack variation: "Content-Length + Transfer-Encoding: chunked" conflict. Message includes both headers; RFC 7230 specifies chunked encoding should take priority, but implementation variance exists. Frontend respects specification, reads message until chunked encoding terminator (zero-length chunk + blank line), forwards to backend. Backend incorrectly prioritizes Content-Length, reads N bytes, treats remaining data as next request. Result: attacker-controlled prefix injected into next legitimate user's request.

## Exploitation Paths and Impact

**Prefix Injection and Cache Poisoning**: Attacker injects HTTP request prefix such as "GET /path HTTP/1.1 Host: victim.com " into stream. Next legitimate request (e.g., user accessing "/admin") becomes: [injected-prefix][legitimate-request]. Backend receives syntactically valid HTTP starting with attacker's injected request header. If frontend shares connection among multiple clients and caches responses, poisoned response (from attacker's injected request) can be cached and served to other users. Attack variants: (1) XSS via injected HTML/JavaScript payload that becomes response to legitimate request; (2) authentication bypass by injecting "Cookie: admin=1" into authenticated request; (3) credential capture via injected forms; (4) cache-based worm—injected response cached and propagated to many users.

**Detection and Mitigation Complexity**: Vulnerability scope: any website using chain of HTTP servers over persistent connections if any server in chain has inconsistent request parsing. RFC 7230 specifies handling of multiple Content-Length headers (reject message) and Content-Length + Transfer-Encoding conflict (prioritize chunked), but servers differ: some follow spec, some reject duplicates, some accept both. Non-standard behaviors emerge: application firewalls (WAF) may parse differently than backend application server; reverse proxies may have chunked encoding disabled (causing fallback to Content-Length); implicit server behavior influenced by configuration, library version, or industry-specific implementations. Safe detection requires: (1) crafting ambiguous messages; (2) identifying backend desynchronization via timing analysis or response content examination; (3) avoiding actual exploitation that affects other users. Attacker-safe methodology: inject data that causes backend parsing error (not XSS or functional exploit) visible only in error response, confirming vulnerability without harmful side effects.