Research Academy
My account Customers About Blog Careers Legal Contact Resellers
The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

New lab: Exploiting HTTP request smuggling to capture other users' requests

Luca | Last updated: Aug 13, 2019 02:58PM UTC

Hi and sorry for bothering again. I am not able to complete the lab in the subject after following the lab solution. As far as I understand, there should be "another user" accessing the blog comments page, whose session cookie should be captured thank you to my previous "smuggled" request. I wait for several minutes, but when I refresh the page, the only credentials that are captured are mine. I send my smuggled request only once, and not twice as in the other exercises, as I understand that the second request is the one from the other user "bot". Is this correct? Thank you in advance, Luca

Burp User | Last updated: Aug 14, 2019 10:29AM UTC

Update: I've been able to play with time and content length enough to get the other user session cookie, but when I replace my session cookie with the captured one, the lab is still not marked as solved. Do I have to access a specific page? Thanks

Burp User | Last updated: Aug 14, 2019 11:11AM UTC

Update: I was able to submit the session cookie, then I restarted the lab from scratch and the whole process went smoother. It can be me or this lab is a bit temperamental :)

Liam, PortSwigger Agent | Last updated: Aug 14, 2019 01:12PM UTC

Thanks for letting us know Luca.

Burp User | Last updated: Aug 14, 2019 02:04PM UTC

As a very last request, I'm completely stuck on the very last lab: Web Cache Deception. I cannot find a way to get an API key different from the one that is already accessible with the given user - and that key is not accepted as solution for the lab. I'm not entirely sure which key I should suppose to retrieve, another bot? Can you please help me on this last lab? Cheers Luca

Burp User | Last updated: Aug 22, 2019 02:53PM UTC

Bumping this... Can anybody please confirm the lab on Web Cache Deception is solvable and does not have any problem?

Burp User | Last updated: Aug 27, 2019 10:16AM UTC

Nobody can solve this lab because my cookies are returned in response in the blog

Burp User | Last updated: Aug 27, 2019 02:05PM UTC

I did manage to solve the Web Cache Deception lab after quite a number of tries. The other user's API key finally appeared in one of the .js files for me. I had a lot more problems solving the "Exploiting HTTP request smuggling to capture other users' requests" lab and only figured out what I was doing wrong after 3-4 days of trying.

Burp User | Last updated: Aug 28, 2019 10:36AM UTC

Derrick, did you solve the "Exploiting HTTP request smuggling to capture other users' requests" lab?

Burp User | Last updated: Aug 29, 2019 02:36AM UTC

Alexandr, yes I managed to solve it. I am very new to all this so not sure if my explanation is accurate. The main thing is you cannot assume that the victim user's request will be exactly like your own. It might be a lot shorter or longer than the content length you specify to capture your own cookie. I think if your content length is too short you won't capture the full cookie of the victim user. If it too long, when the victim request is submitted, it will get stuck at the front end server because the server will be waiting for more content --> so you will never see it as the request fails. So you have to play around with the content length and not leave it unchanged once you see your own cookie being displayed in the comments. Hope this helps.

Burp User | Last updated: Aug 31, 2019 12:44AM UTC

Derrick, I have a question for you. When you smuggle the request, do you just wait for the victim's request to appear on the comments? Because I wait for some time, and refresh the page, and I do see a GET request on the comment, but I expect that it's my own GET request.

Burp User | Last updated: Aug 31, 2019 02:03AM UTC

I solved the lab. the trick is to be patient, and need to distinguish between your own request and the victim's request. also increase the content-length slowly. Once you can see the cookie header, calculate the remaining number of characters to catch the exact length of the cookie.

Burp User | Last updated: Sep 01, 2019 11:27AM UTC

hello,everyone, I have a question need you help , idk how to test the testing process in the lab. I tested it in Burpsuite and it didn't seem to work. No progress in one day,hope somebody can help me how to test http smuggled attck, thanks.

Burp User | Last updated: Sep 03, 2019 10:48AM UTC

Derrick, I want to ask about the Web Cache Deception lab. I've smuggled the request, refresh the home page and confirm that the smuggled request has been called by another user, because the page refreshes smoothly. Now how do I check the static resources? I tried to use Chrome Inspect tool and check the resources folder but they just look the same every time. Is that the right way to check the .js static resources? Thanks

