> For the complete documentation index, see [llms.txt](https://kruknight.gitbook.io/daemon-of-hacking/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kruknight.gitbook.io/daemon-of-hacking/writeups/portswigger-labs/cross-origin-resource-sharing-cors/cors-vulnerability-with-trusted-insecure-protocols.md).
# 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 `` 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&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
