Cross-site scripting (XSS)
- https://owasp.org/www-community/attacks/xss/
- https://swisskyrepo.github.io/PayloadsAllTheThings/XSS%20Injection/#methodology
- https://github.com/payload-box/xss-payload-list/blob/main/Cheatsheet.md#xss-cheatsheet
Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into websites. There are two sides: source (frontend) and sink (backend).
REMEMBER: Viewing the Page Source (CTRL+U) or Inspecting Element (F12) are two separates things: respectively, one is the HTTP response (static site, scripts pre-execution) and the other is the final website (dynamically loaded, scripts post-execution)
| Type | Description |
|---|---|
Stored XSS (Persistent) | Stored in the backend… The most critical type of XSS, which occurs when user input is stored on the back-end database and then displayed upon retrieval (e.g. posts or comments) |
Reflected XSS (Non-Persistent) | Only passes through the backend… Occurs when user input is displayed on the page after being processed by the backend server, but without being stored (e.g. search result or error message) |
DOM-based XSS | Never touches the backend Non-Persistent XSS type that occurs when user input is directly shown in the browser and is completely processed on the client-side, without reaching the back-end server (e.g., through client-side HTTP parameters or anchor tags) |
Breaking Context
Manual Payloads
Sometimes, certain payloads are not allowed
Login Form Injection
Blind XSS
Manual
Generally, to enumerate Blind XSS vulns, start by setting a server to receive a callback for a particular HTML field that is being tested.
NOTE: usually, password fields are hashed and email fields are validated client/server side, so they are harder or impossible
Check the PHP server for the response with the cookie. Then add the cookie to the browser and visit the appropriate login page:
- Click
Shift+F9to show theStoragebar - Click on the
+button on the top right corner - Add
Nameis the part before=and theValueis the part after=from the stolen cookie
Dalfox
NOTE: this is very dangerous and can break servers easily
Blind
XSS Prevention & Mitigation
XSS defense requires a Defense in Depth approach. Never rely solely on Frontend validation (it is easily bypassed).
Frontend
- Input Validation: Use Regex to enforce strict formats (e.g., Email, Date).
- Sanitization: Strip dangerous tags before processing.
- Library:
DOMPurify(Standard).DOMPurify.sanitize(dirtyInput).
- Library:
- Safe Sinks: Avoid writing raw HTML.
- UNSAFE:
innerHTML,outerHTML,document.write(), jQueryappend(),html(). - SAFE:
innerText,textContent.
- UNSAFE:
Backend
- Input Validation: Reject input that doesn’t match expected types (e.g., PHP
filter_var). - Input Sanitization: Escape special characters before storage (e.g., PHP
addslashes, NodeDOMPurify). - Output Encoding (CRITICAL): Convert special characters into HTML Entities (e.g.,
<→<) before rendering.- PHP:
htmlspecialchars($input, ENT_QUOTES, 'UTF-8') - NodeJS:
html-entitieslibrary.
- PHP:
Server Configuration
- Content Security Policy (CSP): The most powerful header against XSS.
Content-Security-Policy: script-src 'self'(Only allow scripts from the same origin, blocks inline JS).
- Cookie Flags:
HttpOnly: Prevents JavaScript from readingdocument.cookie.Secure: Ensures cookies are only sent over HTTPS.
- Headers:
X-Content-Type-Options: nosniff(Prevents MIME sniffing).
- WAF: Web Application Firewall (ModSecurity, AWS WAF) to block common payloads.