When adding a “Password Reset” function to your application it is especially important to ensure this has the same security considerations as any other critical function within the application. Due to the nature of resetting a user’s password, along with many security considerations being overlooked, it is not uncommon for attackers to spend extra time trying to bend these types of functions to their will to try and gain unauthorised access.
There are some key considerations that must take place when implementing this functionality to ensure it cannot be abused by attackers:
Let’s take a look in the case of an application Alchemy Security tested recently.
Problem one – static password reset tokens
For each user a password reset token was created at time of account creation and stored in the database as part of the credentials. This meant the account had a single reset token valid for the lifetime of the account, independent of how many times the user forgot their password.
As the token was not invalidated after a period of time or once used, this meant that even if the legitimate user reset their password, an attacker still had access to the token and in turn the account, another weakness detailed in problem two. It also appeared likely that the token could not be invalidated without deleting and re-creating the account.
The token was returned in a ‘HTTP 200 OK’ response from the API endpoint, so while not visible within the web page itself, was still easily obtainable by an attacker simply using an interception proxy such as Burp Suite. This meant that an attacker could easily write a script to test a list of usernames and obtain the token for each by parsing the resulting response.
To make matters worse, all of the above actions do not require any user authentication. Allowing an un-authenticated attacker to easily enumerate both usernames and their associated reset tokens without restriction or valid credentials.
Problem two – excessive token permissions & incorrect authorisation checks
The biggest problem was the token itself had excessive permissions and was able to perform almost any action for which the user already had permissions. For example, the token could be used to update the user’s profile (which then leaked the user’s password hash, another big issue!) or perform search functions to access data for which the user had access to.
These two issues meant that the application was prone to two critical security issues:
These issues can be easily be avoided in the following manner:
Red teaming is not a new concept within the cyber security community. However in Australia, Red Teaming is a relatively new term for most organisations. In this blog post we'll take a dive into: What differentiates a Red Team engagement from a Penetration Test. Why you shouldn't consider a red team engagement (You totally should.) […]Read More
When adding a “Password Reset” function to your application it is especially important to ensure this has the same security considerations as any other critical function within the application. Due to the nature of resetting a user’s password, along with many security considerations being overlooked, it is not uncommon for attackers to spend extra time […]Read More