Password reset token leak via HTTP referer

[williantenfen]

The reset password token is leaking through the HTTP referer header ... This happens when user clicks at the link sent to their email and when the page is rendered with the token at the URL, if there is some subsequent requests to CDN/analytics or malicious JS , the token will be present at the REFERER header of this requests... As reported at here: https://robots.thoughtbot.com/is-your-site-leaking-password-reset-links A solution will be to store the token to session and then redirect to the page without the token at the URL ...
Is there any chance to change this behavior to current versions?

[joshbuker]

If you open a PR for this, we can definitely take a look and push out a new version. We'd also want to push to the 0.9.x branch and fix the security issue if possible.

[ebihara99999]

Hi @athix
I looked over the issue, wondering which way is favorable, and I would be happy if you offer a suggestion.

The link offers 2 solutions: session based approach and immediate invalidation approach.
The first one is, as @williantenfen mentioned, is to store a token in session. This needs to modify documentation or templates because the password reset feature is implemented only in the model layer.
To embed a token to session instead of url, the following needs to be done:

• Modify resources :password_resets to resource :password_resets in config/routes.rb.
• Modify edit_password_reset_url(@user.reset_password_token) to edit_password_reset_url in app/mailers/user_mailer.rb
• Add a token to session after @user.deliver_reset_password_instructions! succeeds in app/controllers/password_resets_controller.rb.
• Modify params[:id], which stores a token, to session[:token] not to depend on url parameters including a token in app/controllers/password_resets_controller.rb.

To complete these instructions, it's required to modify documentation and generated templates.

The second approach is achieved by adding visited flag to database or session and modify #load_from_reset_password_token to set the flag. At the same time, it's necessary to remove implementions related to reset_password_token_expires_at and reset_password_email_sent_at because this way no longer needs them.

[ebihara99999]

I'm sorry I don't intend to reference the commits from this issue. It's a mistake.

[ebihara99999]

Hi @Ch4s3, would you suggest the way to go? I prefer the second way; because the most of the fix in the first way is about the documentation, it seems difficult to check if the modification is correct.

[ebihara99999]

Hi @athix and @Ch4s3
I asked the direction about how to fix, the both are unclear and seems to be hard to answer...
To clarify I opened a PR. I appreciate if you check it.

[Ch4s3]

Sorry, I've been awol for a bit. I'm reviewing now.