Sentry: Prevent Referer leaking on password reset page

[mattrobenolt]

Right now when you get a password reset link, the page you end up on contains the reset token in the url.

Doing this causes a problem in which any page redirected to after this, and _especially_ any third party assets being loaded leak this reset token via the Referer header on the request.

While this isn't specifically a problem since the only things we embed are trusted vendors, in the case of SaaS, it's better to just avoid it.

My proposal is to keep the same url, but this endpoint does the following:

• Accepts the request, and puts the token either into the browser session or browser's cookie.
• Redirect away from this url, to a generic password reset form page.
• This new password reset form page then takes the values from your session or cookie.

Doing this mitigates any ability for leaking data through any Referer header in the future.

I am open to other proposals, but this is the best that comes to my mind.

[Kacppian]

Can I work on this?

[mattrobenolt]

@Kacppian Sure!

[Kacppian]

Hey, I have some doubts. Couldn't find a place to ask questions. I tried irc #sentry but couldn't find anyone to talk to or maybe I'm bad at using my irc client. Can you please help me?

On lostpasswordhash.py, lno - 68, I see the template of the email is for both set_password and recover_account. But grep reveals no service actually is using template as 'set_password'. May I know why? If this is the wrong way to reach out, I'm extremely sorry.

[Kacppian]

My idea of solving this was to use recover_account view to set the token in the browser session and redirect to set_password view to be able to set the password without the hash in the URL. That led me to see if set_password template is being used

[markstory]

I see the template of the email is for both set_password and recover_account. But grep reveals no service actually is using template as 'set_password'. May I know why?

The set_password email is unused. It was added in e962e56a912e27f79d6acc3b77cf17fe1f34a313 but doesn't appear to ever have been used. There is a set_password flow for when SSO is disabled on an organization but that is a separate thing.

Your plan of setting into the session and redirecting sounds like a good plan to me.

[le0pard]

Hello.

I think to resolve this problem sentry server just need provide header Referrer-Policy with value strict-origin-when-cross-origin : https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy

[ezzy1337]

I'd be happy to take a crack at this for Hacktoberfest!