Burp User | Last updated: Sep 03, 2019 10:58AM UTC

I check the cache storage but it's empty

Burp User | Last updated: Sep 05, 2019 12:35AM UTC

I'll have another got at the Web Cache Deception lab this weekend, I haven't had a chance since I posted. Derrick said he solved it, so we should be able to see an API key show up in a js file, hopefully. Last time I checked the .js files with Burp but I did not see any API key apart from my own.

Burp User | Last updated: Sep 07, 2019 04:06PM UTC

For the web cache deception lab, if I remember correctly I had to send the request in around 10+ times one after the other and then reload the page in the incognito browser. The static resources can be seen in the target tab of Burp Suite. I'm using the community version so I used the "Type a search term" entry at the bottom of the page to search through all the responses when I reloaded the page (the Search in the menu option is only for the Pro version).

Burp User | Last updated: Sep 14, 2019 02:27AM UTC

Absolutely zero API keys in js files for me. I get only 2 js files and nothing in them. Do I have to be logged in as carlos when I refresh the home page in incognito browser? Really frustrating...

Burp User | Last updated: Sep 14, 2019 10:08AM UTC

Derrick which request did you send exactly? The one in the solution? Did you have to put a double newline at the end? What was the answer you got after sending the request multiple times? Thanks

Burp User | Last updated: Sep 14, 2019 10:10AM UTC

Also, did you send the request as the logged in user with / without the cookie, or it doesn't matter?

Burp User | Last updated: Sep 25, 2019 01:50PM UTC

I think web cache deception lab is having some issues. Did everything but API key not getting cached anywhere.

Burp User | Last updated: Sep 25, 2019 10:32PM UTC

I can see in the hall of fame that there are people who were able to complete everything (before the new websockets lab), but I still cannot solve the web cache deception lab. Waiting for a step by step guide from some kind soul...

Burp User | Last updated: Oct 01, 2019 02:17AM UTC

Alright, so... with the help of some kind soul I figured it out. The resource that gives the victim api key is: /resources/css/labs.css (tested 3 times) which is only loaded when we load the page https://your_id.web-security-academy.net/login So: - send the solution to repeater: exactly as it is, with content-length 38, several times. It doesn't matter whether or not you are logged in as carlos - in an incognito window, reload the page https://your_id.web-security-academy.net/login If the api key of the victim is not present, rinse and repeat. The solution for the lab doesn't mention the /login page, which is the main source of confusion in my opinion. If you load and refresh the home page only in incognito mode, /resources/css/labs.css is never loaded. Two months spent on this... (Also not sure why we do not need a double new line at the end of the evil request, as opposed to other labs - and the hint to manually fix the content length doesn't apply here - Overall a complex topic not easy to exploit in an ad hoc lab, let alone in real world, imho)

Burp User | Last updated: Oct 09, 2019 07:58PM UTC

Once I have gotten the cookie of the user, how do I login on the login page?

Burp User | Last updated: Oct 11, 2019 10:22PM UTC

@splunk hunk, which lab are you referring to?

Burp User | Last updated: Oct 16, 2019 05:55PM UTC

@Luca Chiaverini, sorry for not clarifying. I am referring to the initial lab mentioned in this post "Exploiting HTTP request smuggling to capture other users' requests"

Burp User | Last updated: Nov 07, 2019 09:01PM UTC

If you intercept with Burp and replace your cookie with the cookie that you captured, the lab *should* be marked as solved

Burp User | Last updated: Nov 26, 2019 06:55AM UTC

The solution for Lab: Exploiting HTTP request smuggling to perform web cache deception is INCORRECT. The Lab appears to be updated and is not using the /apiKey function anymore. Instead it is replaced with /my-account which has an update email address function /my-account/change-email. I have tried the original solution, and changed the /apiKey with /my-account. I have also tried using a double carriage-return after the X-Ignore: X, which produces some interesting results. However, I cannot for the life of me solve the updated solution. Please help or update the Solution appropriately.

Luca | Last updated: Mar 23, 2022 09:13PM UTC

Re-doing both labs after 3 years and the Web Cache Deception one can be solved flawlessly now.

Yuyu | Last updated: Sep 04, 2024 04:31PM UTC