CORS vulnerability with trusted insecure protocols

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:

• Both using an external site and null resulted in the server filtering them

To successfully exploit the CORS misconfiguration, you need a way to execute malicious JavaScript in the victim’s browser. Look for additional vulnerabilities on the website that may aid in this attack.

• Explore the "Check Stock" feature, which opens a new page displaying stock levels based on parameters like productId.

• We test the productId parameter for reflected XSS:

• Use a simple payload like <script>alert(1)</script> to check if the input is reflected unsanitized.

• Confirm the vulnerability by executing arbitrary JavaScript in the reflected XSS context.

• The productId parameter is vulnerable to reflected XSS. This provides a method to execute JavaScript payloads on a trusted subdomain.

Combine the CORS misconfiguration with the XSS vulnerability to steal the administrator's API key:

• Use the XSS vulnerability to inject JavaScript that performs a CORS request to /accountDetails.

• Include the victim’s cookies using the withCredentials property.

• Exfiltrate the API key to an attacker-controlled server.

Code Breakdown

• document.location: This changes the current page location to include a malicious URL with embedded JavaScript. It attempts to perform a reflective XSS attack.

• Malicious URL (http://stock.YOUR-LAB-ID.web-security-academy.net/?productId=4<script>...</script>&storeId=1):

  • The script is injected directly into a query parameter (productId) of the URL.

  • The vulnerable application likely reflects this input into its response without proper sanitization, enabling the embedded script to execute.

• Core Script Functionality:

  • XMLHttpRequest:

    • Creates a new request to the victim site (https://YOUR-LAB-ID.web-security-academy.net/accountDetails) to fetch sensitive data.

    • withCredentials = true ensures that the victim's cookies, session tokens, and authentication headers are sent with the request.

  • reqListener:

    • A callback function triggered once the XMLHttpRequest is completed.

    • It redirects the victim's browser to the attacker's server (https://YOUR-EXPLOIT-SERVER-ID.exploit-server.net/log), appending the stolen data (this.responseText) as a query parameter.

• Attack Flow:

  • The script is injected into the vulnerable application.

  • When executed, it:

    1. Makes an authenticated request to accountDetails.

    2. Captures the response containing sensitive data.

    3. Exfiltrates the stolen data to the attacker-controlled exploit server.

Looking at the exploit server logs, we can see there's a request that contains the administrator api and

Step 4: Delivering the Exploit

After sending the payload to the victem we look at the server logs we can there's a request containing the administrator apikey