Closed Bug 1253914 Opened 4 years ago Closed 4 years ago

Cross domain referer leakage when resetting the user password

Categories

(bugzilla.mozilla.org :: General, defect, minor)

Production
defect
Not set
minor

Tracking

()

RESOLVED FIXED

People

(Reporter: kathuriaranjan, Assigned: dylan)

Details

(Keywords: sec-low, wsec-authentication)

Attachments

(3 files)

Attached video bugzilla.mp4
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160210153822

Steps to reproduce:

The password reset token is leaking via referer.

1. Ask for a password reset token for bugzilla.
2. Open that link.
3. Now click on any external link (expect for mozilla external links)
4. Capture the request coming from that external link . The bugzilla password token will be in the referer.


Actual results:

The token is leaking via referer.


Expected results:

The request shouldn't contain the password reset token.

To patch this :

1. Either allow the password reset token page to accessed only once (doesn't matter if user changes the password at that time or not.)

2. Stop leakage via referer.

Ref:

1. http://security.stackexchange.com/questions/69074/how-to-implement-password-reset-functionality-without-becoming-susceptible-to-cr

2. https://open.edx.org/CVE-2015-2286
Assignee: website → user-accounts
Component: bugzilla.org → User Accounts
Summary: Cross domain referer leakage . → Cross domain referer leakage when resetting the user password
Severity: normal → minor
HTTPS doesn't send referer to HTTP, right? So if your Bugzilla uses HTTPS, it has to be an HTTP link.

Also, what external links appear on the password reset page?

Having a password reset token in a URL sent by email is a pretty common pattern across the web.

Gerv
Yes the reset token in URL is common but my point is to prevent the token leakage. 

In the attached video poc - The password reset page is showing "Login with github" too and on clicking on it the page is redirected to github.com and the request will contain the password reset token in referer.
Here: http://prnt.sc/acbqvh
Flags: sec-bounty?
Assignee: user-accounts → dylan
This is about the reset_password.cgi, a bmo customization. 

Upstream's password reset page does not have any external links. Moving to BMO while I continue investigating.
Component: User Accounts → General
Product: Bugzilla → bugzilla.mozilla.org
QA Contact: default-qa
Version: unspecified → Production
Alright, this is to do with the tokens.cgi (sorry for my initial confusion).

1) The referer header is coming from the POST request that the login button makes. There no "links" involved.
2) The first step in that process is github.cgi, so we can do something before anything gets to github (in this case)
3) Changing the password token to be "single view" would be complicated as it is needed once to show the reset page and another time to change the password.
4) we should a <meta name="referrer" content="origin"> to bugzilla to prevent any similar leakage. I see very little downside to this. Perhaps origin-when-crossorigin?

In addition to #4, github.cgi is going to refuse to redirect to github if the refer header references token.cgi (and some other suspect pages). Also, the password reset pages shouldn't show login links at all.
I think this is a low risk, particularly because it's github, which we already rely on for authenticating accounts.
Status: UNCONFIRMED → NEW
Ever confirmed: true
There is one more endpoint which have the referer leakage.

When an account is created a confirmation email is sent user email address.

Again if on opening this confirmation link and clicking on any external link the token is leaked via referer.
https://vimeo.com/158131576

Password: bugzilla
Attached patch 1253914_1.patchSplinter Review
part 1: don't redirect to github when the referer looks suspicious.
Attachment #8727813 - Flags: review?(dkl)
Attached patch 1253914_2.patchSplinter Review
part 2:

This will truncate the referer to the part before the first "/".

With this page, part 1 should never engage (but it will if the browser is old and doesn't support this). Defense in depth and all that.
Attachment #8727815 - Flags: review?(dkl)
Comment on attachment 8727813 [details] [diff] [review]
1253914_1.patch

Review of attachment 8727813 [details] [diff] [review]:
-----------------------------------------------------------------

::: github.cgi
@@ +41,5 @@
>      ThrowCodeError("github_invalid_target", { target_uri => $target_uri })
>        unless $target_uri =~ /^\Q$urlbase\E/;
>  
> +    ThrowCodeError("github_insecure_referer", { target_uri => $target_uri })
> +      if $cgi->referer =~ /(reset_password\.cgi|token\.cgi|t=|token=|api_key=)/;

the referer may not be present, and will likely trigger an uninit warning here.
(In reply to Byron Jones ‹:glob› from comment #11)
> Comment on attachment 8727813 [details] [diff] [review]
> 1253914_1.patch
> 
> Review of attachment 8727813 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: github.cgi
> @@ +41,5 @@
> >      ThrowCodeError("github_invalid_target", { target_uri => $target_uri })
> >        unless $target_uri =~ /^\Q$urlbase\E/;
> >  
> > +    ThrowCodeError("github_insecure_referer", { target_uri => $target_uri })
> > +      if $cgi->referer =~ /(reset_password\.cgi|token\.cgi|t=|token=|api_key=)/;
> 
> the referer may not be present, and will likely trigger an uninit warning
> here.

++ for identifying that people with drastically custom setups use Bugzilla. :-/
(there would normally be one from a POST request, but obviously some people turn off referers). I'll fix that after review.
Comment on attachment 8727815 [details] [diff] [review]
1253914_2.patch

Review of attachment 8727815 [details] [diff] [review]:
-----------------------------------------------------------------

r=dkl
Attachment #8727815 - Flags: review?(dkl) → review+
Comment on attachment 8727813 [details] [diff] [review]
1253914_1.patch

Review of attachment 8727813 [details] [diff] [review]:
-----------------------------------------------------------------

r=dkl

::: github.cgi
@@ +41,5 @@
>      ThrowCodeError("github_invalid_target", { target_uri => $target_uri })
>        unless $target_uri =~ /^\Q$urlbase\E/;
>  
> +    ThrowCodeError("github_insecure_referer", { target_uri => $target_uri })
> +      if $cgi->referer =~ /(reset_password\.cgi|token\.cgi|t=|token=|api_key=)/;

if ($cgi->referrer && $cgi->referer =~ /(reset_password\.cgi|token\.cgi|t=|token=|api_key=)/);
Attachment #8727813 - Flags: review?(dkl) → review+
To ssh://gitolite3@git.mozilla.org/webtools/bmo/bugzilla.git
   9cc89d3..844c623  master -> master
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Pushed
Group: bugzilla-security
sec-bounty?
Fixed confirmed.

Thank you Ranjan, we appreciate your report. 

Bounties are not typically paid for low findings.
Flags: sec-bounty? → sec-bounty-
You need to log in before you can comment on or make changes to this bug.