CEH Web Application Hacking: Server, Access, and SQL Clues

Which three areas make up the CEH web domain?

Study CEH web application hacking by separating server configuration, application authorization, and SQL query construction. EC-Council's CEH Exam Blueprint v5.0, checked November 3, 2026, assigns 18 questions to Web Application Hacking across Hacking Web Servers, Hacking Web Applications, and SQL Injection. That is a domain total, not 18 questions specifically about SQL injection.

The matrix below is a study aid for distinguishing mechanisms within that scope. It is not an exhaustive list of the domain's topics or a claim that the areas cannot overlap.

Use the CEH exam blueprint guide for the complete domain map. For broader practice, full CEH prep planned for launch includes 1,800 questions across nine domains. Keep separate notes for the three causes above so that one familiar defense does not become your answer to every web scenario.

Which clues point to server configuration?

OWASP's Security Misconfiguration, 2021 edition, checked November 5, 2026, describes configuration weaknesses across the application stack. Examples include unnecessary services, unsafe settings, and overly informative errors. Its prevention guidance supports removing unnecessary components and using a repeatable hardening process. The edition identifies the source of these concepts; its historical ranking is not a current risk ranking.

The following six cases are original classroom examples, not actual exam questions. Each supplies the evidence needed for a limited conclusion.

Case 1: An unnecessary server feature. A training environment has a file-transfer feature enabled. The scenario explicitly says the website does not need it and the deployment checklist never checks whether it is disabled.

The supported concern is unnecessary functionality left enabled by configuration. Remove or disable the unused feature and add that check to the hardening process. Parameterizing a database query does not remove the unnecessary server feature. This case does not establish that anyone exploited it.

Case 2: An overly detailed error. An ordinary failed request produces an error page containing internal file locations and framework configuration details. No evidence shows that input altered a database query.

The stated issue is excessive error disclosure. Review the error-handling configuration so the response does not expose those details. Calling this SQL injection because an error mentions internal systems adds an unsupported mechanism. Likewise, hiding an error message alone would not repair unsafe query construction if separate evidence later established it.

After either case, write the setting or component that needs attention. “Improve security” is too vague to show that you understood the cause.

When is the problem application authorization?

OWASP's Authorization Cheat Sheet, checked November 5, 2026, distinguishes authentication from authorization: establishing identity does not determine every resource or action that identity may use. Its guidance is to deny access by default and validate permissions on every request in the appropriate server-side location.

Case 3: Another person's record. A fictional training portal correctly signs in Maya. It then returns another learner's private assessment record. The case states that the database query uses bound parameters but the server never checks whether Maya may read that record.

The cause is missing authorization for the requested record. Add the permission check for that user and resource. Parameter binding already exists in this example; it cannot decide whether Maya is entitled to the result. Repeating the login check would confirm the same identity without resolving the missing permission decision.

Case 4: A hidden action. An ordinary account cannot see a “publish results” control in the interface. The server nevertheless accepts that account's request to publish because it performs no permission check for the action.

The missing control is server-side authorization for publishing. Hiding the interface control does not supply the server's decision. A harder-to-guess identifier would not replace that decision either. The decisive clue is the server accepting an action the account is not permitted to perform.

If the evidence instead concerns a cookie or someone using another person's session, continue with the CEH sniffing and session-hijacking lesson. Do not assume session takeover merely because an authenticated request was involved.

For recall practice, full CEH prep planned for launch includes 500 flashcards. In your own notes, pair each permission concept with a limitation: confirming identity does not settle record access, and hiding a control does not enforce an action restriction.

What makes a scenario SQL injection?

OWASP's SQL Injection Prevention Cheat Sheet, checked November 5, 2026, describes the key distinction: untrusted data must remain data rather than change SQL syntax. Parameterized queries separate the query structure from bound values. Joining untrusted input into the query text first defeats that separation.

Case 5: Input changes the query. A classroom case states that a search value is joined directly into SQL text. The resulting input changes the query's structure instead of remaining a search value. No executable example is needed to identify the mechanism.

This evidence supports SQL injection through unsafe query construction. Use a parameterized query with separately bound values. Reducing the database account's permissions is also useful, but it does not remove the injection flaw. Suppressing the resulting error message would address disclosure, not how the query is built.

Case 6: Safe binding, excessive privilege. A separate case states that values are bound correctly, but the website uses a database account with administrative privileges even though its task requires only reading a limited set of records.

The demonstrated problem is excessive database privilege. Reduce the account's rights to those needed for its work. The scenario does not establish SQL injection, and “add parameter binding” misses the stated condition because binding is already present. Least privilege limits potential damage; it does not prove that every query or authorization check is safe.

After each SQL case, identify separately what the query construction permits, what the database account permits, and what the requesting user is authorized to do.

Which control matches the problem without claiming too much?

Several plausible answers address a neighboring problem. Use these boundaries when explaining why your choice fits:

• Stored procedures: moving work into a stored procedure is not automatically safe. Unsafe construction of SQL inside it can preserve the injection problem.
• Allowlisted choices: when a query needs a dynamic identifier, use fixed application-owned choices or an appropriate allowlist. Validating a value does not make concatenating it into SQL safe.
• Least privilege: limiting database rights can reduce damage. It does not prevent unsafe input from changing query syntax.
• Server-side authorization: determine whether the user may access that resource or perform that action. Parameter binding cannot make this decision.
• Configuration hardening: address unnecessary components, settings, and error disclosure. A corrected setting does not demonstrate that application permission checks exist.

Try the 20 free CEH practice questions and record the evidence behind each answer. For wider preparation, full CEH prep planned for launch includes a 125-question mock exam. Use the practice-test readiness guide to organize mistakes without treating a practice result as a guaranteed exam outcome.

How do you turn the three-part map into a review checklist?

Use the free CEH study plan to schedule a return to your uncertain area. The CEH study schedule places subject review within broader preparation; the CEH cost and eligibility guide handles the separate decision about your exam route.

Before moving on, explain these fresh examples in your own words:

1. Configuration: a site retains an unused default account after deployment. Identify the configuration issue and explain why changing the way query values are bound would leave that account in place.
2. Authorization: a correctly authenticated trainee can approve another team's work because the server omits an action-permission check. Identify the missing decision and explain why confirming the trainee's identity again is insufficient.
3. SQL construction: values are bound correctly, but a stored procedure assembles another query unsafely from untrusted input. Explain why the stored-procedure label alone does not establish safety.

For any answer you cannot justify, write down the missing distinction, revisit the matching source-backed section, and create a new fictional example. Your next review should test whether you can connect evidence, cause, and control without assuming facts the case never supplied.