Labs / HTTP Smuggling

Challenge
Released 06 Oct 2025

Can you detect the hidden HTTP request lurking in plain sight?

Deep within seemingly normal web traffic, a malicious request hides in the shadows, exploiting how servers disagree on HTTP boundaries. This sneaky technique has compromised major websites and bypassed enterprise security systems! Armed with network forensics skills and protocol knowledge, you'll uncover how attackers manipulate HTTP headers to smuggle unauthorized requests past security controls. Time to expose this invisible threat!

Flags

Points

Challenge

Solution Available

Pro Exclusive

Start Lab Environment

~1-2 min setup

AWS dedicated

Private instance

Industry standard

Challenge

HTTP Smuggling - Complete Solution

Challenge Goal: You'll analyze network traffic to discover an HTTP request smuggling attack. This attack exploits differences in how two servers interpret HTTP headers. By the end, you'll extract an administrative access token that was hidden in a smuggled request.

Step 1: Understanding What You're Looking For

Before diving in, let's understand HTTP request smuggling. Imagine a web application with two servers:

Front-end server (like a reverse proxy or load balancer) - receives requests from the internet
Back-end server - processes the actual application logic

When these two servers disagree about where one HTTP request ends and another begins, an attacker can hide (smuggle) a second request inside the first. The front-end thinks it's one request, but the back-end sees two separate requests.

The vulnerability occurs when:
• Front-end uses the Content-Length header to determine request size
• Back-end uses the Transfer-Encoding: chunked header instead
• Both headers are present in the same request (which creates ambiguity)

This is called a CL.TE attack (Content-Length front-end, Transfer-Encoding back-end).

Step 2: Download and Open the Packet Capture

First, download the suspicious-traffic.pcap file from the challenge page. A PCAP file is a packet capture that contains recorded network traffic. Think of it as a recording of network conversations.

Option A: Using Wireshark (Recommended for visual analysis)

1. Open Wireshark (download from wireshark.org if needed)
2. Click File → Open
3. Select suspicious-traffic.pcap

You'll see a list of network packets. Each row represents one packet sent between two computers.

Option B: Using Command Line

If you prefer the terminal, use tcpdump to view the traffic:
tcpdump -r suspicious-traffic.pcap -A

The -r flag reads the file, and -A displays packet contents in ASCII (human-readable text).

Step 3: Filter to See Only HTTP Traffic

Network captures contain all types of traffic. We need to focus on HTTP traffic (web requests) since that's where the smuggling attack occurs.

In Wireshark:

1. In the filter bar at the top, type: http
2. Press Enter

Now you'll only see HTTP packets. You should see several packets, including some labeled as "POST" requests.

Alternative filter: tcp.port == 80 (shows all traffic on port 80, which is HTTP)

Using command line:
tshark -r suspicious-traffic.pcap -Y http

