Study guide
6.4 Cross-Site Scripting (XSS) & CSRF
EC-Council Certified Ethical Hacker CEH
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 CEH Exam Format, Cost & Eligibility 1.2 The Five Phases of Ethical Hacking 1.3 Information Security Fundamentals 1.4 Ethical Hacking Concepts, Scope & Legal Framework 1.5 The CEH Domains & Your Study Priority Map
2 Reconnaissance, Footprinting, Scanning & Enumeration
2.1 Footprinting & Reconnaissance Concepts 2.2 Footprinting Sources & Techniques 2.3 Network Scanning Concepts 2.4 Banner Grabbing, OS Fingerprinting & Scanning Beyond IDS/Firewall 2.5 Enumeration 2.6 Vulnerability Scanning & Countermeasures
3 Vulnerability Analysis & System Hacking Phases
3.1 Vulnerability Analysis Concepts 3.2 System Hacking Methodology Overview 3.3 Gaining Access: Password Attack Concepts 3.4 Privilege Escalation Concepts 3.5 Maintaining Access: Backdoors, Rootkits & Persistence 3.6 Covering Tracks, Anti-Forensics & Blue-Team Detection
4 Malware Threats, Sniffing & Social Engineering
4.1 Malware Concepts and Taxonomy 4.2 Malware Analysis and Detection 4.3 Sniffing Concepts and Layer 2 Attacks 4.4 Sniffing Countermeasures and Detection 4.5 Social Engineering Types and Human Psychology 4.6 Social Engineering and Insider Threat Defenses
5 Network & Perimeter Hacking
5.1 Denial of Service and DDoS Attacks 5.2 Session Hijacking 5.3 Evading IDS and IPS (Defensive Focus) 5.4 Evading Firewalls 5.5 Evading Honeypots and Defensive Deception 5.6 Network Security Controls and Architecture 5.7 Packet Analysis and Secure Protocols for Defenders
6 Web Server & Web Application Hacking
6.1 Web Server Attacks & Hardening 6.2 OWASP Top 10 Overview 6.3 Injection: SQL Injection & Command Injection 6.4 Cross-Site Scripting (XSS) & CSRF 6.5 Authentication, Session & Access-Control Flaws 6.6 API & Web App Security Testing Concepts
7 Wireless Network Hacking
7.1 Wireless Concepts and Standards 7.2 Wireless Encryption 7.3 Wireless Threats and Attack Concepts 7.4 Wireless Security Countermeasures
8 Mobile Platform, IoT & OT Hacking
8.1 Mobile Platform Threats & Security Models 8.2 Mobile Attack Vectors & Risks 8.3 Mobile Device Management & Enterprise Defense 8.4 IoT Hacking Concepts & Defense 8.5 OT, ICS & SCADA Security
9 Cloud Computing & Cryptography
9.1 Cloud Computing Concepts 9.2 Cloud Threats & Attack Surfaces 9.3 Cloud Security Controls 9.4 Cryptography Fundamentals 9.5 PKI & Cryptographic Applications 9.6 Cryptanalysis, Crypto Attacks & Best Practices
6.4 Cross-Site Scripting (XSS) & CSRF
Key Takeaways Explain This Topic AI
Cross-site scripting (XSS) injects attacker-controlled script that runs in a victim's browser in the trusted site's context, enabling session theft, credential capture, and content manipulation.
XSS has three forms: stored (persisted server-side and served to many users), reflected (echoed back from the request, requires a crafted link), and DOM-based (the unsafe sink is entirely in client-side JavaScript).
The primary XSS defense is context-aware output encoding, reinforced by input validation, HttpOnly cookies, and a Content Security Policy (CSP) as defense in depth.
Cross-site request forgery (CSRF) abuses an authenticated user's automatically attached credentials to make the browser perform an unwanted state-changing request the user did not intend.
CSRF is defeated with unpredictable anti-CSRF tokens bound to the session and the SameSite cookie attribute; because XSS can read a CSRF token and forge a request, XSS must be fixed too.
Last updated: June 2026
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
Type Where the payload lives Typical delivery
Stored (persistent) XSS Saved on the server (e.g., a comment, profile field) and served to every viewer No special link needed; any user who views the content is hit — highest impact
Reflected (non-persistent) XSS Echoed back immediately from the request (e.g., a search term in the response) Victim must follow a crafted link or submit a crafted request
DOM-based XSS The unsafe data flow is entirely in client-side JavaScript; the server may never see the payload Client script reads attacker-influenced input and writes it to a dangerous sink
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)
The victim is authenticated to the target site (a valid session cookie sits in the browser).
The victim visits an attacker-controlled page (or opens a malicious email).
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).
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:
- Attack Primary capability Worst-case outcome
- Stored XSS Runs script for every viewer Mass session theft, worm-like spread, full account takeover
- Reflected XSS Runs script for a targeted victim Credential capture, one-victim takeover
- DOM XSS Client-side script execution Same as above, often invisible to server logs
- CSRF Forces a state-changing write Unwanted fund transfer, email/password change, settings tampering
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.