How can one exploit a CORS policy?

Cross-origin resource sharing (CORS) is a mechanism within the browser where a content delivery network policy instructs the browser to treat requests from nominated domains as secure and enables continued access to resources past a domain. It is an extension of the same-origin policy (SOP). However, a weak CORS policy is susceptible to attacks and vulnerabilities like XSS. 

What is the Same-Origin Policy?

The same-origin policy is a security mechanism within the web browser that restricts the ability of websites to attack each other—the SOP limits scripts on one source from accessing data from another source. It uses HTTP, the domain example.com, and port number 80. 

The same-origin policy is essential as it contains the access JavaScript code has to cross-domain content. In short, it prevents any JavaScript on the page from being able to read the contents of resources. The page can load external resources such as images, videos, etc.

When an HTTP request is transmitted from one origin to another, any cookies pertinent to the other domain, including authentication session cookies, are sent as part of the request. The response generated within the user's session includes any relevant data detailed to the user. Without the same-origin policy, if a user visited a malicious website, it would be capable of reading private emails, messages, etc. However, the implementation of CORS is not necessarily a safeguard against CSRF attacks. 

How can one exploit CORS?

• Maintaining an allow list for accessing domains can be difficult, hence many applications allow access from any domain. When an HTTP request is made, the cross-origin requests include session cookies. Since the application can reflect arbitrary origins, any malicious domain can access resources, gaining the ability to access sensitive information.

• Many times users/organizations allow access to all subdomains. Therefore, external alternate domains can grant unintended access. Whitelisting can also sometimes backfire when not paid attention.

  • Normal domain -> healthybyte.net

  • Alternate domain -> healthybyte.evil.net

• Whitelisting Null Values. An attacker can trick the browser into generating a cross-origin request containing the origin header's null value.

• Exploit CORS using cross-site scripting. If a website trusts the source origin vulnerable to XSS, a malicious actor can inject malicious Javascript that uses CORS to retrieve sensitive data.

• A misconfigured CORS policy can enable an attacker to perform a man-in-the-middle attack, intercept a user's traffic, and compromise the user's application and data.

How can one prevent CORS attacks?

The primary source of CORS vulnerabilities is due to misconfigurations. Proper configurations should mitigate CORS vulnerabilities. 

Proper configuration of cross-origin requests

• The Access-Control-Allow-Origin header should have the receiver origin adequately specified.

• Only allow trusted websites. It is essential to have specified origins allow-listed & trusted as it would prevent cross-origin requests with any validation.

• Avoid allow-listing the header Access-Control-Allow-Origin to null. Having the CORS headers defined adequately concerning trusted origins for public and private servers is vital.

• Do not use wildcards "*" for internal networks as they can access untrusted external malicious domains.

Important to remember that cross-origin resource sharing should be used for browser security and should not be the only source of dependency for protection.