This uses tshark (Wireshark's command-line version) with a display filter (-Y) for HTTP traffic.

Step 4: Examine the HTTP POST Request

Look for a POST request in the packet list. In Wireshark, you'll see a packet with info showing "POST /search HTTP/1.1".

What to do:

1. Click on the POST request packet to select it
2. Look at the bottom panel (packet details)
3. Expand the "Hypertext Transfer Protocol" section

What you're looking for:
Examine the HTTP headers. You should notice something unusual - this request has BOTH:
• Content-Length: 44
• Transfer-Encoding: chunked

This is suspicious! HTTP specifications say you shouldn't use both headers together. When you do, different servers might interpret the request differently.

Step 5: Follow the TCP Stream

To see the complete HTTP conversation (not just individual packets), we'll use Wireshark's "Follow TCP Stream" feature. This reconstructs the entire conversation between client and server.

In Wireshark:

1. Right-click on the POST request packet
2. Select Follow → TCP Stream

A new window opens showing the complete conversation in easy-to-read format. Text in one color is sent by the client, text in another color is sent by the server.

Using command line:
tshark -r suspicious-traffic.pcap -q -z follow,tcp,ascii,0

This follows TCP stream 0 (the first conversation) in ASCII format.

Step 6: Analyze the Request Structure

Now comes the crucial part. In the TCP stream, you'll see the complete HTTP request. Let's break down what you're seeing:

The request structure looks like this:

POST /search HTTP/1.1
Host: vulnerable-app.hdna.me
Content-Length: 44
Transfer-Encoding: chunked
Connection: keep-alive

0

POST /api/admin HTTP/1.1
Host: backend.internal
X-Admin-Token: [UUID-HERE]
Content-Type: application/x-www-form-urlencoded
Content-Length: 25

command=get_secret_key

Let's understand what's happening:

1. First request (what front-end sees):
   • POST to /search
   • Content-Length says 44 bytes
   • Front-end reads 44 bytes and stops

2. The "0" chunk terminator:
   • In chunked encoding, "0\r\n\r\n" means "end of data"
   • This appears within those first 44 bytes

3. Second request (what back-end sees):
   • POST to /api/admin (administrative endpoint!)
   • Has an X-Admin-Token header
   • Appears after the chunk terminator
   • Back-end interprets this as a separate request

Step 7: Extract the Administrative Token

The smuggled request contains an X-Admin-Token header with the administrative access credential. This is exactly what we need!

Finding the token in Wireshark:

In the TCP stream window, look for the line that says:
X-Admin-Token: [UUID-FORMAT-TOKEN]

The value after "X-Admin-Token: " is a UUID (Universally Unique Identifier) that looks like:
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

This UUID is your target - it's the administrative access token!

Finding the token via command line:

Extract HTTP data and search for the token:
tcpdump -r suspicious-traffic.pcap -A 2>/dev/null | grep -A 2 "X-Admin-Token"

Or use tshark to extract just the HTTP payload:
tshark -r suspicious-traffic.pcap -Y 'http.request.method == POST' -T fields -e http.file_data

Look for the X-Admin-Token header in the output.

Step 8: Understanding Why This Attack Works

Now that you've found the token, let's understand the complete attack flow. This helps you identify similar vulnerabilities in the future.

The Attack Timeline:

1. Attacker crafts malicious request
• Creates request with both Content-Length and Transfer-Encoding headers
• Content-Length: 44 tells front-end to read only 44 bytes
• Transfer-Encoding: chunked tells back-end to use chunked parsing

2. Front-end processes request
• Sees Content-Length: 44
• Reads exactly 44 bytes
• Thinks it's one complete request to /search
• Passes everything to back-end (including data after byte 44)
• Considers this safe and allows it through security controls

3. Back-end processes request
• Sees Transfer-Encoding: chunked
• Ignores Content-Length (per HTTP specification)
• Reads chunks until it sees "0\r\n\r\n" (end marker)
• This happens early (within the first 44 bytes)
• Everything after the chunk terminator looks like a NEW request
• Processes the second POST to /api/admin

4. Smuggled request executes
• The /api/admin request appears to come from the front-end
• Bypasses authentication (front-end is trusted)
• Administrative token is already included in X-Admin-Token header
• Attacker gains unauthorized administrative access

5. Why it's dangerous
• Front-end security controls are completely bypassed
• Authentication checks don't see the admin request
• Rate limiting counts only one request, not two
• Web Application Firewalls miss the smuggled payload
• The attack is invisible in many logging systems

Step 9: Verify Your Finding

Before submitting, verify you have the correct token:

Checklist:

✓ The token is in UUID format (8-4-4-4-12 hexadecimal digits with dashes)
✓ It comes from the X-Admin-Token header
✓ It's in the smuggled POST /api/admin request
✓ It appears after the "0\r\n\r\n" chunk terminator

The complete token (including dashes) is your answer.

Key Takeaways

Technical Concepts

Content-Length header: Specifies exact number of bytes in request body
Transfer-Encoding: chunked: Body is sent in chunks with size indicators
HTTP specification: Transfer-Encoding should take precedence over Content-Length
Request boundaries: Servers must agree on where requests start and end
TCP streams: Multiple HTTP requests can share one TCP connection

Security Implications

Defense in depth: Front-end security controls can be bypassed
Protocol ambiguity: Differing implementations create vulnerabilities
Trust boundaries: Back-ends often trust front-end proxies too much
Attack surface: Load balancers, CDNs, WAFs, reverse proxies all vulnerable
Detection difficulty: Attacks can be invisible to traditional monitoring

Real-World Context

HTTP request smuggling has been found in major platforms including:

Amazon AWS - CloudFront CDN vulnerabilities
Cloudflare - Edge server parsing discrepancies
Apache/Nginx - Proxy configuration issues
Enterprise WAFs - Security bypass techniques

Reported vulnerabilities have paid bounties ranging from $5,000 to $50,000+. Understanding this attack is valuable for both offensive security testing and defensive architecture design.

Prevention and Mitigation

For developers and security teams:

1. Normalize HTTP parsing: Use the same HTTP library on both front-end and back-end
2. Reject ambiguous requests: Return 400 Bad Request if both headers present
3. Use HTTP/2: The protocol makes smuggling much harder
4. Disable connection reuse: Don't use keep-alive between front-end and back-end
5. Update software: Modern versions of nginx, Apache, and HAProxy have protections
6. Test configurations: Use tools like Burp Suite's HTTP Request Smuggler extension
7. Monitor for anomalies: Watch for Content-Length/Transfer-Encoding conflicts in logs

Congratulations! You've successfully analyzed a request smuggling attack, understood how it bypasses security controls, and extracted administrative credentials from a smuggled HTTP request. This skill is directly applicable to penetration testing, bug bounty hunting, and security architecture review.