6.4 Cross-Site Scripting (XSS) & CSRF

Cross-Site Scripting (XSS)

Cross-site scripting (XSS) is an injection flaw where an application includes attacker-controlled data in a page without proper neutralization, so the victim's browser executes attacker script in the trusted site's security context. Because the script runs as the site, it can read accessible cookies and tokens, capture keystrokes and credentials, perform actions as the victim, deface page content, or pivot to a full account takeover. The root cause is the same as all injection: untrusted data crossing into an interpreter — here, the browser's HTML/JavaScript parser. In the OWASP Top 10:2025, XSS is grouped under Injection (A05).

The Three Forms of XSS

A key exam distinction: stored XSS is the most dangerous because one injected payload hits every viewer, while DOM-based XSS can be invisible to server-side defenses because the tainted data never reaches the server — it flows from a source (like the URL fragment) to a sink (like innerHTML) entirely in the browser.

XSS Defenses

• Context-aware output encoding (primary) — encode data for the exact context where it is rendered (HTML body, attribute, JavaScript, URL). Correct encoding makes injected markup inert.
• Input validation — reject input that does not match an expected format; reduces the attack surface but is not sufficient alone.
• Content Security Policy (CSP) — a response header that restricts which script sources may execute; a strong CSP can neutralize many XSS payloads even when an encoding mistake slips through.
• HttpOnly cookies — prevent client-side script from reading session cookies, limiting session-theft impact.
• Framework auto-escaping — modern templating engines encode by default; the danger is opting out with raw-HTML sinks (e.g., dangerouslySetInnerHTML).

Testers typically discover and validate XSS with an intercepting proxy such as Burp Suite or OWASP ZAP, injecting benign markers to see whether input is reflected unencoded.

Cross-Site Request Forgery (CSRF)

Cross-site request forgery (CSRF) exploits the fact that browsers automatically attach a user's credentials (such as session cookies) to requests to a site the user is logged into. An attacker tricks the victim's browser into sending a state-changing request to that site — the server sees a perfectly authenticated request and performs the action (change email, transfer funds, alter settings) that the user never intended. CSRF does not let the attacker read the response; its power is causing an unwanted write.

CSRF Mechanics (step by step)

1. The victim is authenticated to the target site (a valid session cookie sits in the browser).
2. The victim visits an attacker-controlled page (or opens a malicious email).
3. That page causes the browser to issue a request to the target site for a sensitive action (via an auto-submitting form, an image tag, or a script).
4. The browser auto-attaches the victim's session cookie; the server cannot distinguish the forged request from a legitimate one and performs the action.

CSRF Defenses

• Anti-CSRF tokens (primary) — a unique, unpredictable token tied to the user's session is required on every state-changing request and validated server-side. An attacker's forged request cannot include the secret token.
• SameSite cookie attribute — instructs the browser not to send the session cookie on cross-site requests (Lax or Strict), blocking the core mechanism.
• Re-authentication / confirmation for high-value actions.
• Verify Origin/Referer on sensitive requests as a secondary check.

The XSS–CSRF Link (a favorite CEH point)

Anti-CSRF tokens assume the attacker cannot read the token. If the site is vulnerable to XSS, attacker script running in the page can simply read the token and forge a valid request, defeating CSRF protection. Therefore XSS is not just its own risk — it undermines other defenses, which is why both must be remediated. This dependency is exactly the kind of cross-control reasoning CEH likes to test.

Impact and Real-World Consequences

Understanding why these flaws matter helps you pick the right answer under exam pressure:

A subtle but important exam point: CSRF and XSS attack different trust relationships. CSRF abuses the trust a site places in the user's browser (it auto-sends credentials), so it can force actions but cannot read responses. XSS abuses the trust a user's browser places in the site (it runs the site's scripts), so it can both read data and act. Mixing these up is a common distractor. The defensive bottom line CEH rewards: encode output to stop XSS, use anti-CSRF tokens plus SameSite cookies to stop CSRF, and fix XSS regardless because it can defeat the token defense.