CORS Misconfiguration
A site-wide CORS misconfiguration was in place for an API domain. This allowed an attacker to make cross origin requests on behalf of the user as the application did not whitelist the Origin header and had Access-Control-Allow-Credentials: true meaning we could make requests from our attacker’s site using the victim’s credentials.
Summary
Tools
Prerequisites
Exploitation
References
Tools
Prerequisites
BURP HEADER>
Origin: https://evil.com
VICTIM HEADER>
Access-Control-Allow-Credential: true
VICTIM HEADER>
Access-Control-Allow-Origin: https://evil.com
ORAccess-Control-Allow-Origin: null
Exploitation
Usually you want to target an API endpoint. Use the following payload to exploit a CORS misconfiguration on target https://victim.example.com/endpoint
.
Vulnerable Example: Origin Reflection
Vulnerable Implementation
Proof of concept
This PoC requires that the respective JS script is hosted at evil.com
or
Vulnerable Example: Null Origin
Vulnerable Implementation
It's possible that the server does not reflect the complete Origin
header but that the null
origin is allowed. This would look like this in the server's response:
Proof of concept
This can be exploited by putting the attack code into an iframe using the data URI scheme. If the data URI scheme is used, the browser will use the null
origin in the request:
Vulnerable Example: XSS on Trusted Origin
If the application does implement a strict whitelist of allowed origins, the exploit codes from above do not work. But if you have an XSS on a trusted origin, you can inject the exploit coded from above in order to exploit CORS again.
Vulnerable Example: Wildcard Origin *
without Credentials
*
without CredentialsIf the server responds with a wildcard origin *
, the browser does never send the cookies. However, if the server does not require authentication, it's still possible to access the data on the server. This can happen on internal servers that are not accessible from the Internet. The attacker's website can then pivot into the internal network and access the server's data without authentication.
Vulnerable Implementation
Proof of concept
Vulnerable Example: Expanding the Origin / Regex Issues
Occasionally, certain expansions of the original origin are not filtered on the server side. This might be caused by using a badly implemented regular expressions to validate the origin header.
Vulnerable Implementation (Example 1)
In this scenario any prefix inserted in front of example.com
will be accepted by the server.
Proof of concept (Example 1)
This PoC requires the respective JS script to be hosted at evilexample.com
Vulnerable Implementation (Example 2)
In this scenario the server utilizes a regex where the dot was not escaped correctly. For instance, something like this: ^api.example.com$
instead of ^api\.example.com$
. Thus, the dot can be replaced with any letter to gain access from a third-party domain.
Proof of concept (Example 2)
This PoC requires the respective JS script to be hosted at apiiexample.com
Bug Bounty reports
References
Last updated