request-smuggling

Request Smuggling Detection

Overview

Request smuggling attacks the agreement between two servers about where one HTTP message ends and the next begins. A front hop — a load balancer, reverse proxy, CDN node, or gateway — forwards many users' requests down reused upstream connections; if it and the origin resolve a request's length differently, trailing bytes the front hop counted as body are read by the origin as the start of the next request and are grafted onto whichever message arrives next on that connection. The attacker is typically an unauthenticated remote party, and in browser-triggered variants a victim merely visiting a page. What they gain is leverage over other people's traffic: front-hop security controls skipped, forwarded identity headers supplied by hand, victims' requests captured, responses redirected to the wrong requester, and harmful responses pushed into shared caches. This is an infrastructure-boundary flaw far more than an application-code flaw, so this skill locates the hops and length-handling decisions the repository actually contains together with the application behaviours that make a desynchronisation exploitable, checks each candidate in parallel, and merges the results into <output_dir>/request-smuggling-results.md.

What it is NOT

• Web cache poisoning (/websec:web-cache-poisoning): storing a harmful response under a key victims request is that class, and it exists independently through unkeyed inputs. Test: is the mechanism an input the cache omits from its key, or a length disagreement between hops? Only the latter belongs here; the cache outcome is a consequence to record.
• Web cache deception (/websec:web-cache-deception): a victim's private response stored under a fetchable key is that class. Same test — the boundary is the mechanism, not the outcome.
• Host header trust (/websec:host-header): duplicate or ambiguous authority values and a hop that validates only the first request on a reused connection are host-validation problems. Test: is the disagreement about which site the request is for, or about how long the request is? Length belongs here.
• Cross-site scripting (/websec:xss): an unsafe reflection is that class; a desynchronisation is one delivery path that removes the need for victim interaction.
• Access control (/websec:access-control): a path protected only at the front hop is an authorization design defect in its own right. Record it here as what makes a desynchronisation severe, and let the sibling skill own the missing origin-side check.
• Response header injection: injecting delimiters into a single response splits that response; smuggling desynchronises request boundaries between hops. Delimiter injection appears here only as a downgrade-time mechanism.
• Not a finding: a chain that speaks HTTP/2 end to end with no downgrade and no length rewriting; a front hop whose configuration in the repository demonstrably rejects requests carrying conflicting length signals; a single process with no upstream hop and no evidence of connection reuse, absent a body-ignoring handler; a slow endpoint (latency alone says nothing).