XSS: When Websites Trust User Input Too Much

Cross-Site Scripting (XSS) is like that party guest who spikes the punch bowl – except the punch bowl is a website, and the spike is malicious JavaScript. It occurs when an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript.

The Goal of XSS: To execute malicious scripts in the victim's browser. This can lead to session hijacking, defacement, phishing, and more.

Types of XSS - The Unholy Trinity:

1. Stored XSS (Persistent XSS):

   • The Sneaky One: The malicious script is permanently stored on the target server (e.g., in a database, message forum, comment field).
   • How it Works: Attacker injects script -> Server stores it -> Victim views the page with the script -> Script executes in victim's browser.
   • Example: A comment on a blog post: <script>alert('Your session cookie is: ' + document.cookie)</script>
   • Impact: High, as every user visiting the page gets hit. It's the gift that keeps on giving (to the attacker).

2. Reflected XSS (Non-Persistent XSS):

   • The Social Engineer's Friend: The injected script is reflected off a web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request.
   • How it Works: Attacker crafts a malicious URL (e.g., http://example.com/search?query=<script>alert('XSS')</script>) -> Attacker tricks victim into clicking the URL -> Victim's browser sends request -> Server reflects the script back in the response -> Script executes in victim's browser.
   • Impact: Requires user interaction (clicking a link, submitting a form). Often delivered via email or social media. It's like a booby-trapped link.

3. DOM-based XSS:

   • The Client-Side Culprit: The vulnerability exists in the client-side code rather than server-side code. The attack payload is executed as a result of modifying the DOM (Document Object Model) environment in the victim's browser.
   • How it Works: The client-side JavaScript takes data from a user-controllable source (e.g., URL fragment like #, or document.location.search) and passes it to a sink that supports dynamic code execution (e.g., eval(), innerHTML, document.write).
   • Example: var unsafeData = window.location.hash.substring(1); document.getElementById('greeting').innerHTML = 'Welcome, ' + unsafeData; If unsafeData is <img src=x onerror=alert(1)>, boom!
   • Impact: Can be tricky to detect by server-side defenses as the payload might never leave the browser.

Finding XSS - Where to Poke:

• Anywhere user input is reflected in the page: URL parameters, form fields, HTTP headers (Referer, User-Agent).
• Look for places where the application handles user input without proper sanitization or encoding.
• Use browser developer tools to inspect the DOM and see how your input is rendered.
• Tools like Burp Suite can help automate finding reflection points.

Basic XSS Payloads (The "Hello World" of Hacking):

• <script>alert('XSS')</script>
• <img src=x onerror=alert(1)> (when <script> tags are filtered)
• <svg onload=alert(1)>

Next up: We'll discuss how to prevent these pesky script shenanigans!