Week 3 - CORS Exploitation

Exploiting CORS Misconfigurations

In week 3 of the Web App Hacking Tips & Tricks series, we will be covering CORS misconfigurations. When I first became a tester, this topic caused me a good bit of confusion. It took me some time to find a clear and concise summary of how this attack (and CORS in general) worked. Here is my attempt at a clean and simple, Step-By-Step overview: 1. Specify a domain in the ‘Origin’ header of an HTTP Request 2. Check if the response contains ‘Access-control-allow-origin: domain’ or ‘Access-control-allow-origin: null’ ---> This means we can access HTTP Responses from our attacker site. The ‘null’ origin means any site can access responses 3. Check if the response contains the ‘Access-control-allow-credentials: true’ header ---> This means we can send cookies with an HTTP Request, allowing us to access authenticated pages as a user If the above steps are true, then the application has a CORS misconfiguration and can be exploited through a XSS attack using XMLHTTPRequest() like below: <script>

var xhr = new XMLHttpRequest(); xhr.withCredentials = true; xhr.onreadystatechange = function() { if (xhr.readyState == XMLHttpRequest.DONE) { alert(xhr.responseText); } } xhr.open('GET', 'http://domain', true); xhr.send(null);

</script> An attacker can host this JavaScript payload on their domain, convince a user to click on their site, execute an HTTP request on their behalf, and then read the response.

It is important to note that if the vulnerable site uses a wildcard (‘Access-control-allow-origin: *’) and allows credentials (Access-control-allow-credentials: true), it is NOT vulnerable. CORS blocks this by default, and will not send cookies with the request.