Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Potential for reset password link with token to leak to third-parties via the Referer header #5003

Open
summera opened this issue Jan 16, 2019 · 4 comments

Comments

@summera
Copy link

summera commented Jan 16, 2019

I searched to see if this had been brought up before and couldn't find any open or closed issue or PR that mentioned it. If there is one and I missed it, please let me know.

As discussed in this thoughtbot article the reset password link with the token can be leaked to third-parties (CDN, analytics, links to other third-party domains from your site) via the Referer header which is sent by the browser with all requests from the current page (edit password in this case). To fix this in our app I've done something similar to what they did to solve this in Clearance by temporarily storing the reset password token in the session and redirecting the user back to the password edit page without the reset password token in the url params. The token is then pulled from the session to be used in the form.

I'm wondering if this is something you'd be interested in fixing in Devise and if so I'd be happy to put in a PR.

@tegon
Copy link
Member

tegon commented Jan 16, 2019

There's a discussion about this in this PR: #4366

@sonalkr132
Copy link

Rails started setting Referrer-Policy to strict-origin-when-cross-origin since 5.2 rails/rails@428939b

@tegon
Copy link
Member

tegon commented Mar 14, 2019

I didn't know about that @sonalkr132, thanks for sharing!

I'm more inclined to use the Referrer-Policy header to solve this instead of having to change a bunch of code to try to mitigate this at our side.
Looking at https://caniuse.com/#feat=referrer-policy it seems like the bigger issue with support is on Edge and Safari on iOS. They do support an older draft, though. Setting never or origin in an HTML meta element should do the trick, right?

@antonlitvinenko
Copy link

The Referrer-Policy looks like almost a solution... but we found that it might be not enough.
For example, we use intercom widget on our pages to provide customer support and even with the Referrer-Policy set to strict-origin-when-cross-origin they leak the full request url:
intecom-leaking-referer

Which means that there actually has to be a stronger way to enforce this. In my opinion, the session idea from Clearance sounds nice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

4 participants