Skip to content
ScopefileGet the app

Module 13Domain 5 of 9Web Application Hacking

Web server attacks and hardening

Module 13 covers attacks on the web server itself (its software, its configuration and the services it leans on, such as DNS and shared caches) and the hardening and patch management that close them. Nearly all of it is a pairing exercise: each server-layer weakness has a control that removes it, and the table below lists nine of them.

Exam
312-50
Domain
5 of 9
Domain weight
14%
This file
~5%
Targets
16

Nine attack classes, their clues and their controls

Module 13 vocabulary, read from the defender's chair
Attack classWhat it does and the weakness it needsWhat an analyst seesFirst control
Server misconfigurationLeftover defaults (sample content, default accounts, version banners) give out information or access nobody meant to publish.Version strings in response headers, default install pages still reachableA hardened baseline, re-checked after every change
Directory traversalPath references in a request are resolved without confinement, so the server hands back files it was never meant to publish.Access-log entries naming system files or parent directories, often encodedCurrent server patches, a low-privilege service account, file permissions that keep system files unreadable to it
HTTP response splittingInput copied into a response header carries line breaks, so the server emits headers, or a second response, someone else wrote.Headers or cookies the application never sets; encoded CR and LF characters in parametersReject or encode CR and LF in header values
Web cache poisoningA shared cache stores a harmful response and serves it to every later visitor, because the response varies with an input the cache key ignores.Many users see the same wrong content at once; a purge clears itKey the cache on every input that changes the response; drop unexpected headers
DNS server hijackingThe site's name resolves to a server the owner does not control, via a compromised DNS server or a weakly protected registrar account.Traffic to the real server drops; users report a lookalike site or certificate warningsRegistrar lock, MFA on DNS accounts, DNSSEC, alerts on record changes
Website defacementVisible content is replaced: an outcome reached through another weakness, usually write access to content.Altered pages, file-integrity alertsFile integrity monitoring, clean backups, then trace the entry point
Web server DoSConnections, threads or bandwidth run out and real visitors are refused; slow-rate variants hold connections open with requests that never finish.Connection slots full at modest bandwidth, or a flood from many sourcesTimeouts, per-client limits, upstream DDoS scrubbing
Password attacks on admin servicesRepeated login guesses against exposed remote-administration or control-panel logins with weak or default passwords.Bursts of failed logins; logins at odd hoursLockout, MFA, admin interfaces on a management network only
Directory brute forcingAutomated requests for guessable paths find content that is published but unlinked, where obscurity stood in for access control.A spike of 404s from one client across many pathsRemove what should not be served; access control on sensitive paths

DNS server hijacking, web cache poisoning and directory brute forcing are the three attacks EC-Council's v13 course outline names for this module.

Where this module scores, and where it does not

Hacking Web Servers is one of three modules in Domain 5, Web Application Hacking, which carries 14% of the exam per EC-Council's CEH exam blueprint v5.0 (checked Oct 11, 2026). Spend your hours on the nine rows above and the patch cycle below. Product version history and tool rosters are the tail: learn to recognize the names, and stop there.

Server layer or application layer

Start every scenario by deciding which layer broke. Server-layer problems live in the server software, its configuration, the operating system or a service around it (DNS, caches, admin logins); application-layer problems live in code the site's developers wrote. If the fix is a configuration change, a patch from the server vendor or a DNS setting, you are in Module 13. If the fix is a change to how the application handles input or sessions, the weakness belongs to the web application module's threat list.

On authorization, one point is specific to web servers: DNS, CDN and hosting are often run by third parties, and a client can only authorize testing of what it owns, with load testing approved separately.

Pairs that get mixed up

  • Directory traversal against file inclusion: traversal reads a file the server should never return; inclusion makes the application load and process a file as part of the page.
  • Defacement against the attack behind it: defacement names the result users see; the technique that made the change possible carries its own label.
  • Hardening against patching: hardening removes what a default install exposes; patching fixes flaws in code you keep. A missing vendor fix calls for patch management; leftover defaults call for a baseline.
  • Patch, hotfix, service pack: a patch fixes a specific flaw, a hotfix is an urgent patch released outside the normal schedule, and a service pack bundles many fixes into one tested release.

