Lion Cipher Lab
HTTP request smuggling — desync a front-end and back-end, then fix it
- AppSec / DevSecOps
- Intermediate
- ~50 min
- Free · no account required
Why it matters
HTTP request smuggling is one of the highest-impact web bugs there is, and one of the least understood. When it works, an attacker's bytes get glued onto the front of the NEXT person's request — so they can hijack other users' sessions, poison caches, bypass front-end security controls, and reach internal endpoints, all without ever touching the victim's browser. It exists for a boring, fixable reason: two servers in front of each other quietly disagree about where one request ends. Most courses teach it as a magic trick to perform. The skill worth having is the opposite — understanding the…
What you'll learn
- what HTTP request smuggling (desync) actually is
- how Content-Length and Transfer-Encoding disagree (CWE-444)
- reading the CL.TE and TE.CL variants on paper
- using Burp Suite Repeater to craft a raw HTTP request
- disabling automatic Content-Length so you control the bytes
- recognizing a successful smuggle from the response
- the fix: reject ambiguous requests and make front-end and back-end agree
- why HTTP/2 end-to-end removes the bug class
Steps in this lab
- The one-sentence bug: two servers disagree about where a request ends
- The two headers that cause the disagreement: Content-Length vs Transfer-Encoding
- CL.TE and TE.CL, on paper (read this twice)
- Set up your tools: a free PortSwigger account and Burp Community
- Open the CL.TE lab and capture a request in Repeater
- Craft the CL.TE request — and turn OFF automatic Content-Length
- Fire it twice and read what success looks like
- See the mirror image: the TE.CL variant
- The fix, part 1: make the two servers agree — or reject the request
- The fix, part 2 (the durable one): HTTP/2 end-to-end — and when it's not enough
- What you actually learned — and why it outlasts the trick