search

CORS

hashtag
Trusting Any Origin

For exploiting a CORS misconfiguration, we must first check if the SameSite cookie flag is set (Figure 1).

Figure 1: Checking the SessionCookie's set flags via the browser.

The presence of Access-Control headers indicates that the application supports CORS (Figure 2).

Figure 2: Inspecting a CORS request and response.

If we send the same request unauthenticated (without the Cookie header), we get a 401 Unauthorized response (Figure 3). Remember that a browser won't include credentials on a CORS request without the Access-Control-Allow-Credentials header. Furthermore, a wildcard value for the Access-Control-Allow-Origin header doesn't allow Access-Control-Allow-Credentials to be true.

Figure 3: Sending a request without credentials.

When we add the Origin header to the CORS request, the Access-Control-Allow-Credentials response header is added (Figure 4).

Figure 4: Adding the Origin header.

We can try to reach the above endpoint from an external domain (Figure 5). Notice that this is a CORS request (mode: 'cors') including credentials (credentials: 'include').

Figure 5: Accessing the page from another domain.

Since JavaScript can access the response, we can update our page to send the code to an arbitrary domain. The below request creates a CORS page to get the code on behalf of the victim and then sent it to an attacker-control server (Figure 6).

Figure 6: Successfully exfiltrating the code to an arbitrary domain.

hashtag
Improper Domain Allowlist

The Access-Control-Allow-Origin header can only set a single domain. When an application needs to support multiple-origin CORS, it must include server-side logic to respond with the appopriate value via inspecting the Origin header to a CORS request. Two common appraches are to check if the Origin header includes a preset value or ends with a preset value and then reflecting that header value. In the example below, the server responds with an Access-Control-Allow-Origin header.

Passing a different origin (different protocol and subdomain) via the Origin header reflects it back to the response.

The server does not reflect the origin passed if we change its TLD, but it responds with the default value. The same behavior happens when another domain is passed.

Based on this information, we can infer that the server is allowing domains that end with offensive-security.com, perhaps to allow various subdomains. However, it is not checking for a leading period and this allow us to prepend something to the domain name and bypass CORS.

PreviousCSRFNextDevOps

Last updated