HTTP request smuggling

This is the topic where the fix is almost never in your application code — it lives in the configuration between the proxy and the backend, and in whether the two speak the same version of HTTP.

Three things that make it worse than it looks:

• It attacks OTHER users. Unlike most vulnerabilities that only harm the attacker's own request, the smuggled part attaches to the next victim's request on a shared connection — so the attacker captures someone else's request, or injects a response for them.
• It bypasses every front-tier control. The WAF, authentication and rate limiting at the proxy see the first request as valid; the smuggled part never passes them because the proxy does not consider it a request.
• It does not appear in a single-request test. It needs exactly two requests on a shared connection, so it is invisible to nearly every test suite.

And the good news for defence: the root cause is HTTP/1.1 and how it determines body length (Content-Length vs Transfer-Encoding: chunked). End-to-end HTTP/2 closes nearly all of this class, because it has one explicit way to determine length. So the strongest fix is architectural: HTTP/2 from client to backend, with no downgrade to HTTP/1.1 in between.

The mechanism is a disagreement about how to read body length. HTTP/1.1 has two ways — Content-Length and Transfer-Encoding: chunked — and when a request carries both, the spec says prefer chunked, but not every server obeys.

sequenceDiagram    autonumber    actor A as Attacker    participant P as Proxy (reads Content-Length)    participant B as Backend (reads Transfer-Encoding)    A->>P: POST with BOTH Content-Length: 6<br/>AND Transfer-Encoding: chunked<br/>body containing a hidden request    Note over P: Proxy follows Content-Length → sees ONE request,<br/>forwards it verbatim to the backend.    P->>B: forwards the whole byte blob    Note over B: Backend follows Transfer-Encoding → sees the request<br/>end EARLIER, the remainder is the START of<br/>a new request, kept in the buffer.    actor V as Victim    V->>P: a normal GET /    P->>B: forwards the victim request    Note over B: The remainder + the victim request JOIN →<br/>the victim request is altered, or captured.

The key point: the smuggled part attaches to the next victim's request on the shared proxy↔backend connection. This is why it attacks other people rather than only the attacker — and why it does not appear in a single-request test.

Four variants, named for which side reads which header:

The last row matters: many assume HTTP/2 at the CDN is enough, but if the CDN downgrades to HTTP/1.1 to talk to the backend the whole class returns — and worse, because HTTP/2 permits headers HTTP/1.1 forbids, creating new variants (request splitting via header injection).

A CL.TE payload. The crucial part is that the request carries both length-determining headers.

POST / HTTP/1.1Host: app.exampleContent-Length: 6Transfer-Encoding: chunked 0\r\n\r\nGPOST / HTTP/1.1\r\nFoo: x

The proxy reads Content-Length: 6 → the body is 0\r\n\r\n (exactly 6 bytes including CRLFs), and forwards the whole blob. The backend reads Transfer-Encoding: chunked → sees the 0 chunk as the end, so GPOST / HTTP/1.1... is the start of a new request kept in the buffer.

# The victim request arrives next, on the same proxy↔backend connection:GET /home HTTP/1.1Host: app.exampleCookie: session=<the VICTIM's session>

# The backend joins the remainder with the victim request, so it sees:GPOST /home HTTP/1.1     ← a junk method, or worse: a POST to /adminFoo: xGET /home HTTP/1.1Host: app.exampleCookie: session=<victim session>

# Timing-based detection (no real victim needed). A CL.TE payload makes the backend# WAIT for bytes that never arrive → an abnormally slow response.time curl -s -o /dev/null https://app.example/ \  -H 'Content-Length: 4' -H 'Transfer-Encoding: chunked' \  --data-binary $'1\r\nA\r\nX'# If the request hangs ~10s before returning → a sign of CL/TE disagreement.

James Kettle's research (PortSwigger, 2019) — "HTTP Desync Attacks". The paper that revived this class (first described in 2005) and showed it existed at scale on real CDNs and load balancers, with a timing-based detection technique. It is the source of the variant table in block 3, and the reason this topic is taken seriously again.

"HTTP/2: The Sequel Is Always Worse" (James Kettle, 2021). Showed that moving to HTTP/2 at the CDN is not enough if the CDN downgrades to HTTP/1.1 to talk to the backend — and worse, downgrade creates new variants because HTTP/2 permits headers HTTP/1.1 forbids. This is why block 6 stresses that HTTP/2 must be end-to-end.

And a bug bounty family: smuggling to bypass WAF controls. The recurring pattern: a /admin request blocked by a WAF at the proxy, but the same request smuggled into the backend never passes the WAF — because the proxy does not consider the smuggled part a request. This illustrates block 2's point: smuggling bypasses EVERY front-tier control.

This topic has a distinctive property: most checks run at the infrastructure layer, not the application layer, and a single-request test never finds it.

1. Check the proxy REJECTS ambiguous requests — the direct check for layer 1b:

B=https://app.example# A request with BOTH Content-Length and Transfer-Encoding must be a 400, never a guess.printf 'POST / HTTP/1.1\r\nHost: app.example\r\nContent-Length: 6\r\nTransfer-Encoding: chunked\r\n\r\n0\r\n\r\n' \  | openssl s_client -quiet -connect app.example:443 2>/dev/null | head -1# Expect: HTTP/1.1 400. If it is 200 → the proxy is guessing, and it may guess differently from the backend.

2. Check HTTP/2 is end-to-end — the check that catches what "the CDN uses HTTP/2" hides:

# Client to CDN — usually HTTP/2, easy to check:curl -sI --http2 "$B/" -o /dev/null -w 'client<->cdn: %{http_version}\n'# CDN to origin — must be checked in the CDN CONFIG, not observable from outside.# In nginx/Envoy: grep the protocol used to talk to the upstream.grep -rE 'proxy_http_version|http2.*upstream|http_protocol_options' deploy/ \  | grep -v '1.1' || echo "WARNING: the upstream may be HTTP/1.1 (a downgrade)"

3. Use a dedicated tool, do not write your own. Smuggling detection needs raw bytes with precise timing — HTTP Request Smuggler (a Burp extension) and smuggler.py do that. Run them against staging in a nightly pipeline:

python3 smuggler.py -u https://staging.example.com/ | tee /tmp/smug.txtgrep -qi 'potentially vulnerable\|CL.TE\|TE.CL' /tmp/smug.txt \  && { echo "desync detected"; exit 1; }exit 0

4. Check no security control lives ONLY at the proxy (layer 2) — smuggling bypasses the proxy tier, so a WAF rule blocking /admin must also be enforced by the backend:

# Call the backend DIRECTLY (bypassing the proxy) at a path the proxy blocks.# It must be refused by the backend on authorisation, not merely because the proxy blocks it.curl -s -o /dev/null -w '%{http_code}\n' http://backend-internal:5100/admin/users# Expect 401/403 from the backend itself, not 200.

5. Alert on latency and junk methods in the access log (layer 3). This is an operational check, not a test — but it is the only way to know smuggling is happening in production, because the victim cannot report what they did not see.

The location mistake, and it is the central one: hunting in application code. Smuggling is a bug of the boundary between two servers, so it is in no .cs file. The fix lives in the nginx/Envoy/CDN configuration, and it is checked at that layer.

The severity mistake: rating it "hard to exploit, so low risk". It attacks OTHER USERS, bypasses every front-tier control, and the victim does not know they were harmed. Hard to construct is not rare — the tools in block 7 automate the construction.