CSRF too strict when no referer is present

[rtux]

For privacy reasons, users may decide to stop their browser from sending referer headers, which is fine with probably 99.9% of the webpages. I recently had troubles logging into launchpad, which uses django’s csrf-protection and it turned out to be due to the missing referer header from my browser.
So just the fact, that the header is missing should not imply, that the request is invalid.

This concerns mainly the function django.middleware.csrf.CsrfViewMiddleware.process_view

[Paul McMillan]

This is intentional and is not likely to change. We are looking at adding support for the Origin header, which has similar functionality, but we will not remove the requirement entirely. We only require the referer header in the case that you're coming from an SSL encrypted Django site back to that same site, in which case the privacy implications of blocking the header are pretty nonexistent.

Instead of blocking the header altogether, you might consider an addon that does something more intelligent like blocking it only when moving from one domain to another.

Unfortunately, this check is absolutely necessary for the security of Django's CSRF protection. Without it, we can't prevent man-in-the-middle attacks on SSL sites. We made the decision that preventing MITM was a more valuable tradeoff than breaking sites for the small minority of users who block the header in a fashion which does not improve privacy.

[rtux]

Thank you for the detailed explanation!

[Luke Plant]

For reference, this Firefox add-on looks like it implements the kind of referer blocking you need: ​https://addons.mozilla.org/en-US/firefox/addon/smart-referer/

(I do not know if you are using Firefox or not).

[ilf]

I'm hitting this on 1.5 and find it very annoying. There's also a lengthy discussion on this over here: ​https://bugs.launchpad.net/launchpad/+bug/560246

[Jon Dufresne]

This issue came up recently on django-developers: ​https://groups.google.com/forum/#!msg/django-developers/4ZDBMulE-W0/_iKRIGctxccJ

One recent development that makes this more of a concern than in the past is the new HTML referrer tag:

​https://blog.mozilla.org/security/2015/01/21/meta-referrer/

[Raúl Cumplido]

Reopen bug so we take a look. I also think that things have changed since the bug was open and due to new implementation of browsers the % of users that may want to not send their HTTP_REFERER header may increase.

[James Bennett]

Per the ticket/triaging documentation, do not re-open a ticket which has been closed "wontfix" by a member of the Django core team:

​https://docs.djangoproject.com/en/1.7/internals/contributing/triaging-tickets/#closing-tickets

[Raúl Cumplido]

As per policy! Close ticket :)

[Aymeric Augustin]

Perhaps we should document that Django's CSRF protection is incompatible with <meta name="referrer" content="none"> and requires at least the origin for same-site requests (in which case there are no privacy concerns).

[Tim Graham <timograham@…>]

In 0af14b2:

Refs #16870 -- Doc'd that CSRF protection requires the Referer header.