What is the difference between CL.TE and TE.CL vulnerabilities?

CL.TE occurs when the front-end uses the Content-Length header and the back-end uses Transfer-Encoding. TE.CL is the opposite, where the front-end uses Transfer-Encoding and the back-end uses Content-Length.

How can you prevent HTTP Request Smuggling?

Prevention strategies include normalizing HTTP requests at the edge, disabling Transfer-Encoding for legacy systems, and upgrading to HTTP/2 or HTTP/3 to utilize binary framing instead of text-based delimiters.

Why is HTTP Desync detection important for DPDP Act compliance?

Under India's DPDP Act 2023, failing to secure protocol-level vulnerabilities like HTTP Desync that lead to session hijacking can result in significant penalties for failing to implement reasonable security safeguards.

HTTP Request Smuggling Detection: CL.TE & TE.CL Guide

Q: What is HTTP Request Smuggling?

HTTP Request Smuggling, or HTTP Desync, is a vulnerability where front-end proxies and back-end servers disagree on request boundaries, allowing attackers to bypass security controls by smuggling hidden requests.

The Initial Discovery: Identifying Proxy Discrepancies

During a recent red team engagement against a major Indian financial services provider, I identified a critical desynchronization vulnerability between a global CDN and a legacy F5 BIG-IP load balancer located in a Mumbai data center. The discrepancy occurred because the front-end CDN prioritized the Content-Length header, while the back-end load balancer, running an unpatched firmware version (CVE-2022-1388), prioritized the Transfer-Encoding: chunked header.

This "Proxy Sandwich" architecture is ubiquitous across Indian IT infrastructure, particularly in government portals and Tier-2 data centers in cities like Noida and Pune. We observed that by sending a specifically crafted request, we could "smuggle" a second, hidden request into the back-end's connection buffer. This hidden request was then prepended to the next legitimate user's request, allowing us to hijack their session.

To detect this, we monitored the back-end logs for 400 Bad Request errors that appeared sporadically without a clear source. When we correlated these with X-Forwarded-For headers, we noticed the errors were often attributed to IP addresses of legitimate users, indicating their requests were being corrupted by smuggled data.

What is HTTP Request Smuggling?

HTTP Request Smuggling, or HTTP Desync, occurs when the front-end (reverse proxy/WAF) and the back-end server disagree on where a request ends. This disagreement typically involves the Content-Length (CL) and Transfer-Encoding (TE) headers. Because HTTP/1.1 allows both headers, a malicious actor can craft a request that looks like one request to the front-end but is parsed as two separate requests by the back-end.

The impact is severe. We have successfully used desync to bypass WAF rules that were only applied to the first request parsed by the front-end. In many Indian enterprise environments, the WAF sits at the edge, but the internal routing is handled by legacy Nginx or HAProxy instances that may not share the same strict parsing logic.

Why HTTP Desync Detection is Critical for Web Security

Modern web applications are rarely single-server entities. They are chains of proxies, caches, and microservices. Each hop in this chain presents a potential desynchronization point. If a single node in the chain handles the Transfer-Encoding header differently—perhaps by ignoring it if it contains a trailing space—the entire security posture of the application is compromised.

In the context of the DPDP Act 2023, a desync vulnerability that leads to session hijacking constitutes a major data breach. Under Section 8 of the Act, data fiduciaries in India are required to implement "reasonable security safeguards" to prevent personal data breaches. Failing to detect a known protocol-level vulnerability like HTTP Desync could lead to significant financial penalties, potentially reaching ₹250 crore for severe non-compliance.

The Mechanics of Request Desynchronization

The desync occurs because of the stateful nature of the TCP connection between the proxy and the back-end. To improve performance, proxies reuse these connections for multiple users (Keep-Alive). For DevOps teams managing these complex environments, using a web SSH terminal can simplify secure access and debugging without the complexities of traditional proxy chains.

When the back-end server processes a smuggled request, it leaves the "leftover" bytes in the buffer. The next request arriving on that same TCP connection—belonging to an innocent user—is then appended to those leftover bytes. This results in the back-end processing a mangled request that often includes the innocent user's session cookies in the body of my smuggled request.

Core Concepts: CL.TE and TE.CL Vulnerabilities

The two primary types of desynchronization are CL.TE and TE.CL. These acronyms describe which header is used by the front-end and which is used by the back-end.

Understanding the Content-Length (CL) Header

The Content-Length header specifies the size of the request body in bytes. It is straightforward and used by almost every HTTP client. However, it is prone to errors if the body contains multi-byte characters or if the client calculates the length incorrectly.

Understanding the Transfer-Encoding (TE) Header

