What is covered in CEH v13 Module 14: Hacking Web Applications?

CEH v13 Module 14 covers attacks against web applications organized around the OWASP Top 10 vulnerability categories. Key topics include three types of Cross-Site Scripting (XSS) — reflected (script delivered via crafted URL), stored (script persisted on server), and DOM-based (vulnerability in client-side JavaScript); Cross-Site Request Forgery (CSRF) attacks and token bypass techniques; injection flaws including SQL injection, OS command injection, and LDAP injection; security misconfiguration (default credentials, verbose error pages, open cloud storage); broken authentication and session management failures; insecure direct object references (IDOR); and vulnerable and outdated components. This domain accounts for approximately 15% of the CEH v13 exam questions, making it one of the highest-weighted web security domains on the exam.

What is the difference between reflected and stored XSS on the CEH exam?

The key distinction is persistence and delivery mechanism. Reflected XSS: the malicious script is embedded in a URL or form submission parameter and reflected back to the victim in the server's response without being stored on the server. The attacker must trick the victim into clicking a specifically crafted link (e.g., via email or social engineering). When the victim clicks, their browser sends the malicious input to the server, which reflects it in the HTML response — the script executes in the victim's browser. Reflected XSS is stateless: the payload exists only in transit. Stored XSS: the malicious script is permanently saved on the target server's database or file system (in comment fields, user profiles, product reviews, forum posts). Every user who views the page containing the stored payload gets the script executed in their browser without any trickery needed beyond visiting the page. Stored XSS is stateful and significantly more dangerous because it can compromise all users of the application automatically, requires no social engineering to spread, and persists until the vulnerable code is patched or the malicious data is removed. On the CEH exam, know that stored XSS is also called 'persistent XSS' while reflected XSS is 'non-persistent' — this terminology appears in exam questions. DOM-based XSS is a third variant where the vulnerability exists entirely in client-side JavaScript (unsanitized use of document.location, document.referrer, or DOM methods like innerHTML) with no server interaction needed.

CEH v13 Module 14: Hacking Web Applications

This module covers attacks against web applications, focusing on the OWASP Top 10 vulnerabilities. Attackers exploit XSS (reflected, stored, DOM-based), CSRF, injection flaws, security misconfigurations, and broken authentication to compromise web application systems and data.

The CEHStudy app carries 11 flashcards for Module 14 across 3 sections — resolve every question by naming the OWASP Top 10 (2021) category first; Broken Access Control leads the list, and stems about object IDs, payloads, or cookie handling all fall out from there.

Key Topics Covered

OWASP Top 10 categories and their evolution in v13
Reflected XSS vs Stored XSS vs DOM-based XSS
Cross-Site Request Forgery (CSRF) attacks and token bypass
SQL injection, command injection, LDAP injection
Security misconfiguration: default credentials, verbose errors
Broken authentication and session management
Insecure Direct Object References (IDOR)

Important Terms & Concepts

OWASP Top 10: The ten most critical web application security risks, updated periodically. Categories include injection, broken authentication, XSS, insecure direct object references, security misconfiguration, and more.

Reflected XSS: Malicious script is embedded in a URL or form submission and executed immediately in the victim's browser. Not stored on the server. Requires tricking user into clicking a crafted link.

Stored XSS: Malicious script is permanently stored on the target server (in comments, user profiles, forums). Every user who views the stored data is affected — most dangerous XSS type.

DOM-based XSS: Vulnerability exists in client-side JavaScript rather than server code. The attack modifies the DOM environment in the victim's browser without server interaction.

CSRF (Cross-Site Request Forgery): Forces an authenticated user's browser to perform unwanted actions on a trusted site. Mitigated with anti-CSRF tokens, SameSite cookies, and re-authentication for sensitive operations.

IDOR (Insecure Direct Object References): Accessing resources by manipulating object identifiers in URLs (e.g., changing ?user_id=100 to ?user_id=101). Allows unauthorized access to other users' data.

How to Study This Module

Know all OWASP Top 10 categories and their descriptions
Differentiate reflected vs stored vs DOM-based XSS with examples
Understand CSRF attack flow and mitigation techniques
Practice identifying web application vulnerabilities in sample code

Frequently Asked Questions

What is the OWASP Top 10?
A standard awareness document for web application security listing the ten most critical security risks. It is updated every few years to reflect evolving threats.

What are the types of XSS attacks?
Three types: Reflected (script delivered via link), Stored (script saved on server), and DOM-based (exploits client-side JavaScript). Stored XSS is most dangerous as it affects all visitors.