Patch management as a cycle

  1. Detect

    Inventory every server and its software versions, then compare against vendor advisories and scans. You cannot patch a host nobody knows exists.

  2. Assess

    Decide which missing patches apply to your servers and how urgently each is needed. A public list such as CISA's Known Exploited Vulnerabilities catalog flags flaws already exploited in the wild. The scoring side is covered in the vulnerability analysis module.

  3. Acquire

    Take fixes only from the vendor's channel and verify signatures or checksums.

  4. Test

    Apply the patch to a staging copy first. A fix that breaks the site in production becomes the outage the attacker never had to cause.

  5. Deploy

    Roll out in an approved change window with a rollback plan, highest-risk servers first.

  6. Maintain

    Confirm the patch took, record it, and watch advisories for the next release.

Check yourself on server-layer scenarios

Answer, then read the notes on the options you passed over: that is where the look-alike terms from the table get pulled apart.

Answered 0/16Hits 0

T-01

A security report highlights reflected XSS, open directory listing, and an exposed database dump. What is the MOST critical immediate action to mitigate the highest-impact vulnerability?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. AA WAF helps against injection-style payloads such as XSS, but it does not remove an already exposed database dump or invalidate credentials that may have leaked from it.
  2. BOutput encoding is the right long-term fix for reflected XSS, yet XSS is lower impact here than a publicly downloadable database containing data and secrets.
  3. CTurning off directory indexing is good hygiene and may hide the file listing, but the dump could still be reachable by direct URL and its secrets remain compromised.
  4. DCorrect: the exposed dump is the highest-impact issue, so containment means removing access to it and recovery means rotating any credentials or keys it may have disclosed.
T-02

An attacker successfully executes a web shell by uploading a file named shell.php.jpg. Which web server misconfiguration allowed this payload to execute?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. ACorrect: some servers, such as Apache with handler mappings by extension, treat a file as PHP if .php appears anywhere in the name, so restricting handlers to the final extension prevents this.
  2. BNull-byte truncation is a different, largely legacy flaw where an embedded terminator cuts off a filename; this filename contains no such character and keeps its .jpg ending.
  3. CTrusting the client-supplied content type is a real upload weakness, but it explains why the upload was accepted, not why the server later executed the file as PHP.
  4. DRandomizing stored filenames makes uploaded files harder to locate, but the execution itself comes from how the server maps extensions to handlers, not from predictable names.
T-03

In a web server architecture, what is the term used to describe the main directory that contains all the site files?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. ACorrect: the document root is the top-level directory the web server serves content from, and anything placed or exposed inside it can be reached through the site.
  2. BWeb_Root is an informal or product-specific label rather than the standard term; the generic name for the served directory used across servers is the document root.
  3. CBase_Dir is not a standard web server term for the served directory; it may appear as an application setting, but it does not name the site's content root.
  4. Dpublic_html is a common folder name on shared hosting that is often configured as the document root, but it is a specific directory name rather than the general term.
T-04

Which vulnerability allows an attacker to navigate outside the web root directory to access files stored in other parts of the filesystem?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. ACorrect: directory or path traversal manipulates file paths so the application reads files outside the web root; canonicalizing paths and restricting file access prevents it.
  2. BCross-domain scripting is not the standard name here, and script-injection issues run code in a victim's browser rather than reading files elsewhere on the server.
  3. CRemote file inclusion makes an application load and execute a file from an external location; the concern is code execution, not navigating the server's own directory tree.
  4. DHTML injection inserts markup into a page that other users see; it affects page content in the browser and does not give access to the server's filesystem.
T-05

An application's input filter explicitly blocks the strings "127.0.0.1" and "localhost" to prevent SSRF attacks. However, log analysis confirms an attacker successfully reached the local loopback interface. Which bypass technique was MOST likely utilized?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. ANull bytes target string termination in file paths and older parsers; they do not turn a blocked hostname into an address the filter fails to recognize as loopback.
  2. BCorrect: hexadecimal, decimal or octal forms of 127.0.0.1 still resolve to loopback, so a string blocklist misses them; checking the resolved address against a deny list closes this gap.
  3. CDNS rebinding is a genuine SSRF technique, but it is more involved; when only literal strings are blocked, an alternate encoding of the same address is the simpler and likelier route.
  4. DThe Host header names the site the client is asking for; changing it does not alter which address the server-side request is actually sent to.
