I will probably update this post with new examples and screenshots.
One of the features I like to test the most is the 'forgot password' process. Since it may lead to account takeover, or sometimes it is like a riddle that you have to solve by understanding its logic.
In my opinion, the probability of 'forgot password' issues in a web application is 6-7/10. So it is not very common, but not that rare.
1. Some web applications require entering the target email address or username. Then they send an email with the 'forgot password' link. Usually, there is a form there that asks for a new password. While intercepting the request, sometimes the username is sent next to the 'forgot password' token and the new password. The 'username' parameter tells the server to change the password to this account. Note that this process could be combined from several requests, so the whole process should be understood.
2. Another example is a guessable token. Some tokens or 'forgot password' links are combined from guessable data, such as company IDs, timestamps, iterators, etc. An example of such a link is:
Let's say that the 'c' parameter is company ID, 'i' is an iterator, and 't' is some kind of another iterator, maybe an encrypted timestamp.
If we send another reset password request to the same user, we will probably get this link:
As we can see, the 'i' parameter's value has been increased by one, and the 't' parameter's value (in Hexadecimal) also increased. The company ID could also be guessed easily if it is a sequential number or by using other ways.
Now we can send ourselves a reset password request and very fast after that, send a reset password request to our victim. We use the values in the link that was sent to us in order to guess the parameters' values of our victim.
We know that the 'i' value was increased by 1, and we probably know or can guess the victim's company ID. An automated tool can be used for this attack (such as Burp Suite's Intruder) and only a few characters should be guessed. It should take a short moment before guessing the correct link.
3. One of the requests in the 'forgot password' process may send the user's credentials in the URL.
These credentials may be saved in proxy history, browser history, etc. Malicious users who have access to these areas may try to log in or steal the account.
4. Tokens that can be brute-forced and are guessable (such as '9389913'), even if they are random, may lead to account takeovers.
5. Tokens that are not expired after a limited and short amount of time increase the chances of being discovered. Also, allowing several valid tokens at the same time.
6. A *very* common issue (with a *very* low impact probability) is 'forgot password' tokens sent to 3rd parties. Usually, after entering the 'forgot password' link sent to our email address, there an analytics and logs requests sent to 3rd parties. These requests usually contain the reset password token in the 'referer' header or one of the GET or POST parameters. Data leakage from this 3rd parties website, or a malicious user who has access to this data, may compromise users using these tokens. The probability of this attack is increased as the token expiration is higher.
7. Reset password poisoning - sometimes, we can try and send a reset password request with the 'Host' or 'X-Forwarded-Host' headers containing the attacker's server URL. There are cases where an email message will be sent to the victim and contain a link with the attacker server's URL, and the 'reset password' token attached. After the victim enters the link, a request with the 'reset password' token will be sent to the attacker's server.
8. Sending two email addresses - some web applications will also send the victim's token to the attacker in case a similar payload is sent:
email=victim@gmail.com&email=attacker@gmail.com In other cases, instead of using '&' we can try other characters or URL encoding of them.
9. Email flooding - some systems allow sending many 'forgot password' requests without any anti-automation mechanism or other limitations. By sending many requests, we can flood our victim's mailbox.
Thank you,
Orel 🌷
Komentáře