CEH Web Application and Injection Attacks Practice Question

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