312-50 Question 345
Single answer▪ Web API, Webhooks, and Web ShellDuring an authorized assessment, a company asks you to review a public-facing web application that uses a REST API and a webhook feature to notify third-party systems when support tickets are created. You discover that the webhook configuration endpoint accepts arbitrary callback URLs and sends a JSON POST containing ticket data to the supplied address. The application does not validate the destination beyond basic URL formatting. The client is specifically concerned about attackers gaining command execution on internal systems. Which issue represents the most immediate and realistic security risk in this design?
- A
An attacker can use the webhook feature for server-side request forgery (SSRF) to reach internal services, potentially interacting with administrative endpoints that could lead to remote code execution or web shell deployment
- B
An attacker can force the API to use only HTTP/2, which directly creates a web shell on the application server
- C
An attacker can exploit the webhook callback to bypass TLS certificate validation on all outbound connections and automatically dump database credentials
- D
An attacker can use the webhook feature to change the REST API from JSON to XML, which by itself results in command execution on the host
Show answer and explanation
Correct answer: A
Explanation
The best answer is the SSRF scenario caused by accepting arbitrary webhook destinations. Webhooks are designed to make outbound HTTP requests, so if an application allows untrusted users to define callback URLs without strict validation, authentication controls, or allowlists, the server can be abused as a proxy into internal networks. In practice, this can expose internal REST APIs, localhost-only management interfaces, cloud instance metadata services, container orchestration endpoints, or debugging panels. If any of those internal services have command-execution flaws or unsafe deployment features, the attacker may escalate from SSRF to remote code execution and ultimately deploy a web shell. This aligns with common guidance from OWASP on SSRF prevention and API security best practices. Relevant references include the OWASP Server-Side Request Forgery Prevention Cheat Sheet and the OWASP API Security Top 10, especially risks related to security misconfiguration and unsafe consumption of external or user-controlled resources. From a CEH perspective, the candidate should recognize that the webhook itself is not the web shell; rather, the dangerous design flaw is the trust placed in attacker-controlled callback URLs, which can be chained into deeper compromise.
- A. Correct.
Correct. Allowing arbitrary webhook callback URLs without proper allowlisting or destination validation is a classic SSRF risk. In a real environment, an attacker may register a callback pointing to internal resources such as localhost services, cloud metadata endpoints, internal admin APIs, or management consoles not exposed externally. While the webhook itself does not automatically create a web shell, SSRF can be chained with vulnerable internal services or unsafe admin endpoints to achieve remote code execution and eventually web shell placement. This is the most immediate and realistic concern tied to the scenario.
- B. Incorrect.
Incorrect. HTTP/2 is an application-layer protocol version and does not inherently create a web shell or command execution condition. A protocol choice alone is not a direct path to code execution. This option reflects a misconception that transport or protocol changes automatically imply host compromise.
- C. Incorrect.
Incorrect. Weak or missing outbound TLS validation is a separate security problem, but it is not implied by the scenario. Even if certificate validation were poor, that alone would not automatically dump database credentials. The statement combines multiple unrelated effects into one unsupported conclusion.
- D. Incorrect.
Incorrect. Changing data serialization from JSON to XML does not by itself cause command execution. XML can introduce risks such as XXE if parsers are insecurely configured, but the scenario describes webhook destination validation issues, not unsafe XML parsing. This option is a plausible distractor because XML-related attacks are common in API discussions, but it does not match the immediate risk here.