Changes between Version 10 and Version 11 of CsrfProtection


Ignore:
Timestamp:
Aug 28, 2009, 2:39:50 PM (15 years ago)
Author:
Luke Plant
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • CsrfProtection

    v10 v11  
    44
    55This page aims to document and discuss CSRF protection for Django.
     6
     7== Summary ==
     8
     9For Django 1.2, I (Luke Plant) propose:
     10
     11 * We should move to using a session independent nonce as a CSRF token, instead of a hash of the session identifier as used in Django 1.1 and earlier.  This eliminates the false positives associated with session cycling, and removes the dependency on the session framework, making the middleware more generally useful, and also fixing login CSRF vulnerabilities (which were only partially and accidentally addressed before).
     12 * Since the above introduces a subtle regression involving attacks on HTTPS connections, this should be fixed by adding strict referer checking for HTTPS connections.
     13 * The post-processing middleware (CsrfResponseMiddleware) should be deprecated and replaced with a template tag to insert the CSRF token.  This allows for streaming responses and fixes a potential vulnerability that existed with the post-processing middleware.  All contrib apps should be updated to use this, which makes the CSRF app a dependency of these apps.
     14
     15These changes require some immediate changes to settings.py for people upgrading if they want the admin and other contrib apps to continue to work, and, longer term, apps must be updated to switch away from the deprecated features and use the new template tag method, but otherwise the upgrade path should be fairly easy (and it is fully documented).
    616
    717== Background ==
    … …  
    3444 1. 'CSRF': normal CSRF attacks, where an attacking site hosts a form, link, or piece of javascript that causes the user's browser to make a request on a (Django) site.  Normally this involves abuse of the user agent's authentication (e.g. a session/login cookie) to cause an action that the attacking site would not otherwise have permission to do.
    3545 2. 'Login CSRF': this is when a browser is tricked into logging into a site under an account that is controlled by an attacker, so that the attacker can then track or otherwise abuse the actions performed by the victim.
    36  3. 'CSRF + MITM': this is a combination of  CSRF and active network (man-in-the-middle) attack, which is relevant in HTTPS situations which are otherwise thought to be invulnerable to MITM attacks.  This is because HTTP 'Set-Cookie' headers are accepted by clients that are talking to a site under HTTPS, allowing a MITM attacker to set cookies on the client. (MITM attacks under HTTP are considered out of scope, because in general MITM attacks under HTTP are impossible to protect against).
     46 3. 'CSRF + MITM': this is a combination of CSRF and active network (man-in-the-middle) attack, which is relevant in HTTPS situations which are otherwise thought to be invulnerable to MITM attacks.  This is because HTTP 'Set-Cookie' headers are accepted by clients that are talking to a site under HTTPS, allowing a MITM attacker to set cookies on the client. (MITM attacks under HTTP are considered out of scope, because in general MITM attacks under HTTP are impossible to protect against).
    3747
    3848Further, attacks can be categorised as:
    … …  
    128138 * Template tag for inserting the CRSF token
    129139   * with a backwards compatible !CsrfResponseMiddleware which can be used at the same time as the template tag, to allow people to upgrade without upgrading all their apps.
     140 * The middleware should be enabled by default.
    130141
    131142Compared to Django 1.1:
    … …  
    137148 * there are required upgrade steps for contrib apps (including the admin) to continue working.  Given the fact that without CSRF protection enabled by default ticket #510 is a security bug that should not be considered closed, and the fact that the CSRF protection provided in Django 1.1 is considered inadequate (due to its performance and security problems), I think this is acceptable.
    138149
    139 This proposal is implemented in the lp-csrf_rework branch in http://bitbucket.org/spookylukey/django-trunk-lukeplant/ (with patches regularly copied to #9977)
     150This proposal is implemented in the lp-csrf_rework branch in http://bitbucket.org/spookylukey/django-trunk-lukeplant/ (with patches regularly copied to #9977).  It includes fixes to all the contrib apps. The only things not updated yet are the tutorials.  Fixing them unfortunately isn't trivial, and since we are turning on the CSRF middleware by default, the tutorials must beo be updated somehow.
    140151
    141152The docs for this branch, which contain upgrade information, are here: http://bitbucket.org/spookylukey/django-trunk-lukeplant/src/tip/docs/ref/contrib/csrf.txt
Back to Top