Before you start: This lesson requires a solid understanding of HTTP/1.1 from http-fundamentals, TCP and DNS basics from networking-dns-tls, and hands-on Burp Suite experience (specifically Burp Repeater) from the Recon, Scanning & Traffic Tools category.
HTTP request smuggling — also called desync — is an infrastructure-level attack that affects not just you but other users sharing the same proxy connection. It is catalogued in the OWASP Web Security Testing Guide and tracked as CWE-444 (HTTP request/response smuggling).
How proxies parse request boundaries
Your traffic rarely reaches the application server directly. It flows through a chain:
client ──▶ front-end (CDN / load balancer / reverse proxy) ──▶ back-end (app server)To be efficient, the front end forwards many requests down a single reused (keep-alive) TCP connection — it pipelines them (sends the next request before waiting for the previous response). For that to work, both ends must agree on exactly where each request body ends, so that the next request starts in the right place.
The seed of the bug
HTTP/1.1 gives two ways to declare body length:
- **
Content-Length** — a byte count. - **
Transfer-Encoding: chunked** — chunks terminated by a0\r\n\r\nmarker, with no up-front count. (\r\nis the carriage-return + line-feed pair that ends each HTTP header line.)
The specification says that if both appear, Transfer-Encoding wins. But real servers disagree on this in subtle, implementation-specific ways. If the front end measures a request one way and the back end measures it another, the byte stream desynchronises: trailing bytes of your request get treated as the prefix of the next person's request on that shared connection.
What you will do in this lesson
- Understand why a single request can be measured two different ways.
- Learn the CL.TE, TE.CL, and TE.TE variants, plus HTTP/2 downgrade smuggling.
- Send a probe carrying both length headers and confirm the desync with a timing differential.
- Name the two headers behind the desync, and learn the durable fix.
Required external lab. This is not reproducible in a single bare NovaCart instance — it needs a front-end/back-end chain that disagrees about request boundaries. Use the PortSwigger Web Security Academy HTTP request smuggling labs (free account required at portswigger.net).
Estimated time: ten to fifteen minutes.
When you are ready, send the Continue signal.