Lesson Notes
OWASP Top 10: XSS & CSRF
Module 4: Common Vulnerabilities. Client-side issues.
Module 4: OWASP — XSS & CSRF: Comprehensive Theory
Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF) are two of the most common web vulnerabilities. Both abuse trust: XSS abuses the trust a user's browser has in the content delivered by a site (so the browser runs attacker script in the site's origin); CSRF abuses the trust the server has in requests that arrive with the user's cookies (so the server executes actions the user did not intend). TLS protects data in transit but does not stop XSS or CSRF—these must be fixed in application logic and with correct use of cookies and headers. This lesson explains in detail how XSS and CSRF work, the different XSS variants (reflected, stored, DOM-based), and the defenses: output encoding, Content-Security-Policy (CSP), CSRF tokens, and cookie attributes (Secure, HttpOnly, SameSite).
Cross-Site Scripting (XSS): Concept and Impact
XSS occurs when the application includes untrusted data in a web page in a way that the browser interprets it as executable code (HTML or JavaScript). The script runs in the context of the vulnerable site—so it can read the same-origin data: cookies, localStorage, session tokens, and the DOM. An attacker can steal session cookies and hijack the user's account, keylog credentials, deface the page, or perform actions as the user (e.g. post content, change settings). The "cross-site" name refers to the fact that the malicious script is often delivered from or controlled by an attacker's site or payload, but it executes as if it came from the vulnerable domain. XSS is a client-side vulnerability: the server sends a response that contains the injected content; the damage happens in the user's browser.
Reflected, Stored, and DOM-Based XSS
Reflected XSS: the payload is supplied in the request (e.g. a query parameter or form field) and is echoed back in the response without being stored. Example: search?q=<script>alert(1)</script> returns a page that includes that string in the HTML; if not encoded, the browser runs the script. The payload is not persisted; the victim must be tricked into clicking a crafted link. Stored XSS: the payload is saved (e.g. in a database) and later included in a page viewed by other users (e.g. a comment, profile field, or message). One injection can affect many users. DOM-based XSS: the payload is processed entirely in the client; a JavaScript snippet reads from the URL (e.g. document.location) and writes it into the DOM (e.g. innerHTML). The server never sees or echoes the payload; the vulnerability is in the client-side code. Defenses: output encoding (escape HTML/JS so the payload is displayed as text, not executed) and Content-Security-Policy to restrict where script can load from and forbid inline script where possible.
Cross-Site Request Forgery (CSRF): Concept and Impact
CSRF exploits the fact that browsers automatically send cookies (including session cookies) with every request to the site that set them. If a user is logged in to bank.com and visits attacker.com, a page on attacker.com can contain a form or image that submits to bank.com (e.g. <form action="https://bank.com/transfer" method="POST">...). When the form is submitted (or the image is loaded), the browser sends the user's bank.com cookies, so the server treats the request as legitimate. The user did not intend to transfer money—they just loaded a malicious page. CSRF is a "one-click" or "drive-by" attack for state-changing operations (transfer, change email, delete account). GET requests that change state are especially dangerous (a single <img src="https://bank.com/delete?id=123"> can trigger the action). Defenses: CSRF tokens (a secret value in the form or header that the server validates; the attacker cannot know the token) and SameSite cookie attribute (restricts when cookies are sent on cross-site requests).
Defenses in Detail: Encoding, CSP, Tokens, and Cookie Flags
Output encoding: when you insert user-controlled or untrusted data into HTML, JavaScript, or URL context, encode it so it is treated as data. In HTML context, replace <, >, ", ', & with entities (e.g. < >). In JavaScript context, escape quotes and backslashes and avoid inserting into eval or innerHTML. Use a well-tested library (e.g. OWASP Java Encoder) and encode for the exact context. Content-Security-Policy (CSP): a response header that tells the browser which sources are allowed for script, style, images, etc. Strict CSP (e.g. script-src 'self' or nonces) can prevent execution of injected script even if encoding fails. CSRF token: server generates a random token per session (or per form), stores it server-side, and includes it in forms (hidden field) or in a custom header. On submit, server checks that the token matches; attacker cannot forge it without knowing the token. Cookie flags: Secure (send only over HTTPS), HttpOnly (not accessible via JavaScript—reduces XSS cookie theft), SameSite=Strict or Lax (limits CSRF by not sending cookies on cross-site requests or only on safe top-level navigations).
TLS and Application Security
HTTPS ensures confidentiality and integrity of traffic between browser and server. It does not prevent XSS (the malicious script is delivered as part of the site's own response or via stored content) or CSRF (the forged request is sent over HTTPS with the user's valid cookies). You must implement secure coding: output encoding, CSP, CSRF tokens, and cookie attributes. Next: misconfigurations, including weak TLS ciphers and protocol versions on the server.
Key Takeaway for Lesson 14
XSS is injection of script into pages; reflected (in request/response), stored (persisted), or DOM-based (client-side). Defend with output encoding and CSP. CSRF tricks the browser into sending unintended state-changing requests using the user's cookies; defend with CSRF tokens and SameSite. Protect cookies with Secure, HttpOnly, and SameSite. TLS protects transport, not application logic. Next: misconfigurations and weak TLS.