Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Lab for "Web cache poisoning with an unkeyed header" not completing despite correct (?) solution

Andrew | Last updated: Jan 06, 2022 07:41AM UTC

Hi, Basically as the title says I have done the lab for "Web cache poisoning with an unkeyed header" and succeeded in getting the alert box to pop up in my browser. However despite this no matter what I do the lab itself will not solve. I looked at the solution and video attached on the lab page and did them step by step but still the same result. I also made sure I am not using any type of cachebuster and instead poisoning the raw "/" path (and to verify this I made sure not to proxy through Burp when re-accessing the site after poisoning). Here is a screenshot of the request I am sending in Burp: https://i.ibb.co/T4Btygr/web-cache-001.png Here is a screenshot of the response showing my poisoned path: https://i.ibb.co/7kHLNV7/web-cache-002.png Here is a screenshot of the alert box generated when accessing the lab URL (this was done from a different browser and not proxied through Burp just to make sure it wasn't some issue like Burp automatically adding cachebuster params etc): https://i.ibb.co/8sXjknw/web-cache-003.png Here is a screenshot of the source when accessing the lab URL in the browser: https://i.ibb.co/kKMcp4J/web-cache-004.png Finally, here is a screenshot of my exploit-server file settings, just incase there is an issue there: https://i.ibb.co/1JcCwZm/web-cache-005.png I have tried many different things but just cannot get it working. If there is any help you can give I would be very grateful! Best Regards, AC

Ben, PortSwigger Agent | Last updated: Jan 06, 2022 09:06AM UTC

Hi, I have just run through this particular lab and was able to solve it using the solution so it is, at least, working as intended for some users. From the screenshots that you have provided, I cannot immediately see anything obviously wrong with what you are trying to do - just to confirm, are you sending your request more than once just in case the victim user is not visiting the page whilst the cache is poisoned?

Mushtak | Last updated: Jan 14, 2022 03:31PM UTC

Hi I'm facing the same issue

Alex, PortSwigger Agent | Last updated: Jan 17, 2022 02:01PM UTC

Hi, I've confirmed with the Academy team that the lab is operating as intended. I can only repeat Ben's advice and confirm that you are sending more than one request. Thanks

alexp | Last updated: Jan 22, 2022 04:03AM UTC

Hi, I'm having the same issue, I tried to solve the lab on my own method it didn't work then intended solution doesn't work either. This happened to me at past in one of the SQLi lab after relogin in private browser worked before but in this case it doesn't Thanks

Alex, PortSwigger Agent | Last updated: Jan 24, 2022 09:01AM UTC

Hi, Can you confirm how you are determining which header to use for the solution? Thanks

Ju | Last updated: Feb 18, 2022 01:47PM UTC

Hello, I am also facing the same issue. The intended solution does not work for me either. I get a pop up window which seems to indicate that the "alert" is triggered. I sent the request with my payload multiple times and tried to access the target page before the cache expires (<30s). Thanks

Towsif | Last updated: Apr 15, 2022 08:52PM UTC

Hello, I have tried the same technique as was intended, exploited the lab but not showing the lab is done solving. I have done all of your advice from above but still, it's not solving the lab. I have added the parameter as ?cb=1234 then I have used the "X-Forwarded-Host: url ", like full copy-pasting but still not working.

Hannah, PortSwigger Agent | Last updated: Apr 18, 2022 10:28AM UTC

Hi Have you removed your cache-buster after confirming that your attack is functioning as expected? You can find this in step 9. You will need to poison the home page to solve the lab. If you're using the "Param Miner" extension, make sure you aren't adding any additional cachebusters through that.

Dennis | Last updated: Apr 28, 2022 03:10AM UTC

Hi I have the same behavior, the exploit script runs from Chrome browser, but it's not run from Firefox v99.0.1 beacuse in console appears the message: 'Loading failed for the <script> with source "https://exploit-server-id.web-security-academy.net/resources/js/tracking.js"' The victim in the lab could be using a browser based on Firefox? The header I was used (in exploit-server-id I used the id lab generated): GET / HTTP/1.1 ... X-Forwarded-Host: exploit-server-id.web-security-academy.net And I made a persistent poisoning with Intruder using a null payload indifinitely.

Hannah, PortSwigger Agent | Last updated: Apr 28, 2022 10:50AM UTC

Hi I have just tested and can confirm that the lab is working as expected. Have you tried following along with any video solutions?

Dennis | Last updated: Apr 30, 2022 03:28AM UTC

Hi Yes I made all steps. After many retries, I got the "LAB solved" when I used the FireFox ESR browser in a Linux Machine, and I saw the headers are a little differents when I used Firefox or Chrome on Windows (not only the user-agent header is different). I hope this info helps. Thanks.

viduka | Last updated: Oct 08, 2022 08:41AM UTC

Hi, I had same issue and solution was to disable Param Miner extension. I thought that the extension manipulates requests only if explicitly requested but maybe it is doing it all the time while enabled.

lewis | Last updated: Nov 23, 2022 10:13AM UTC

Can confirm had the same issue as viduka, the param miner config options "Add 'fcbz' cache buster" or "Add dynamic cachebuster also" seem to apply to requests from repeater. It's pretty transparent to the enduser however can see them being added to the requests with logger++. Either disabling the plugin or going to Param Miner settings and unchecking the tickbox options to add cachebuster also work.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.