Labs Covered

This write-up focuses on the following PRACTITIONER-level lab from the PortSwigger Web Security Academy related to Cross-origin resource sharing (CORS):

3 CORS vulnerability with trusted insecure protocols

This lab demonstrates how trusting insecure protocols (like HTTP instead of HTTPS) in CORS policies can lead to security vulnerabilities.

---

LAB 3 - CORS vulnerability with trusted insecure protocols

Lab Description

Solution

Here’s a more professional and structured version of your write-up:

---

Lab Walkthrough: Exploiting CORS Misconfiguration with XSS to Exfiltrate API Key

Step-by-Step Guide

1. Login and Identify the API Key

   • Access the shop application provided by the lab.

   • Login with the credentials:

     Username: wiener
     Password: peter
     

     

   • Once logged in, navigate to the “My Account” page. The API key for the user wiener is visible.

   • Viewing the HTML source reveals a JavaScript call fetching this key dynamically.

     

2. Review Network Activity

   • Open the browser’s developer tools or Burp Suite to monitor requests.

   • You’ll observe a GET request to the endpoint:

     /accountDetails
     

   • Send this request to the Repeater tab in Burp Suite for testing.

     

3. Test for CORS Misconfiguration

   • Add an Origin header to the request:

     Origin: http://subdomain.0a4f006a04b14c4a807d0dfc00b80015.web-security-academy.net
     

   • Replace the domain with the appropriate subdomain for your lab.

   • If the server reflects this origin in the response header:

     Access-Control-Allow-Origin: http://subdomain.0a4f006a04b14c4a807d0dfc00b80015.web-security-academy.net
     

     and includes:

     Access-Control-Allow-Credentials: true
     

     — this confirms the server is vulnerable to CORS misconfiguration.

     

4. Find XSS Injection Point

   • Navigate to any product page and click on Check Stock.
   • Intercept the request and inject an XSS payload into the productId parameter.

   • If the application executes JavaScript via this parameter, it confirms an XSS vector is present.

     If we enter a simple alert() script in productID parameter, we get a pop up which confirms that it is vulnerable to XSS.

GET /?productId=<script>alert("Hey")</script>&storeId=1 HTTP/1.1
Host: stock.0a4f006a04b14c4a807d0dfc00b80015.web-security-academy.net
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:106.0) Gecko/20100101 Firefox/106.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1

This productID parameter is vulnerable to XSS

1. Prepare the Exploit Script

   • Go to the Exploit Server provided in the lab.

   • Store the following script (modify URLs accordingly):

     

   • Replace:

     • YOUR-LAB-ID with the lab’s domain.

     • YOUR-EXPLOIT-SERVER-ID with your exploit server domain.

     • 

2. Inject the Script via XSS

   • Use the XSS injection point discovered earlier (e.g., via productId in stock checker).
   • Inject the <script> tag to trigger the CORS-based API key exfiltration.

3. Deliver Exploit to Victim

   • Once the exploit is saved and ready, click “Deliver exploit to victim” in the exploit server interface.
   • Go to the Access Log tab of the exploit server.

1. Retrieve and Clean API Key

   • You’ll see a request logged containing the administrator’s API key.
   • Use Burp Decoder or a URL decoder to clean and extract the key.

The code is now clean, and here is the API key for the administrator: 7Rdgi0KARqz2GXkaWvspBYozqsoxmOgl.

Submit the API key of admin to solve the lab.

---