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
Origin
HeaderThe 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:
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:
Makes an authenticated request to
accountDetails
.Captures the response containing sensitive data.
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

Last updated
Was this helpful?