Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

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

Luca Chiaverini 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


Luca Chiaverini 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

Luca Chiaverini 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 Tai-Hogan Aug 14, 2019 01:12PM UTC Support Center agent

Thanks for letting us know Luca.


Luca Chiaverini 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

Luca Chiaverini 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?


Alexandr Aug 27, 2019 10:16AM UTC
Nobody can solve this lab because my cookies are returned in response in the blog

Derrick C 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.

Alexandr Aug 28, 2019 10:36AM UTC
Derrick, did you solve the "Exploiting HTTP request smuggling to capture other users' requests" lab?

Derrick C 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.

Dai D 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.


Dai D 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.

Noah 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.

Dai D 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

Dai D Sep 03, 2019 10:58AM UTC
I check the cache storage but it's empty

Luca Chiaverini 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.

Derrick C 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).

Luca Chiaverini 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...

Luca Chiaverini 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

Luca Chiaverini 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?

VIPIN BIHARI 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.

Luca Chiaverini 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...

Luca Chiaverini 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)

Splunk Hunk Oct 09, 2019 07:58PM UTC
Once I have gotten the cookie of the user, how do I login on the login page?

Luca Chiaverini Oct 11, 2019 10:22PM UTC
@splunk hunk, which lab are you referring to?

Splunk Hunk 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"

Luca Chiaverini 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

Andrew 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.


Post Your public answer

Your name
Your email address
Answer