The Transfer-Encoding: chunked header allows the client to send the request body in "chunks." Each chunk starts with its size in hexadecimal, followed by the data. The request ends with a chunk of size 0. This is often used for streaming data where the total length isn't known upfront.

How Discrepancies Lead to Desync

CL.TE: The front-end uses Content-Length, but the back-end uses Transfer-Encoding. I send a long CL that encompasses the entire payload, but a TE body that ends early. The back-end stops reading at the 0-size chunk, leaving the rest of my payload in the buffer.
TE.CL: The front-end uses Transfer-Encoding, but the back-end uses Content-Length. I send a chunked request, but the back-end only reads the number of bytes specified in the CL header, ignoring the rest of the chunks which then wait in the buffer for the next request.
TE.TE: Both servers support Transfer-Encoding, but one can be induced to ignore it by obfuscating the header (e.g., Transfer-Encoding: xchunked).

Manual HTTP Desync Detection Techniques

Detecting desync manually requires a precise understanding of how different servers handle malformed headers. We often start by testing for time delays.

Using Time-Delay Techniques for Discovery

If we suspect a CL.TE vulnerability, we send a request where the Content-Length is longer than the actual body. The front-end will wait for the remaining bytes, or if it forwards the request, the back-end (using TE) will wait for the terminating "0" chunk that never arrives.



Manual CL.TE probe using curl
The back-end (TE) will wait for the terminating chunk, causing a timeout

curl -v -X POST https://api.target.in/v1/login \      -H "Content-Length: 4" \      -H "Transfer-Encoding: chunked" \      --data-binary $'0\r\n\r\nX'

If the application hangs for 10-30 seconds before returning a 504 Gateway Timeout, there is a high probability of a desync vulnerability.

Observing Differential Responses

The most reliable way to confirm desync is to observe how the smuggled request affects a subsequent request. We use two separate connections. Connection A sends the smuggled payload. Connection B sends a normal request. If Connection B receives a response intended for the smuggled request (e.g., a 404 for a path specified in the smuggled body), the desync is confirmed.

Crafting Desync Probes for CL.TE and TE.CL

When crafting probes, we must ensure the Connection: keep-alive header is present. Without socket reuse, desync is impossible. We also look for headers like X-Forwarded-For to see if the back-end is reflecting our smuggled headers back to us in error messages.



Testing for TE.CL
Front-end (TE) sees one request. Back-end (CL) sees the '0' chunk and stops.
The 'GET /admin' part stays in the buffer.

curl -v -X POST https://target.in/ \      -H "Transfer-Encoding: chunked" \      -H "Content-Length: 3" \      --data-binary $'8\r\nSMUGGLE\r\n0\r\n\r\n'

Automated Tools for HTTP Desync Detection

Manual testing is time-consuming and prone to missing edge cases. We use automated scanners to baseline our target environments, similar to how we optimize Tier 1 SOC workflows through automated log correlation.

Burp Suite: Using the HTTP Request Smuggler Extension

The "HTTP Request Smuggler" extension in Burp Suite is the industry standard. It automates the generation of various permutations of CL.TE and TE.CL probes. When we run this against Indian banking portals, we often find that internal load balancers are more vulnerable than the external-facing WAFs.

Open-Source Scanners and CLI Tools

For CI/CD integration, we use smuggler.py. It allows for rapid scanning of large IP ranges, which is useful during the discovery phase of an engagement.



$ python3 smuggler.py -u https://target.in -t 20 --config default

[+] CL.TE detected: https://target.in [+] TE.CL detected: https://target.in [+] Potential vulnerability found. Manual verification required.

Integrating Detection into CI/CD Pipelines

Detection should not be a one-time event. We recommend integrating smuggler.py or similar tools into the Jenkins or GitHub Actions pipeline. If a developer introduces a new proxy configuration or changes the Nginx proxy_pass settings, the scanner should trigger an alert before the code reaches production.

Advanced Detection Scenarios

As WAFs become more sophisticated, attackers move toward more obscure desynchronization methods.

Detecting TE.TE Vulnerabilities (Header Obfuscation)

In a TE.TE scenario, both servers support Transfer-Encoding, but we can trick one of them into ignoring it. We've seen success with:

Transfer-Encoding: chunked (with a trailing space)
Transfer-Encoding : chunked (space before the colon)
Transfer-Encoding: [tab]chunked
X: X followed by Transfer-Encoding: chunked on the next line with a leading space.

Identifying Desync in Multi-Tiered Proxy Architectures

In large Indian enterprises, it is common to see a path like: Akamai -> F5 BIG-IP -> Nginx -> Gunicorn. Each of these four layers must be perfectly synchronized. A single mismatch at the Nginx layer can allow an attacker to smuggle a request that bypasses the Akamai WAF and the F5 ACLs.