T-06

An attacker targets the web server of an e-commerce platform by sending malicious data as part of a command stream message intended for the database interpreter. This kind of attack is categorized under which OWASP Top 10 web server vulnerability?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. ABroken authentication, renamed Identification and Authentication Failures in the 2021 OWASP list, concerns logins and sessions, not data sent to a database interpreter.
  2. BInsecure deserialization, folded into Software and Data Integrity Failures in 2021, involves untrusted serialized objects rather than commands inserted into a query.
  3. CCross-site scripting runs script in a victim's browser; in the 2021 OWASP list it is grouped under Injection, but the target here is the database, not the browser.
  4. DCorrect: hostile data inserted into a command or query that an interpreter executes is an injection flaw, listed as A03 in the 2021 OWASP Top 10 and still present in the 2025 edition.
T-07

You are assessing a client's web application security and discover that unauthorized users can view PHP error messages. Which file should the client modify to resolve this issue?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. ACorrect: php.ini is PHP's main configuration file, and turning off on-screen error display there while logging errors privately stops leaking details to visitors.
  2. Bindex.php is a page script; suppressing errors in a single file would leave every other script exposed and is not where the server-wide behavior is configured.
  3. Csettings.php is an application-level file in some CMSs such as Drupal; it does not control how the PHP runtime displays errors for the whole server.
  4. Dweb.config configures IIS and ASP.NET applications; it can influence some PHP settings on IIS, but the standard place to control PHP error display is php.ini.
T-08

A custom web application dynamically serves proprietary documents based on user input parameters. Which programmatic remediation strategy is the MOST robust for preventing path traversal vulnerabilities within this specific architecture?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. ACorrect: canonicalizing the requested path and confirming it stays inside an isolated root, ideally by mapping requests to known document IDs, blocks traversal regardless of encoding.
  2. BEncrypting URIs only obscures parameters in transit; once decrypted on the server, an unsafe path is processed exactly as before.
  3. CChecking file extensions controls file types, but traversal sequences can still reach other directories while using an approved extension.
  4. DStripping non-alphanumeric characters is a fragile filter that breaks legitimate names and can be bypassed through encoding, so it is less robust than canonicalization.
T-09

A security team is responding to an incident where an exposed .env file containing live database credentials was discovered on a public web server. Which sequence of actions properly aligns with the Contain, Eradicate, and Recover phases of incident response?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. ARotating secrets matters, but doing it first while the file is still public lets the new values leak too, and the order does not map to contain, eradicate, recover.
  2. BThese are useful hardening steps, but none of them stops the file being downloaded right now, and the leaked credentials stay valid throughout.
  3. CPipeline fixes prevent recurrence later, and deleting the server destroys evidence and service; the sequence skips containment and puts long-term work first.
  4. DCorrect: blocking access stops further leakage (contain), fixing the exposure removes the root cause (eradicate), and rotating the secrets makes any copied credentials useless (recover).
T-10

An automated scanner reports hundreds of directory listing vulnerabilities with low CVSS scores, while a penetration tester manually discovers a difficult-to-find blind SSRF. How should the security team prioritize remediation efforts?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. ACorrect: risk follows exploitability and impact, not count; a blind SSRF can reach internal services or cloud metadata, while many low CVSS v3.1 listing findings carry little real risk.
  2. BQuick wins feel productive, but closing hundreds of low-impact findings first leaves the most dangerous flaw open longer, which is the opposite of risk-based prioritization.
  3. CA confirmed manual finding does not need scanner confirmation; delaying a known high-impact flaw until tooling catches up leaves the exposure open for no benefit.
  4. DScanner CVSS v3.1 base scores lack business context and miss flaws the scanner never detected, so relying on them alone would bury the most serious issue here.
T-11

Which of the following is NOT a method to secure a web server?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. ACorrect: running services the site does not need enlarges the attack surface, so hardening guides say to disable or remove them rather than host them.
  2. BRegular patching closes known vulnerabilities in the server software and its components, so it is a core hardening practice rather than the exception asked for.
  3. CFirewalls limit which ports and sources can reach the server, reducing exposure, so this is a legitimate way to secure a web server.
  4. DA certificate enables encrypted HTTPS, which is protective, so it is not the insecure option here.
