4

I have typically implemented password reset functionality by sending a link that included something like this:

http://example.com/pwreset?id=userId&resetToken=superSecretResetToken

On my pwreset page I will typically request a few resources from third parties. From what I understand, since I have sensitive information in my URL at this point, it could be revealed to these third parties in the referer header when the request is made.

While I trust these parties, I would prefer that they don't see URLs that would give them the ability to reset passwords or have this information logged on their end and available should their system be compromised.

A few questions:

  • Is it possible to implement a password reset page that includes third party resources without disclosing the referer?
  • Where else, besides the third party, would this information be visible (if anywhere)?
Improve this question

3 Answers 3

Reset to default
5

Yes. This could solve your problem:

  1. mysyte.com/?token=xxx sets a cookie and redirects to mysite.com/changepwd without returning any markup
  2. mysite.com/changepwd recognises the user by the cookie and can safely request for 3rd party resources without leaking the token through referrer headers.

To answer your second question: if the resource is over http, then any network nodes between you and the 3rd party would be able to see the token. If it is https, then it's only the 3rd party that will get the token.

Improve this answer
2

Make the token single-use: expire it when the page is first requested, so it's no longer of any use to anyone after that point should leakage occur.

You can also respond to the initial request with a redirect to a neutral URL which you don't mind being leaked (having set up a cookie/session to remember the authentication). However this still leaves the browser history, server/proxy logs and client-side extensions as possible sources of leakage.

Improve this answer
4
  • Interesting, just to clarify - the token would expire when the user submitted the page for the first time rather than when they requested it, right?
    – Abe Miessler
    Commented Oct 6, 2014 at 20:38
  • No, the leakage can happen between the initial request and the submission, so the token must expire on initial request. The authorization that token implies can be moved elsewhere, eg to another second-stage token in a hidden input on the form.
    – bobince
    Commented Oct 7, 2014 at 10:35
  • Interesting, how would you submit the new password request if the token is already expired?
    – Abe Miessler
    Commented Oct 7, 2014 at 15:16
  • Expiring the link on the initial request can cause problems such as when email scanning systems follow the links and cause them to expire.
    – SilverlightFox
    Commented Oct 7, 2014 at 19:49
0

It didn't exist was little known back in 2014 when this question was asked (First Public Working Draft was from 7 August 2014, question asked on October 2014), but the Referrer Policy allows precisely to do that, stating (through a header) that no Referrer should be sent for this site requests, that only the domain is to be provided, etc. (it is then up to the different clients to support/honor it or not)

For this use case, Valentinas answer works perfectly with no need for Referrer Policy support, though.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .