Security Risks of CORS

Ayush Pathak
Nov 16 · 4 min read

Hey everyone.

As we see, these days webpages are full of animations, different font styles, GIF’s, images, videos etc. They even requests for and include different font styles and other scripts from any other website without user interaction. So what will happen if any bad guy in hoodie and green terminals hosts a malicious script on other-site.com to steal data from site.com? To prevents these kinds of “Cross” site attacks, SOP came into existence.

Same-origin Policy: SOP is a browser’s security mechanism which prevents one website to load scripts or request for other resources from another website/different origin.
Different origin ? When can we say that two URL’s are in same origin ?
If protocol, host and port are all same for two URL’s then we can say that both the URL’s are having same origin.
For example, let’s see if the following URLs are in same origin with http://domain.com

         URL             Result           Reason
http://domain.com/path Yes Protocol, host and port are same https://domain.com No Protocol is not same.
http://domain.com:8080 No Port is not same.
http://a.domain.com No Host is not same.

Note: Internet Explorer doesn’t care about port into same-origin checks.

Okay, sounds great. But what if I, the developer/admin of my-site.com wants to access some resources from my-other-site.com on which i completely trusts? To solve this issue Cross-origin resource sharing was introduced. CORS allowed developers to share resources between the sites they want to.

Cross-origin resource sharing (CORS)

It is a browser’s mechanism which allows sharing of resources from different origins. So, basically you allow access to the websites you trust to share resource with, and when a website with another origin requests for a resource, the application sends an HTTP request with origin header. If the origin is trusted it sends back the requested resource with Access-Control-Allow-Origin andAccess-Control-Allow-Credentials header in response.

Origin header: Origin header contains the URL from where the request has originated.
Access-Control-Allow-Origin: This header is send back in the response from one website to a request originated from another website, telling the website that it is allowed to access the resource.
Access-Control-Allow-Credentials: If this header is set to true then only you can share cookies and other credentials with another website.

CORS Specification

> Multiple origins:
Access-Control-Allow-Origin: http://domain1.com http://domain2.com
However, no browser supports multiple origins.
> Wildcards (*):
Access-Control-Allow-Origin: *
Sadly, you can use only this wildcard, means you allow each and every website, you can’t use wildcards on any other way like https://*.website.com to allow all subdomains of your website.
For security measures it automatically disables the Allow-Credentials header when using a wildcard. You need to specify a domain if you want to allow credentials.

> Null origin:
Acess-Control-Allow-Origin: null

Exploiting CORS misconfiguration
1. Origin reflection : In some cases, web server generate Access-Control-Allow-Origin header based on the origin they recieved in the requests. Which means any site can access the resource. So if a attacker intentionally changes the origin header and gets back ACAO header in response with his website and credentials set to true then the attacker can use this misconfiguration to get any secret data by hosting a html page with simple script on his website.

2. Null origin : If a website allow null origin then also it is exploitable as any website can obtain null origin using a sandboxed iframe.
3. Pre-domain wildcard: If a non existing domain like somevictim.com allowed access then the attacker can register this domain and can steal your data.
4. Post-domain wildcard: If victim.com.attacker.com is allowed, then an attacker can simply set up a domain like this to steal your data.
5. Sub-domains allowed: If sub.victim.com is allowed, the also an attacker can exploit this if he finds an XSS vulnerability in subdomain.

Security risks of CORS

If implemented badly, CORS can lead to major security risk like leaking of API keys, other users data or even much more. A very great example of security risk of CORS misconfiguration is this.

Detection

  1. Manually Testing: When testing for CORS misconfigurations manually, you simply sends your website in origin header via a simple curl https://victim.com -H "Origin: https://attacker.site" -I or by capturing the request in Burp Suite and using Repeater tab and check the response for Access-Control-Allow-Origin and Access-Control-Allow-Credential headers. If ACAO header contains https://attacker.site then you can host a script on https://attacker.site to steal private data or anything from https://victim.com
  2. https://github.com/RUB-NDS/CORStest
  3. Shodan.io : A simple search on shodan like this will give you back many sites with Access-Control-Allow-Origin: null, where you can try to exploit this issue.

References:
https://portswigger.net/web-security/cors
https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007)
https://www.youtube.com/watch?v=tH-HG4b4GYQ

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade