testing-request-smugglinglisted

# Testing request smuggling: the bug is between two servers When two HTTP servers sit in series and parse a request's boundaries differently, the front end forwards what it thinks is one request while the back end sees two, and the smuggled second request is attributed to the next client on the reused connection. That desync lets an attacker prefix a victim's request, bypass front-end controls, poison the connection, and capture other users' traffic. The bug is a disagreement between parsers, not a single flaw in one. ## When to use - You are reviewing a reverse proxy, load balancer, CDN, or gateway in front of an origin. - Requests pass through more than one HTTP parser in series. - Connections between hops are kept alive and shared across clients. ## Scope check Test chains you own or are authorized to test, and keep every probe on your own traffic. Do not target other users' live requests. If you can't name the authorization, stop. ## The loop 1. **Map the server chain and the reused connections.** Identify every hop a request passes through (edge, proxy, balancer, cache, origin) and where connections between hops are kept alive and shared across clients. A desync only bites where a downstream connection is reused for another user, so map that reuse first. 2. **Find conflicting length signals.** A request's body length can be stated more than one way, and smuggling happens when two hops resolve a conflict differently: one honors one signal, the oth