Related Modules

Module 13: Hacking Web Servers — web server compromise often leads to application attacks
Module 15: SQL Injection — SQL injection is one of the most critical OWASP Top 10 vulnerabilities

What is Web Application Hacking in Ethical Hacking?

Web Application Hacking is the highest-weighted web security domain on the CEH v13 exam. The module targets vulnerabilities in the application layer — code, inputs, sessions, and business logic running on top of web servers (Module 13) — organized around the OWASP Top 10, the most commonly exploited web application vulnerabilities in production. Module 14 topics account for approximately 15% of CEH v13 exam questions.

Key Concepts in Hacking Web Applications

XSS Vulnerability Classifications (Reflected vs Stored vs DOM-based): Cross-Site Scripting injects malicious JavaScript into pages viewed by other users. Reflected (non-persistent): the payload lives only in the request — attacker crafts a URL, victim clicks it, server reflects it back. Stored (persistent): the payload is saved in the application's database — every visitor executes it automatically. DOM-based: client-side JavaScript unsafely uses user-controllable data (document.location.hash, window.name, document.referrer) to modify the DOM without any server round-trip. The most-tested distinction is reflected vs stored — stored is self-propagating; reflected requires the victim to click. The HttpOnly cookie flag blocks both from exfiltrating session cookies via document.cookie.
CSRF Attack Flow & Mitigation Stack: Cross-Site Request Forgery exploits browsers automatically attaching cookies to cross-origin requests: (1) attacker hosts a page with a hidden form or JavaScript targeting the site, (2) the victim's browser sends the request with the victim's session cookie attached, (3) the target processes it as if the victim initiated it — state change occurs (password change, fund transfer, permission grant). Mitigations: per-session anti-CSRF tokens (unreadable cross-origin due to the Same-Origin Policy), the SameSite cookie attribute, server-side Origin/Referer checks, re-authentication for sensitive operations. CSRF does NOT give the attacker access to data (the Same-Origin Policy blocks reading responses) but CAN force state changes — read vs write is commonly tested.
IDOR & Broken Access Control: Insecure Direct Object References occur when an app exposes an object identifier (database ID, filename, URL parameter) without verifying the requester may access it — /api/orders?order_id=1002 returns order details for anyone who guesses or increments the ID. IDOR is classified under OWASP A01:2021 (Broken Access Control) after the 2021 Top 10 consolidated older categories. Defense: server-side authorization checks on every object access, not just authentication. Indirect references (UUIDs or hashed identifiers instead of sequential integers) reduce risk but are not a complete fix — the server must still verify the user owns that resource.
OWASP Top 10 Evolution (2017 → 2021): Key changes from 2017 to 2021: Insecure Direct Object References (A05:2017) merged into Broken Access Control (A01:2021); Security Misconfiguration (A05:2017) became Vulnerable and Outdated Components (A06:2021); SSRF returned from the 2013 list as A10:2021. The 2021 list: A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection, A04 Insecure Design, A05 Security Misconfiguration, A06 Vulnerable and Outdated Components, A07 Identification and Authentication Failures, A08 Software and Data Integrity Failures, A09 Security Logging and Monitoring Failures, A10 SSRF. Know each category and which attacks fall under it — SQL injection is A03 (Injection), weak TLS configuration is A02 (Cryptographic Failures).

Common Exam Mistakes in Module 14

Mixing up the three XSS flavors: reflected XSS rides in the URL and echoes back in the response; stored XSS persists on the server (a database row) and executes for every visitor; DOM-based XSS moves from an untrusted source to a sink such as innerHTML entirely inside the browser, staying invisible to server-side WAFs. The data path in the stem picks the flavor — stored is the one that reaches everyone.

Treating CSRF and XSS as one client-side problem: XSS runs attacker script in the victim browser with stolen context; CSRF makes the victim browser send a forged request with its own cookies attached, unverified by the application. Defenses differ — output encoding and HttpOnly for XSS; per-request anti-CSRF tokens plus SameSite for CSRF.

Testing access control only in the interface: IDOR (incrementing an object reference like /order/1234) and privilege escalation are server-side authorization failures; a hidden button is not a control. Exam answer: enforce authorization server-side on every request.

Tools Used in Web Application Hacking

Tools the CEH v13 exam references for web application testing:

