312-50 Question 302
Single answer▪ Web App ThreatsDuring an authorized web application assessment, you test an e-commerce site's password reset function. The application sends a link such as https://shop.example.com/reset?token=8f3c... to the user's email. While intercepting traffic with a proxy, you modify the Host header in the password reset request to attacker.example.net. The application then emails the victim a reset link pointing to https://attacker.example.net/reset?token=8f3c.... Which web application threat does this most directly demonstrate?
- A
Host header injection leading to password reset poisoning
- B
Cross-Site Request Forgery (CSRF) because the victim receives an unsolicited reset email
- C
Server-Side Request Forgery (SSRF) because the server processes a user-supplied URL
- D
Open redirect because the reset link points to an external domain
Show answer and explanation
Correct answer: A
Explanation
The most direct issue is Host header injection causing password reset poisoning. Many web applications generate absolute URLs for emails by relying on the incoming Host header or related proxy headers. If these values are not validated against an allowlist of trusted domains, an attacker can alter them and cause the application to send security-sensitive links, such as password reset URLs, to an attacker-controlled host. This is dangerous because the token remains valid, and the victim may click the malicious-looking-but-otherwise-expected reset email link. Best practice is to avoid deriving security-sensitive links from client-supplied headers; instead, use a server-side configured canonical base URL, validate host/proxy headers, and deploy frameworks or reverse proxies with strict trusted host settings. This aligns with OWASP guidance on secure password recovery and unvalidated host header handling in web applications.
- A. Correct.
Correct. This scenario is a classic Host header injection issue that results in password reset poisoning. The application improperly trusts the user-supplied Host header when constructing absolute URLs in password reset emails. An attacker can cause the server to generate a valid reset link using an attacker-controlled domain, potentially capturing the victim's reset token and taking over the account.
- B. Incorrect.
Incorrect. CSRF involves tricking an authenticated user's browser into sending unintended requests to a target application. In this case, the core issue is not the victim's browser performing an unwanted state-changing action, but the server trusting manipulated request metadata to build a password reset URL.
- C. Incorrect.
Incorrect. SSRF occurs when a server is induced to make outbound requests to attacker-controlled or unintended internal/external resources. Here, the problem is the application reflecting the Host header into an email link, not the server making a backend request to attacker.example.net.
- D. Incorrect.
Incorrect. Open redirect refers to an application endpoint that forwards or redirects users to a user-controlled destination, typically via a parameter such as next= or url=. In this scenario, the vulnerability is in reset link generation based on the Host header, not an unsafe redirect endpoint.