Opened 13 years ago

Closed 10 years ago

Last modified 7 years ago

#16870 closed Bug (wontfix)

CSRF too strict when no referer is present

Reported by: rtux Owned by: nobody
Component: CSRF Version: dev
Severity: Normal Keywords:
Cc: fritsch+djangoproject.com@…, jon.dufresne@… Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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

Change History (11)

comment:1 by rtux, 13 years ago

Cc: fritsch+djangoproject.com@… added

comment:2 by Paul McMillan, 13 years ago

Resolution: wontfix
Status: newclosed

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.

comment:3 by rtux, 13 years ago

Thank you for the detailed explanation!

comment:4 by Luke Plant, 13 years ago

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).

comment:5 by ilf, 12 years ago

Version: 1.31.5

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

comment:6 by Jon Dufresne, 10 years ago

Cc: jon.dufresne@… added
Version: 1.5master

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/

comment:7 by Raúl Cumplido, 10 years ago

Resolution: wontfix
Status: closednew

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.

comment:8 by James Bennett, 10 years ago

Resolution: wontfix
Status: newclosed

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

Version 0, edited 10 years ago by James Bennett (next)

comment:9 by Raúl Cumplido, 10 years ago

As per policy! Close ticket :)

comment:10 by Aymeric Augustin, 10 years ago

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).

comment:11 by Tim Graham <timograham@…>, 7 years ago

In 0af14b2:

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

Note: See TracTickets for help on using tickets.
Back to Top