CEH Web Application and Injection Attacks Practice Question
A security analyst identifies that a web application is vulnerable to Server-Side Request Forgery (SSRF). Which TWO of the following are effective mitigation techniques for SSRF?
⚠ Common exam trap
CEH often tests the misconception that blacklisting private IPs is sufficient, but allowlisting and schema restrictions are more robust mitigations.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Disable unnecessary URL schemas (e.g., file://, dict://)
Option A is correct because restricting or disabling dangerous URL schemas such as file://, dict://, gopher://, and ftp:// prevents an attacker from abusing the server's URL-fetching functionality to read local files or interact with non-HTTP services, which is a core SSRF exploitation vector. Option D is correct because an allowlist (positive validation) of permitted domains, URLs, or IP addresses ensures the application only makes requests to explicitly trusted destinations, which is the most robust defense against SSRF since it rejects all unapproved targets by default. Option B is not ideal because blacklisting private IP ranges is easily bypassed using techniques such as decimal/octal/hex IP encoding, DNS rebinding, IPv6-mapped addresses, or redirects, so it is considered a weak mitigation rather than an effective one. Option C is incorrect because increasing HTTP request timeouts only affects how long the server waits for a response and does nothing to prevent SSRF requests from being made. Option E is incorrect because base64-encoding user input does not validate or restrict the destination; the server would still decode and process the URL, so the SSRF vulnerability remains exploitable.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Disable unnecessary URL schemas (e.g., file://, dict://)
Why this is correct
Disabling unnecessary URL schemas, such as `file://`, `dict://`, `gopher://`, or `ftp://`, is a crucial mitigation for Server-Side Request Forgery (SSRF). By restricting the protocols the server can use to make outbound requests, the attack surface is significantly reduced. This prevents attackers from leveraging the vulnerability to access local files, perform port scanning, or interact with internal services using non-HTTP protocols, thereby blocking common exploitation vectors.
- ✗
Use a blacklist to block private IP ranges
Why it's wrong here
Using a blacklist to block private IP ranges is an insufficient and easily bypassable mitigation for SSRF. Attackers can circumvent such blacklists through various techniques, including DNS rebinding attacks where a malicious domain's IP resolution changes from public to private after initial validation. Furthermore, alternative IP address representations (e.g., octal, hexadecimal, or integer encoding) can often bypass simple string-based blacklist checks, allowing access to internal resources.
- ✗
Increase the timeout for HTTP requests
Why it's wrong here
Increasing the timeout for HTTP requests does not address the fundamental Server-Side Request Forgery (SSRF) vulnerability. This action merely dictates how long the server will wait for a response from a requested URL before terminating the connection. While it might affect the timing of an attacker's interaction with an internal service, it does not prevent the server from initiating the malicious request in the first place, leaving the core vulnerability unmitigated.
- ✓
Implement an allowlist of permitted URLs or IP addresses
Why this is correct
Implementing an allowlist (or whitelist) of permitted URLs or IP addresses is a highly effective defense against Server-Side Request Forgery (SSRF). This security measure strictly defines the only external or internal destinations the server is authorized to connect to, enforcing a 'deny by default' policy. Any attempt by an attacker to direct the server to an unauthorized IP address, internal resource, or sensitive cloud metadata endpoint will be explicitly blocked, preventing malicious requests.
- ✗
Encode user input in base64 before passing to URL functions
Why it's wrong here
Encoding user input in Base64 before passing it to URL functions provides no security against Server-Side Request Forgery (SSRF). If the server-side application is designed to decode this input before making the actual request, it will simply revert the Base64 string back to the attacker's malicious URL. Encoding is a data transformation, not a validation or sanitization technique, and therefore does not prevent the server from ultimately making the controlled request.
Go deeper
Related to this question
About these practice questions
One of 913 original CEH practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official EC-Council exam blueprint
This CEH practice question is part of Courseiva's free EC-Council certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CEH exam.