Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

" Exploiting clickjacking vulnerability to trigger DOM-based XSS" Lab broken

Jürgen | Last updated: Apr 10, 2024 01:27PM UTC

Hi everyone, it seems like the Lab "Exploiting clickjacking vulnerability to trigger DOM-based XSS" cannot be completed currently. The exploit works right away with Firefox, but it only worked on Chrome when i manually allowed third party cookies in the settings. Without third party cookies allowed, Chrome displays the error "Invalid CSRF token (session does not contain a CSRF token)" instead of the payload. I used the correct payload and injection point (double-checked with the solution), and when using "Deliver exploit to victim" the victim accesses the exploit, but the lab does not get marked as solved. This might be related to Chrome starting to block third-party cookies by default since the start of 2024 ([1]). Can you please check if your solution-checking Chrome has third party cookies blocked? As can be seen in [1] the Lab will be completely broken at the end of 2024 when third-party cookies get fully removed from chrome. [1] https://developers.google.com/privacy-sandbox/3pcd

Ben, PortSwigger Agent | Last updated: Apr 10, 2024 04:03PM UTC

Hi Jürgen, You are correct, there are some issues with solving the Clickjacking labs at this current time. The embedded browser in the latest version of Burp has a flag enabled by default that causes issues with these labs. In the interim whilst we resolve this issue, you should still be able to solve these labs using a normal version of Chrome (or Firefox).

Jürgen | Last updated: Apr 11, 2024 09:45AM UTC

Hi Ben, I'm afraid you misunderstood my problem. I was able to do the client-side part of the lab (creating and verifying that the exploit is correct). This worked with my local Firefox and Chrome once I allowed third party cookies. However, as clickjacking is a client-side exploit, to get the lab marked as solved, one must send the exploit to a "victim" via the exploit server. It is this step that is currently not working, even if one sends a correct exploit. So even if one sends a correct exploit, the simulated victim does access the exploit server (can be seen in the access logs), but the lab does not get marked as solved. I guess this verification step has a simulated user using an instrumented chrome browser to verify that the exploit actually does what it is supposed to do. It seems that the chrome instance on this verification step (that is, server-side, not on my local burp instance), also has third party cookies disabled, making the exploit fail, even though it is correct. Interestingly enough, the other Clickjacking labs did not have this problem, so maybe just this specific labs did not get thrid party cookies reenabled.

Ben, PortSwigger Agent | Last updated: Apr 11, 2024 10:04AM UTC

Hi Jürgen, Are you able to email us with the details of exactly what you are doing so that we can see this? Actually, having just run through this I can successfully solve this particular lab so, at this current time, this particular lab should still work without any changes made. In view of this, it would be useful to know exactly what you are doing. You are correct, the victim is currently using Chrome 119 (this is why we recommend you test your exploit on Chrome in case of any browser based discrepancies).

Jürgen | Last updated: Apr 11, 2024 03:19PM UTC

Hi Ben, interesting, i rechecked as well, and the problem still persists for me. I wrote you an E-mail with my steps.

Ben, PortSwigger Agent | Last updated: Apr 11, 2024 04:40PM UTC

Hi Jürgen, We have received your email and will pick this up from there.

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