Fix insecure password recovery (OWASP A04)

[thiagoaugustocosta]

This solution refers to which of the apps?

A4 - Super Recovery Password

What did you do to mitigate the vulnerability?

The application was vulnerable to an insecure password recovery design that allowed an attacker to enumerate users, obtain their password recovery questions, brute-force the answers, obtain a recovery JWT, and use it to reset the user's password.

The following changes were implemented:

• Removed the /userinfo endpoint, preventing user enumeration and exposure of recovery questions.
• Removed the /recovery endpoint, disabling the insecure question-and-answer recovery mechanism.
• Changed the password reset authorization logic so that JWTs issued with Recovery=true can no longer be used to change passwords.
• Password changes remain available through a normal authenticated session.
• The insecure knowledge-based recovery flow is therefore no longer available.

This approach intentionally fails closed: password recovery through the vulnerable mechanism is disabled until a strong out-of-band recovery mechanism can be implemented.

Did you test your changes? What commands did you run?

The following validation commands were executed:

• go test ./... — completed successfully for all Go packages. The project currently contains no test files, so this validates compilation rather than functional test coverage.
• git diff --check — completed successfully with no whitespace errors.
• The provided brute-force utility was also attempted as part of the attack narrative. However, the practical attack could not be completed reliably because of connectivity problems between the containers in the GitHub Codespaces environment.

Testing was additionally affected by unstable Internet connectivity while completing the challenge during international travel. Since the submission deadline could not be extended, the final validation was completed through source-code analysis and application/code-level checks.

No successful brute-force exploitation is being claimed. The vulnerability was confirmed by analyzing the original /userinfo, /recovery, and /reset flow, and the vulnerable recovery path has been removed from the application.

Vulnerability summary

The original design relied on knowledge-based security questions as a password recovery factor. These questions were exposed through the user information endpoint and their answers could be systematically tested through the recovery endpoint.

This created an insecure recovery flow in which knowledge of low-entropy personal information could lead to a valid recovery token and ultimately an unauthorized password reset.

Security impact

An attacker could potentially:

1. Enumerate valid user accounts.
2. Obtain the recovery questions associated with an account.
3. Automate attempts against the recovery answers.
4. Obtain a recovery token after successful answers.
5. Use the token to change the victim's password.

The mitigation removes the vulnerable recovery path and prevents recovery tokens from being used for password changes.

Validation limitation

The provided brute-force attack tool could not be reliably completed in the GitHub Codespaces environment because of container connectivity issues. This was compounded by unstable Internet connectivity while the challenge was being completed during international travel.

The limitation is explicitly documented here rather than claiming a successful exploitation that was not observed.