CORS Miscofigration

Overview of CORS

CORS (Cross-Origin Resource Sharing) is a mechanism that allows web servers to specify which domains (origins) are permitted to access resources on that server. It enhances the Same-Origin Policy (SOP), which restricts interactions between websites and external resources unless they share the same origin.

Same-Origin Policy (SOP):

  • Restricts web pages to interacting only with resources from the same domain (origin).

  • An origin consists of a scheme, host, and port.

CORS allows servers to provide access to resources across different origins by adding specific HTTP headers that describe which domains are allowed.


How CORS Works

CORS relies on HTTP headers sent by the server to allow or deny requests based on the origin of the request.

  • Request Headers: Headers sent by the client (browser) when making a cross-origin request.

  • Response Headers: Headers sent by the server to the client, allowing or denying cross-origin access.


CORS Request Types

  1. Simple Requests: Simple requests are those that don't trigger a preflight request and meet the following criteria:

    • Methods: GET, HEAD, POST.

    • Allowed Headers:

      • Accept, Accept-Language, Content-Language, Content-Type, DPR, Downlink, Save-Data, Viewport-Width, Width.

    • Allowed Content-Type Values:

      • application/x-www-form-urlencoded

      • multipart/form-data

      • text/plain

    • No XMLHttpRequestUpload event listeners.

    • No ReadableStream.

    Example of Simple Request:

    GET /api/data HTTP/1.1
    Host: example.com
    Origin: https://trusted-origin.com
  2. Preflighted Requests: For more complex requests, an initial OPTIONS request (preflight) is sent by the browser to check if the request is safe.

    • Trigger Conditions:

      • HTTP methods like PUT, DELETE.

      • Custom headers.

    • Preflight is sent via the OPTIONS method and asks for permission to proceed.

    Example of Preflight Request:

    OPTIONS /api/data HTTP/1.1
    Host: example.com
    Origin: https://trusted-origin.com
    Access-Control-Request-Method: POST
    Access-Control-Request-Headers: Content-Type

CORS Response Headers

  1. Access-Control-Allow-Origin:

    • Specifies which origins are allowed to access the resource.

    • * allows any origin.

    • For requests with credentials, the origin must be explicitly specified (no *).

    • Example:

      Access-Control-Allow-Origin: https://trusted-origin.com
  2. Access-Control-Allow-Methods:

    • Specifies which HTTP methods are allowed (e.g., GET, POST, DELETE).

    • Example:

      Access-Control-Allow-Methods: GET, POST
  3. Access-Control-Allow-Headers:

    • Specifies which headers can be included in the actual request.

    • Example:

      Access-Control-Allow-Headers: Content-Type, X-Custom-Header
  4. Access-Control-Expose-Headers:

    • Specifies which headers are exposed to the client.

    • Example:

      Access-Control-Expose-Headers: X-Custom-Header
  5. Access-Control-Max-Age:

    • Specifies how long the results of a preflight request can be cached.

    • Example:

      Access-Control-Max-Age: 86400
  6. Access-Control-Allow-Credentials:

    • When true, allows credentials (cookies, HTTP authentication) to be sent with requests.

    • Example:

      Access-Control-Allow-Credentials: true

Handling Credentialed Requests

  • If a request includes credentials (cookies, authentication headers), the server must respond with an explicit origin (not *) in the Access-Control-Allow-Origin header.

  • Example:

    Origin: https://user-origin.com
    Access-Control-Allow-Origin: https://user-origin.com
    Access-Control-Allow-Credentials: true

Common CORS Misconfigurations and Exploits

  1. Abusing CORS without Credentials:

    • If a victim’s network is used for authentication, attackers can use the victim’s browser to bypass IP-based authentication.

    Origin: http://attacker.com
    Access-Control-Allow-Origin: *
  2. Breaking TLS with Poor CORS Configuration:

    • If an application trusts an origin using HTTP (not HTTPS), attackers can intercept the victim’s traffic and execute an attack.

    Origin: http://trusted-subdomain.vulnerable-website.com
    Access-Control-Allow-Origin: http://trusted-subdomain.vulnerable-website.com
  3. Broken Parser (String Parsing Vulnerabilities):

    • Some servers improperly parse the Origin header, allowing attackers to inject malicious origins.

    Origin: https://website.com`.attacker.com/
  4. Exploiting XSS via CORS Trust Relationships:

    • If a site trusts a subdomain vulnerable to XSS, an attacker can inject a script to read sensitive information.

    Origin: https://subdomain.vulnerable-website.com
    Access-Control-Allow-Origin: https://subdomain.vulnerable-website.com
  5. Server-Side Cache Poisoning:

    • If a server reflects the Origin header without proper validation, attackers can inject malicious values that persist in cache.

    Origin: z[0x0d]Content-Type: text/html
  6. The Null Origin Issue:

    • The null origin is used in specific cases like sandboxed iframes or file-based requests. If whitelisted, attackers can exploit this to perform unauthorized requests.

    Origin: null
    Access-Control-Allow-Origin: null
  7. Vary Header and Cache Poisoning:

    • The Vary: Origin header should be used when dynamic CORS headers are generated. Missing this header can lead to improper caching and potential attacks.

    Vary: Origin

Best Practices for Configuring CORS

  1. Limit Origins: Don’t use * (wildcard) for sensitive endpoints.

  2. Validate Origins: Ensure proper origin validation to prevent malicious sites from being trusted.

  3. Use Preflight Requests: For non-simple requests, always use a preflight to ensure safe methods and headers.

  4. Avoid Including Sensitive Data in CORS: Be cautious about including sensitive information like API keys, session tokens, or user data in responses.

  5. Configure Access-Control-Allow-Credentials Carefully: Ensure that credentials are only allowed from trusted origins

Reports

Last updated