Subdomain XSS & Parent Domain Cookie Theft

TL;DR

Yes, an Cross Site Scripting (XSS) exploit on a subdomain can steal cookies from the parent domain if certain conditions are met. This is because browsers generally share cookies across subdomains by default. However, modern security measures like HttpOnly and SameSite attributes can mitigate this risk.

Understanding the Problem

Cookies are small pieces of data websites store on a user’s computer to remember information about them. Parent domains often set cookies that apply to all their subdomains. If an attacker can inject malicious JavaScript (XSS) into a subdomain, that script can access these shared cookies.

How XSS Exploits Work

XSS happens when an attacker finds a way to make a website run their code instead of the intended code. This usually involves injecting HTML or JavaScript into input fields, URLs, or other parts of a web application that aren’t properly sanitised.

Steps for Cookie Theft via Subdomain XSS

1. Find an XSS Vulnerability: Locate a place on the subdomain where you can inject JavaScript. Common places include search boxes, comment sections, or URL parameters.
2. Inject Malicious Script: Insert your script into the vulnerable input field. A simple example to send cookies to an attacker’s server:

3. Trigger the Script: Make sure the injected script runs when a user visits the vulnerable page. This usually happens automatically if the XSS is stored (e.g., in a database). If it’s reflected, you need to trick the user into clicking a malicious link.
4. Cookies Sent to Attacker: The script will execute in the victim’s browser and send their cookies (including those for the parent domain) to the attacker’s server at https://attacker.com/collect.

Mitigation Strategies

Here’s how to protect against this:

1. Input Validation and Output Encoding: Always validate user input on the server-side and encode output before displaying it in HTML. This prevents malicious code from being injected.
   • Validation: Check that input conforms to expected types, lengths, and formats.
   • Encoding: Convert special characters into their HTML entities (e.g., < becomes <). Use a context-aware encoding library.
2. HttpOnly Cookies: Set the HttpOnly flag on sensitive cookies. This prevents JavaScript from accessing them, making XSS attacks less effective.

   Set-Cookie: sessionid=12345; HttpOnly

3. SameSite Cookie Attribute: Use the SameSite attribute to control when cookies are sent with cross-site requests. Options include:
   • Strict: Cookies are only sent for same-site requests (best protection).
   • Lax: Cookies are sent for same-site and top-level navigation requests.
   • None: Cookies are sent with all requests, but requires Secure attribute to be set.

   Set-Cookie: sessionid=12345; SameSite=Strict; Secure

4. Content Security Policy (CSP): Implement a strong CSP to control the sources from which the browser is allowed to load resources. This can prevent the execution of malicious scripts.

   Content-Security-Policy: default-src 'self'

5. Regular Security Audits and Penetration Testing: Regularly scan your web applications for vulnerabilities, including XSS flaws.