312-50 Question 303
Single answer▪ Web App Hacking MethodologyDuring an authorized web application assessment, you discover that the target site uses a multi-step password reset workflow: the user submits a username, receives a reset link by email, and then sets a new password through a form at /reset/confirm. You notice the reset form sends a POST request containing a reset token in the body, and the application accepts the request even when the HTTP Referer header is missing. The application uses cookies for session management and does not include any anti-CSRF token in the password reset form. Which finding is the most accurate to report based on web app hacking methodology?
- A
The password reset function is vulnerable to CSRF because the state-changing request relies on browser-supplied session cookies and lacks a server-validated anti-CSRF token
- B
The password reset function is vulnerable to SQL injection because the reset token is submitted in a POST request instead of a GET request
- C
The password reset function is secure because the reset token in the request body is sufficient protection against forged requests
- D
The password reset function is vulnerable to clickjacking because the Referer header is not required
Show answer and explanation
Correct answer: A
Explanation
In web app hacking methodology, testers evaluate authentication, session management, and state-changing functions for request forgery weaknesses. Password reset workflows are especially sensitive because they directly affect account access. A key principle from widely accepted guidance such as the OWASP Web Security Testing Guide (WSTG) and the OWASP CSRF Prevention Cheat Sheet is that state-changing requests should not rely solely on cookies or other automatically attached browser credentials. Applications should use robust anti-CSRF defenses such as unpredictable server-validated CSRF tokens, SameSite cookie controls where appropriate, and, in some architectures, additional origin verification. Referer or Origin checking can be a supplemental control, but it is not generally the primary or sole defense. The best report here is that the workflow is potentially vulnerable to CSRF because the form performs a sensitive action and lacks a proper anti-CSRF mechanism.
- A. Correct.
Correct. A password reset confirmation is a state-changing action. If the application authenticates the request using the victim's browser session cookie and does not require a unique, server-validated anti-CSRF token, it may be susceptible to Cross-Site Request Forgery. The absence of Referer validation alone is not the root issue; the main problem is that the application appears to rely on ambient authority from cookies without CSRF-specific protection. In a real assessment, the tester would also verify exploitability by checking whether an attacker can cause the victim's browser to submit the reset request under realistic conditions.
- B. Incorrect.
Incorrect. Whether a parameter is sent via POST or GET does not determine SQL injection risk. SQL injection depends on unsafe server-side handling of input in database queries. A reset token in a POST body does not inherently indicate SQL injection. This distractor reflects a common misconception that request method alone implies a specific vulnerability class.
- C. Incorrect.
Incorrect. A reset token can help authorize the password reset process, but it does not automatically prevent CSRF. If an attacker can induce the victim's browser to submit a valid request that includes the token, or if the token is already present in the victim's browser context during the reset flow, the lack of an anti-CSRF mechanism remains a concern. Security depends on how the token is generated, validated, and bound to user actions, not merely on its presence in the request body.
- D. Incorrect.
Incorrect. Clickjacking and CSRF are different issues. Clickjacking involves tricking a user into interacting with a concealed or framed interface element, typically mitigated with X-Frame-Options or Content-Security-Policy frame-ancestors. Not requiring a Referer header does not by itself demonstrate clickjacking. This option is plausible because both attacks involve browser behavior, but it misclassifies the weakness.