Burp Suite: the proxy standard — intercept, modify, and replay requests to inject XSS payloads, strip anti-CSRF tokens, and walk IDOR object IDs one at a time
OWASP ZAP: open-source alternative with automated active and passive scanning — the free-tool reference on the exam
SQLMap: automated SQLi detection across parameters (union, boolean blind, time-based, error, out-of-band) — the injection workhorse
Wfuzz: web fuzzer for brute-forcing parameters, files, and headers that directory tools miss
Skipfish / Arachni: content-discovery and multi-framework scanning from the same OWASP-toolbox family
OWASP WebGoat: deliberately vulnerable training application demonstrating the Top 10 flaws interactively — the standard hands-on lab before exam day

Worked Example: One Comment Field, Two Different Flaws

A tester posts a <script> tag into a comment field. If the payload only echoes back to the poster through URL parameters it is reflected XSS; once saved and executed for every visitor reading the thread, it is stored XSS — typically the most damaging flavor. A DOM-based variant never round-trips to the server: location.hash flows into innerHTML client-side, so a WAF watching HTTP traffic sees nothing.

The twist: the same profile page serves another user's data when the tester increments its ID — broken access control, the top of the OWASP Top 10 (2021) list. A fake "account suspended" screen on an invisible iframe over the real page is clickjacking, closed by X-Frame-Options: DENY or CSP frame-ancestors. One test session, three categories; reporting each under the right name separates a passing write-up from a failing one.

How to Study Web Application Hacking for the CEH v13 Exam

To study Module 14 for the CEH v13 exam:

Build a reference table of all 10 OWASP Top 10 (2021) categories: Category Name | Example Attack | Mitigation Technique | CEH Exam Tip. Exam stems classify specific attacks into their category — e.g., "An attacker manipulates a URL parameter to access another user's account" = A01 Broken Access Control (IDOR). Practice 20+ scenarios until each takes under 30 seconds
Hands-on: set up OWASP WebGoat locally (Docker or standalone JAR). Work through all XSS lessons (reflected, stored, DOM-based), the CSRF lab, and IDOR challenges. For each, document the triggering request, the response, and the mitigation that would have prevented it — this mirrors scenario questions asking for the right defense
Memorize XSS payloads per type: Reflected = '' in a URL parameter; Stored = same payload in a comment/profile field; DOM-based = vulnerable JavaScript like document.write(location.hash). Know which HttpOnly/Content-Security-Policy/SameSite flags block which vector
Review related modules: Module 15 (SQL Injection) for deep-dive SQLi techniques in the OWASP A03 Injection category, and Module 11 (Session Hijacking) for how XSS steals session cookies — the XSS-to-session-theft chain is a common exam scenario

Frequently Asked Questions About Web Application Hacking

What is Content-Security-Policy (CSP) and how does it prevent XSS?

Content-Security-Policy is an HTTP response header telling the browser which content sources may execute. A strict CSP (e.g., "default-src 'self'") lets only same-origin scripts run — injected inline or attacker-domain scripts are blocked before execution. CSP complements other XSS defenses: HttpOnly blocks cookie theft but not the XSS itself (the script still executes for DOM manipulation and exfiltration via API calls); CSP stops the malicious script from executing at all. Most effective: both together — CSP prevents execution, HttpOnly limits damage if XSS occurs anyway. A bypass tested on advanced exams: if the policy allows 'unsafe-inline', inline scripts still run — the strongest CSP omits 'unsafe-inline' and uses nonces or hashes. Stems may show a CSP header and ask whether a given attack is blocked.

How does SQL injection differ from other injection flaws in the OWASP Top 10?

All injection flaws share one root cause: user input concatenated into a command (SQL query, OS command, LDAP query, XML document) without sanitization or parameterization. The difference is the target language and impact. SQL Injection (most common): input into SQL queries — read/modify/delete data, authenticate as any user, or in some DBMS configurations execute OS commands. OS Command Injection: input to system() or exec() calls — arbitrary shell commands on the server. LDAP Injection: input into directory queries — enumerate users, bypass authentication, modify attributes. XML Injection (XXE): input processed as XML — read local files, SSRF, denial of service. All four fall under OWASP A03:2021 (Injection). Universal defense: input validation and parameterization — prepared statements for SQL, escaped arguments for OS commands, XML parsers with external entity loading disabled for XXE. Stems may show code snippets and ask which injection type is present.

Related CEH v13 Modules

Module 15: SQL Injection Attacks — deep coverage of the SQLi techniques behind the OWASP A03 (Injection) category
Module 11: Session Hijacking — the impact side of the XSS → cookie theft → session hijack chain