Fix insecure password recovery design (OWASP A04:2021) - #654
Closed
thamiresbione wants to merge 1 commit into
Closed
thamiresbione wants to merge 1 commit into
thamiresbione wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
/userinfoendpoint, which exposed security questions and allowed user enumeration./recoveryso it no longer processes security question answers and returns a neutral response./register,/login, and/recovery.Vulnerabilities addressed
/userinfo/recovery,/login,/registeradminfor arecoveryboolean/registerleaks single-account existenceThe 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:
