[kelvin0]

I've read the article twice, and I'm not totally clear as to what the problem is, and how it's being addressed (web n00b here). Also, this bit:

"Browsers will not send the Referer for resources fetched via HTTP from a document loaded via HTTPS"

So using HTTPS resolves the issue? But breaks analytics?

Any further clarification would be nice, thanks!

[msimpson]

The article is simply pointing out that services which record referrers can inadvertently store live password reset tokens if you're not careful.

For instance, someone places Google Analytics in the head of the default layout for a given site. Now traffic to and from the password reset page, which uses that layout, is being recorded. This means an attacker would only need to gain access to that account, which is probably much less guarded, and gather referrers containing password reset tokens. From there they could quickly try the last few--which might still be active--and easily gain access to one or more accounts within the site.

[kelvin0]

>>...would only need to gain access to that account, which is probably much less guarded..

So "that account" you mention, is it the Google analytics account or the web application (leaking urls) account? Why is it much less guarded?

[msimpson]

I mean the analytics account; and in my experience it is less guarded due to clients handing out access as it's "just reporting" in their eyes.

[mankyd]

The basic observation is that the reset url is sent as the referrer to any 3rd party content that gets loaded on the page. So if you have a facebook link, ads, analytics, cdn, or other random content on the page, they get to see what the reset url is.

This is a valid concern, though it's worth noting that you shouldn't be including 3rd party content you don't trust on any potentially sensitive page in the first place. This includes not only password pages, but potentially ANY logged in page on the site.

Otherwise, you should consider the 3rd party content trusted and move on.

[jordanlev]

The thing about https only applies when an https page is loading assets from a non-http address. But if your site uses https and so does your CDN, then the referer headers are still sent.

[impostervt]

If you're site uses a password reset token email as the article describes, and your Reset Password page loads 3rd party scripts or css, those 3rd parties (and any servers en route to them) may be able to see the password reset token as part of the HTTP Referer header.