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.

• ✓

  The server returns data from internal services like http://localhost/ or http://192.168.x.x/

  Why this is correct

  A strong indicator of SSRF is when the server's response to an external request inadvertently includes data or error messages that clearly originate from internal network addresses, such as http://localhost/ or http://192.168.x.x/. This suggests the application processed a user-supplied URL that pointed to an internal resource, and then relayed the internal resource's content or status back to the attacker, confirming the server's ability to access and return data from its private network.

• ✓

  The application supports file:// or dict:// URL schemes in user input

  Why this is correct

  The presence of SSRF can be indicated if an application's URL processing component accepts and acts upon non-standard URL schemes like file:// or dict:// within user input. Supporting file:// allows an attacker to read local files on the server, while dict:// can be used to interact with internal dictionary services or potentially execute commands. This lack of strict scheme validation demonstrates the server's vulnerability to fetching resources beyond standard HTTP/HTTPS protocols, a common SSRF vector.

• ✗

  The application reflects user input in the page source without encoding

  Why it's wrong here

  When an application reflects user-supplied input directly into the page source without proper encoding, it signifies a Cross-Site Scripting (XSS) vulnerability, not Server-Side Request Forgery (SSRF). XSS involves injecting malicious client-side scripts that execute in the victim's browser, whereas SSRF exploits the server's ability to make requests to internal or external resources on behalf of the attacker. These are distinct attack types targeting different components of the web application stack.

• ✓

  The application accepts a URL parameter that is fetched by the server

  Why this is correct

  A primary indicator of SSRF is an application feature that accepts a URL as a parameter from user input and subsequently causes the server to fetch content from that specified URL. Examples include image loading services, PDF generators, or webhook integrations. This direct server-side fetching mechanism allows an attacker to manipulate the URL to target internal network resources, external services, or even cloud metadata endpoints, making the server an unwitting proxy for their requests.

• ✗

  The server responds with a different delay when a URL is provided versus a non-URL input

  Why it's wrong here

  Observing a different response delay when providing a URL versus non-URL input is generally not a specific indicator of SSRF. While timing differences can sometimes hint at server-side processing, such as blind SQL injection or XML External Entity (XXE) attacks involving out-of-band requests, they do not directly confirm that the server is making an internal request on the attacker's behalf. SSRF is typically confirmed by observable data leakage or successful interaction with internal services, not merely a timing anomaly.

Go deeper

Related to this question