Skip to content

Fix insecure password recovery design (OWASP A04:2021) - #654

Closed
thamiresbione wants to merge 1 commit into
globocom:masterfrom
thamiresbione:thamires-fix-insecure-password-recovery
Closed

thamiresbione wants to merge 1 commit into
globocom:masterfrom
thamiresbione:thamires-fix-insecure-password-recovery

Conversation

@thamiresbione

Copy link
Copy Markdown

This solution refers to which of the apps?

A4 - Super Recovery Password

What did you do to mitigate the vulnerability?

The password recovery flow was vulnerable to account takeover because it relied only on security questions, which could be exposed and brute-forced without authentication or attempt limits.

The mitigation disables the insecure recovery flow instead of trying to patch the individual weaknesses:

  • Removed the /userinfo endpoint, which exposed security questions and allowed user enumeration.
  • Updated /recovery so it no longer processes security question answers and returns a neutral response.
  • Prevented recovery tokens from being used to change passwords.
  • Added rate limiting to /register, /login, and /recovery.
  • Removed recovery token logging from the server output.

Vulnerabilities addressed

Vulnerability CWE OWASP Top 10:2021 Severity Status
User enumeration via /userinfo CWE-203 A04 Insecure Design High Fixed
Security questions exposed without authentication CWE-640 A04 Insecure Design High Fixed
No rate limiting on /recovery, /login, /register CWE-307 A07 Identification and Authentication Failures High Fixed
Recovery JWT valid for 72h and reusable CWE-613 A04 Insecure Design Critical Fixed
Recovery token printed to server logs CWE-532 A09 Security Logging and Monitoring Failures Medium Fixed
Security question answers stored in cleartext CWE-256 A02 Cryptographic Failures Critical Documented, not fixed
JWT claim named admin for a recovery boolean CWE-1078 A04 Insecure Design Medium Documented, not fixed
/register leaks single-account existence CWE-203 A04 Insecure Design Medium Mitigated through rate limiting

The main approach was to remove the insecure password recovery mechanism rather than attempting to make security questions secure, since knowledge-based recovery cannot reliably prove a user's identity.

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

Yes. The changes were tested by reproducing the original attack scenario and verifying that the attack could no longer be successfully performed.

The following tests were performed:
image

@thamiresbione
thamiresbione deleted the thamires-fix-insecure-password-recovery branch September 15, 2026 19:44
@thamiresbione
thamiresbione restored the thamires-fix-insecure-password-recovery branch September 15, 2026 19:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant