reset password flow leaves site vulnerable to phishing attacks

Nobody has claimed this yet.

The reset password flow puts a redirect_url in the password link that the user receives in email. This parameter can be changed by an attacker, and use it to send emails to people with a link that points to your site and then redirects to their site. Example:
- Attacker creates a site that matches your sites branding and has a login screen.
- Attacker creates an account on your site.
- Attacker initiates the reset password flow.
- Attacker gets the URL, changes the redirect_url parameter in the URL to go their site.
- Attacker emails the link to random people that are members of your site, telling them something that would cause them to log in (such as they have a new message, or whatever. How they get these emails is immaterial, while it can be hard, attackers find ways.
- Users get the email, see the link looks legit and opens it. Do not assume people are smart enough to not click on links in email, or from emails they don't know. A lot of people are not tech savvy and don't notice these things.
- Users try to login and now have just given the attacker credentials on your site. Do not assume that people will notice the URL changed. A lot of people are not tech savvy and don't notice these things.

I don't understand the motivation for putting the redirect_url parameter in the password reset link. Why isn't this a configuration parameter? If there is a valid reason for this being in reset link, then the token needs to also include signing all the URL parameters, and then you can verify the URL hasn't been tampered with.

If you disagree that this isn't a legit attack vector, I'll just say that I've already had multiple 3rd party "researchers" (hackers looking for $$) reach out to me about this issue on our site.

We're using version 1.1.3. I apologize if this has been fixed already, but I tried to examine the issues and the source code and it still looked like an issue.

Start by tracing the password reset flow in version 1.1.3, focusing on how redirect_url is placed in the emailed password link and later handled. Confirm that an attacker cannot use the flow to redirect users to an external phishing site, and verify the behavior with coverage for tampered redirect URLs.

Written by the indexing model from the issue text.