1263731 - Don't require referrers for treeherder retriggers and for staring tests

Status: RESOLVED WONTFIX

(Tree Management :: Treeherder, defect)

Description

[Tanvi Vyas[:tanvi]]

Some users universally turn off referrers for privacy reasons.  Or they restrict the referrer to origin only.  Treeherder seems to require the full referrer to:
* login
* star tests
* retrigger tests

Because of this, I have to continually go back and forth in about:config to change my referrer settings when I need to use treeherder.  If it was just for login, I could manage that.  But I have to do it everytime I need to star or retrigger, which gets to be too much.  My other alternative is to use a different browser for treeherder, which seems like too much overhead.

I understand that the referrer check is an attempt to protect against XSRF attacks, but it is not the right way to protect against that attack.  referrers can be missing, spoofed, or changed by proxies.  Instead, you can use token based xsrf protection where the users token is tied to their cookie.  The good thing is that django framework has this protection built in.  From what I undestand, older versions required this referrer.  Updating django (assuming you are using it) should fix this issue for you.

mdn has the same problem.  Here are some related bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=698427
https://bugzilla.mozilla.org/show_bug.cgi?id=789016

Thanks!

Comment 1

[Ed Morley [:emorley]]

We're using Django 1.8 currently, and will update to 1.9 once the extensions we use are compatible (bug 1266065). If Django 1.8 doesn't already have this issue fixed, I'd suggest asking them to backport, since it's the LTS release. We pick up 1.8 point releases regularly, so this would save having to wait on bug 1266065.

It's also likely that for the login part this is Persona's fault. However since Persona is EOL, we'll be moving to another solution as part of bug 1032163 and friends.

Unless there's something specific we're doing wrong with our Django config (please do double check https://github.com/mozilla/treeherder/blob/master/treeherder/config/settings.py), I suspect this is wontfix pending an upstream fix - particularly given this is a Mozilla developer-only site and not general-purpose like MDN, and we're pretty short of bandwidth.

Comment 2

[Ed Morley [:emorley]]

This Django ticket was wontfixed fwiw:
https://code.djangoproject.com/ticket/16870

Comment 3

[Ed Morley [:emorley]]

Digging around in the Django CSRF middleware in the latest Django release (1.9), reveals:

    # Suppose user visits http://example.com/
    # An active network attacker (man-in-the-middle, MITM) sends a
    # POST form that targets https://example.com/detonate-bomb/ and
    # submits it via JavaScript.
    #
    # The attacker will need to provide a CSRF cookie and token, but
    # that's no problem for a MITM and the session-independent
    # nonce we're using. So the MITM can circumvent the CSRF
    # protection. This is true for any HTTP connection, but anyone
    # using HTTPS expects better! For this reason, for
    # https://example.com/ we need additional protection that treats
    # http://example.com/ as completely untrusted. Under HTTPS,
    # Barth et al. found that the Referer header is missing for
    # same-domain requests in only about 0.2% of cases or less, so
    # we can use strict Referer checking.

(See: https://github.com/django/django/blob/1.9.5/django/middleware/csrf.py#L137-L158)

As such I don't believe this is true:

> I understand that the referrer check is an attempt to protect against XSRF
> attacks, but it is not the right way to protect against that attack. 
> referrers can be missing, spoofed, or changed by proxies.  Instead, you can
> use token based xsrf protection where the users token is tied to their
> cookie.

And even if there is a better way to fix this, it needs to be done upstream in Django.

In the meantime I'd recommend using a Firefox addon that either allows whitelisting certain sites, or allows passing the referrer to same-host connections, for example:
https://addons.mozilla.org/en-US/firefox/addon/smart-referer/

Comment 4

[Tanvi Vyas[:tanvi]]

Thank you Ed for looking into this!  I will look into https://github.com/django/django/blob/1.9.5/django/middleware/csrf.py#L137-L158.  Seems like the problem and django has changed since I looked at it a couple years ago.  I need to take a closer look to see if there is a more privacy preserving solution out there for the django framework.

Comment 5

[Ed Morley [:emorley]]

You're welcome - good luck! :-)