Changes between Version 4 and Version 5 of CsrfProtection


Ignore:
Timestamp:
Jun 1, 2009, 5:55:48 PM (15 years ago)
Author:
Luke Plant
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • CsrfProtection

    v4 v5  
    7070=== Django 1.0 - HMAC of session identifier ===
    7171
    72  1. CSRF: '''protected'''
     72 1. CSRF:
     73   * if using Django's session framework as the basis for authorisation: '''protected'''
     74   * otherwise: '''not protected''' (the middleware provides no protection if there isn't an active session)
    7375 2. Login CSRF:
    7476   * if using Django's built-in session framework and login routines, you are '''protected''' (albeit accidentally).  This is because the login views in Django create a session when the login form is first accessed.  When the form is filled in and POSTed back, the view checks for the existence of a test value in the session (to check whether the session cookie has been accepted by the browser).  If not found, you receive the message: "Looks like your browser isn't configured to accept cookies. Please enable cookies, reload this page, and try again".  Hence, login CSRF doesn't work - the session is established in the step before logging in, and is required for login to succeed.
    … …  
    7779   * The CSRF token is tied to the session, so the MITM will not be able to fake the token and abuse the user's session.
    7880   * but related session fixing vulnerabilities are not protected, essentially due to a flaw in cookies (see Barth et al).
    79  4. Cross sub-domain CSRF: '''protected'''
    80  5. Cross sub-domain login CSRF: same as normal login CSRF above
     81 4. Cross sub-domain CSRF: same as normal CSRF (1) above
     82 5. Cross sub-domain login CSRF: same as normal login CSRF (2) above
    8183 6. Cross sub-domain session fixing: '''not protected'''
    8284   * sub-domains will be able to send a wild-card session cookie to clients, giving them the attacker's session.
    … …  
    115117== Proposal ==
    116118
     119(by Luke Plant)
     120
    117121CSRF protection should be done by the following method:
    118122
    119  * Session independent nonce (with backwards compatibility for the Django 1.0 token to avoid upgrade bumps)
     123 * Session independent nonce
     124   * with backwards compatibility for the Django 1.0 token to avoid upgrade bumps
    120125 * Additionally, strict Referer header checking for HTTPS only
    121  * Template tag for inserting the CRSF token (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).
     126 * Template tag for inserting the CRSF token
     127   * 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.
    122128
    123129Compared to Django 1.0:
    … …  
    126132 * the vulnerability caused by automatically including the CSRF token in all POST forms (including external targets) can be avoided much more easily.
    127133 * some cross sub-domain vulnerabilities are opened up - '''regression'''.  This is deemed an acceptable compromise, since there were already cross sub-domain vulnerabilities, and giving sub-domains to untrusted parties seems to be increasingly uncommon as most people buy their own domains.  It also isn't possible to fix cross sub-domain session fixing without changes to browsers, so it is safer simply to say that sub-domains should be only given to trusted parties.
    128  * adding strict Referer checking closes the other vulnerabilities opened up in the case of HTTPS connections.
     134 * for HTTPS connections, adding strict Referer checking closes the other vulnerabilities opened up by the change from 'HMAC of session identifier' to 'session independent nonce' (i.e.  CSRF + MITM under HTTPS)
    129135
Back to Top