Connection State Desynchronization Challenges

Sometimes the desync isn't about the length headers but about the connection state. If a proxy doesn't properly handle the Upgrade header (used for WebSockets), it might leave the connection open in a way that allows raw TCP data to be sent to the back-end, bypassing all HTTP-level inspections.

The Impact of Undetected HTTP Desync

The consequences of a successful desync attack go far beyond simple site defacement.

Bypassing Security Controls and WAFs

WAFs typically inspect the first request they see. If I smuggle a second request inside the body of the first, the WAF never sees the malicious payload (e.g., a SQL injection or a path traversal to /admin). This effectively renders the ₹10M+ investment in high-end WAFs useless.

Session Hijacking and Account Takeover

This is the most common "high" or "critical" finding. By poisoning the back-end socket, I can capture the cookies of the next user. In many Indian apps, session tokens are not tied to an IP address, making them easily reusable from any location once stolen.

Cache Poisoning via Request Smuggling

If there is a caching layer (like Varnish or Akamai), I can smuggle a request that forces the back-end to return a redirect to my malicious site. This technique is a specialized form of web cache deception, where the cache stores this redirect for the legitimate URL.

Remediation and Prevention Strategies

Fixing desync requires a top-down approach to protocol enforcement.

Normalizing HTTP Requests at the Edge

The front-end should normalize all incoming requests. This means it should strip invalid headers, enforce a single Content-Length, and reject any request that contains both CL and TE headers. Most modern CDNs now do this by default, but it must be explicitly verified.

Disabling Transfer-Encoding for Legacy Systems

If your back-end systems do not strictly require chunked encoding, disable it. For Nginx, you can force the use of HTTP/1.1 and clear the Connection header to prevent socket reuse in high-risk environments.



Nginx mitigation for TRACE and Desync

server {     listen 80;     # Disable TRACE/TRACK methods to prevent XST     if ($request_method ~ ^(TRACE|TRACK)$ ) {         return 405;     }
location / {         proxy_pass http://backend_nodes;         # Force HTTP/1.1 to prevent protocol mismatch         proxy_http_version 1.1;         # Ensure Connection header is cleared to prevent socket reuse         proxy_set_header Connection "";     } }

The Role of HTTP/2 and HTTP/3 in Eliminating Desync

HTTP/2 and HTTP/3 are significantly less susceptible to desync because they use binary framing rather than newline-delimited text. The length of each frame is built into the protocol at a low level. However, be careful: many proxies "downgrade" HTTP/2 requests to HTTP/1.1 when talking to the back-end, which reintroduces the vulnerability.

Configuring Front-end and Back-end Consistency

Ensure that all servers in the chain use the same parsing engine or are configured to be equally strict. If the front-end rejects requests with multiple Content-Length headers, the back-end must do the same.

TRACE-based Attacks and Cross-Site Tracing (XST)

The TRACE method is designed for diagnostics; it returns the full request back to the client. While seemingly harmless, it is a primary vector for Cross-Site Tracing (XST).

Why TRACE is Dangerous

If an attacker finds a Cross-Site Scripting (XSS) vulnerability on a site that has TRACE enabled, they can bypass the HttpOnly flag on cookies. Standard JavaScript cannot read HttpOnly cookies, but it can make an AJAX request using the TRACE method. The server will then echo the request—including the cookies—back in the response body, which the script can read.



Testing for TRACE and header reflection
$ curl -v -X TRACE https://api.target.in -H "Max-Forwards: 1"
If the response reflects your headers, TRACE is enabled

.

SIEM Ingestion and Log Patterns

To detect these attacks in your SIEM (e.g., Splunk or ELK), you must ingest both access logs and error logs. Look for the following patterns:

High frequency of 405 Method Not Allowed (for TRACE attempts).
400 Bad Request errors with "Invalid header" or "Multiple Content-Length" descriptions.
Inconsistent X-Forwarded-For chains.



Identifying high-frequency protocol errors in SIEM ingestion

grep -E '400|405|501' /var/log/nginx/access.log | awk '{print $1, $7, $9}'

Real-time Capture of Conflicting Headers

For high-security environments, we use tcpdump to monitor the traffic between the proxy and the back-end. This allows us to see the raw bytes and identify desync attempts that don't necessarily trigger a 400 error but still poison the buffer.



Real-time capture of conflicting length headers

tcpdump -A -s 0 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' | grep -Ei 'Transfer-Encoding|Content-Length'

Next Command: Validating the Socket State

To move beyond basic detection, use openssl s_client to manually inject a malformed chunked request and observe if the back-end socket hangs or closes immediately.


openssl s_client -connect target.in:443 -quiet

(After connecting, paste a malformed CL.TE payload and observe the server's timeout behavior).