XSS Lab
DOWNLOAD XSS LAB FILES --------------->
|
Warning: For educational purposes only.
Below is a thorough, defensible explanation of XSS attacks, the common subtypes, how specific attacks work in principle, how to detect them, and safe, legal mitigation and testing advice. I will not provide instructions, exploit code, or step-by-step attack procedures that could be used to harm systems.
What is XSS?!?
Cross-Site Scripting is a class of web vulnerability where an attacker injects malicious scripts into content that other users trust and execute in their browsers, often giving the attacker access to session tokens, local data, or the ability to perform actions on behalf of the victim.
Core types of XSSStored XSS (persistent)Description: Malicious script is saved on the server, then served to multiple users later. Typical storage locations: message boards, user profiles, comments, file metadata, or any persisted field.
How it works: Attacker submits a payload to an input that the application stores without properly encoding or sanitizing. Later, other users load the page and the browser executes the script.
Example payload:
<script>alert(document.cookie)</script>
Why it matters: High impact, because every visitor to that resource may be affected. Easier to weaponize for account takeover, persistent malware, or chained attacks.
Reflected XSS (non-persistent)Description: Payload is included in a request and reflected back in the HTTP response, often via query parameters, search fields, or error messages. The malicious script is not stored.
How it works: Attacker crafts a URL containing the payload and tricks a victim into visiting it, via email, social engineering, or another channel. When the victim opens the link, the server reflects the input into the page and the browser executes it.
Example URL-based payload:
https://example.com/search?q=<script>fetch('/steal?c='+document.cookie)</script>
Why it matters: Often used in targeted phishing, because the attacker needs the user to click the specially-crafted link.
DOM-based XSS (client-side)Description: The vulnerability exists in the client-side code only. The server may return completely safe data, but browser-side JavaScript reads unsafe input (URL fragment, query param, document.location, document.referrer, localStorage) and writes it into the DOM unsafely.
How it works: Client JS manipulates DOM using untrusted data without appropriate encoding. This is purely a browser-side bug where sinks include innerHTML, document.write, eval, setTimeout(string), new Function, and similar.
Example:
// vulnerable: uses location.hash directly as HTML
document.getElementById('message').innerHTML = location.hash.substr(1);
Why it matters: Harder to spot in server-side code reviews, because the payload never touches server logs. It also often bypasses server-side filtering.
Context matters: where input landsXSS defenses depend entirely on context. Different contexts need different escaping:
Below is a thorough, defensible explanation of XSS attacks, the common subtypes, how specific attacks work in principle, how to detect them, and safe, legal mitigation and testing advice. I will not provide instructions, exploit code, or step-by-step attack procedures that could be used to harm systems.
What is XSS?!?
Cross-Site Scripting is a class of web vulnerability where an attacker injects malicious scripts into content that other users trust and execute in their browsers, often giving the attacker access to session tokens, local data, or the ability to perform actions on behalf of the victim.
Core types of XSSStored XSS (persistent)Description: Malicious script is saved on the server, then served to multiple users later. Typical storage locations: message boards, user profiles, comments, file metadata, or any persisted field.
How it works: Attacker submits a payload to an input that the application stores without properly encoding or sanitizing. Later, other users load the page and the browser executes the script.
Example payload:
<script>alert(document.cookie)</script>
Why it matters: High impact, because every visitor to that resource may be affected. Easier to weaponize for account takeover, persistent malware, or chained attacks.
Reflected XSS (non-persistent)Description: Payload is included in a request and reflected back in the HTTP response, often via query parameters, search fields, or error messages. The malicious script is not stored.
How it works: Attacker crafts a URL containing the payload and tricks a victim into visiting it, via email, social engineering, or another channel. When the victim opens the link, the server reflects the input into the page and the browser executes it.
Example URL-based payload:
https://example.com/search?q=<script>fetch('/steal?c='+document.cookie)</script>
Why it matters: Often used in targeted phishing, because the attacker needs the user to click the specially-crafted link.
DOM-based XSS (client-side)Description: The vulnerability exists in the client-side code only. The server may return completely safe data, but browser-side JavaScript reads unsafe input (URL fragment, query param, document.location, document.referrer, localStorage) and writes it into the DOM unsafely.
How it works: Client JS manipulates DOM using untrusted data without appropriate encoding. This is purely a browser-side bug where sinks include innerHTML, document.write, eval, setTimeout(string), new Function, and similar.
Example:
// vulnerable: uses location.hash directly as HTML
document.getElementById('message').innerHTML = location.hash.substr(1);
Why it matters: Harder to spot in server-side code reviews, because the payload never touches server logs. It also often bypasses server-side filtering.
Context matters: where input landsXSS defenses depend entirely on context. Different contexts need different escaping:
- HTML body text — escape <, >, &, " , ' to HTML entities.
- HTML attribute — also escape quotes and newlines.
- JavaScript string — escape quotes, backslashes, newlines; prefer not to inject raw user data into JS code.
- URL/URI — use percent-encoding.
- CSS context — escape characters that can break out into url() or expression.
- Inside a DOM API — avoid innerHTML, prefer textContent or safe DOM creation.
Minimal vulnerable examples:
1) Stored XSS (server-side template that outputs unsafely)
Vulnerable server rendering:
<!-- templates/profile.html -->
<h2>Bio</h2>
<div id="bio">
{{ user.bio }}
</div>
If user.bio contains "<script>...</script>" and the templating engine does not escape, the script runs.
2) Reflected XSS example
<!-- /search?q= -->
<form method="GET" action="/search">
<input name="q" value="{{ q }}">
<button>Search</button>
</form>
<p>Showing results for: {{ q }}</p>
If the app just inserts q verbatim, a crafted link can execute script.
3) DOM XSS example
<!-- client.js -->
const params = new URLSearchParams(location.search);
const name = params.get('name');
document.getElementById('greeting').innerHTML = 'Welcome, ' + name;
If an attacker uses ?name=<img src=x onerror=alert(1)>, the image onerror fires.
1) Stored XSS (server-side template that outputs unsafely)
Vulnerable server rendering:
<!-- templates/profile.html -->
<h2>Bio</h2>
<div id="bio">
{{ user.bio }}
</div>
If user.bio contains "<script>...</script>" and the templating engine does not escape, the script runs.
2) Reflected XSS example
<!-- /search?q= -->
<form method="GET" action="/search">
<input name="q" value="{{ q }}">
<button>Search</button>
</form>
<p>Showing results for: {{ q }}</p>
If the app just inserts q verbatim, a crafted link can execute script.
3) DOM XSS example
<!-- client.js -->
const params = new URLSearchParams(location.search);
const name = params.get('name');
document.getElementById('greeting').innerHTML = 'Welcome, ' + name;
If an attacker uses ?name=<img src=x onerror=alert(1)>, the image onerror fires.