T-12

The Code Red worm exploited which vulnerability in Internet Information Services (IIS) to spread itself rapidly across the internet in 2001?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. ASQL injection targets database-backed applications through crafted input; Code Red attacked the IIS server software itself, not an application's queries.
  2. BCorrect: Code Red exploited a buffer overflow in an IIS indexing component in 2001, which let it run code and spread on its own; the fix was a Microsoft patch many servers lacked.
  3. CCross-site scripting runs script in visitors' browsers; it cannot by itself let a worm take over servers and copy itself across the internet.
  4. DWeak passwords enable guessing attacks, but Code Red needed no credentials; it spread by exploiting a software memory flaw in unpatched IIS servers.
T-13

A vulnerability scanner flags a blind SSRF vulnerability on two distinct servers: an isolated on-premises legacy server and a cloud-hosted production instance. How should a security analyst prioritize these findings?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. ALegacy patch levels matter, but an isolated host limits what SSRF can reach, while the cloud host risks credential exposure.
  2. BWaiting for a manual pentest delays response; scanner findings should be risk-ranked and validated, not set aside.
  3. CEqual treatment ignores context: SSRF impact depends on what the server can reach, and a cloud host has far more to lose.
  4. DCorrect: SSRF on a cloud instance can reach the instance metadata service and expose temporary credentials, so it carries higher impact and priority.
T-14

During a penetration testing engagement, an attacker discovers a publicly accessible exposed version control directory on a production web application. Which escalation path is the MOST direct consequence of this misconfiguration?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. ACorrect: an exposed version control folder can let someone reconstruct the repository and its history, including old commits that still hold API keys or deployment secrets.
  2. BVersion control metadata served as static files is read-only to a visitor; exposure leaks information rather than directly granting command execution on the server.
  3. CReading repository files does not trigger recompilation, so this is not a realistic consequence; the real risk is disclosure of source code and secrets.
  4. DSession cookies and admin tokens live in users' browsers and server sessions, not in source control, so this is not the direct consequence of the exposure.
T-15

Which of the following is a configuration file on a web server used to manage which IP addresses are allowed to access certain directories?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. AConfig.txt is a generic filename with no special meaning to web servers; it does not control directory access by IP address.
  2. BSecurity.cfg is not a standard web server file; access rules are configured elsewhere, and a file with this name would be just another document.
  3. CCorrect: .htaccess is Apache's per-directory configuration file, which can allow or deny clients by IP and set other directory rules; the server should refuse to serve it.
  4. DAccess.ini is not a recognized web server configuration file; despite the suggestive name, it does not manage which IP addresses may reach a directory.
T-16

A security analyst utilizes historical internet archives and OSINT footprinting tools to locate a previously exposed legacy backup archive file. Why does this passive reconnaissance technique represent a significant ongoing threat?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. AOld configuration files do not by themselves defeat MFA; session hijacking requires a live session token, which an archived backup would not normally provide.
  2. BDownloaded copies sit on the analyst's machine; altering them has no effect on the target server, so the risk lies in what the files disclose.
  3. CWeb archives crawl public pages and store snapshots; they do not probe internal infrastructure or obtain restricted files, which is why using them is passive.
  4. DCorrect: backups frequently include database passwords, API keys and private keys that were never rotated, so an old copy found in archives can still unlock live systems.

Where Module 13 ends

Is HTTP response splitting still worth learning if modern frameworks block it?

Yes, at the concept level. It stays a named web server attack class, and the idea transfers: any header value built from user input must have line breaks rejected or encoded before the server sends it.

Where does this module stop and Hacking Web Applications start?

Server software, configuration, the host operating system and the services around them belong here. Flaws in the site's own code, such as injection, cross-site scripting and broken access control, belong to Module 14, web application threats.

Is denial of service studied here or in its own module?

Both. Here you only need to recognize a web server being exhausted and pick timeouts, per-client limits or upstream scrubbing. The attack families and their countermeasures live in the denial-of-service module.

Defacement is what users see. The misconfiguration or missing patch underneath it is what you fix.

Sources