Code

Changes between Version 7 and Version 8 of CsrfProtection


Ignore:
Timestamp:
07/30/09 05:53:48 (5 years ago)
Author:
lukeplant
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • CsrfProtection

    v7 v8  
    3939 2. Cross sub-domain - attacker.example.com attacking victim.example.com 
    4040 
    41 There is also an attack related to 'CSRF + MITM' which is not necessarily 'CSRF', which will be called 'session fixing': the opposite of session theft, a malicious agent sets the session cookie on a user's machine, giving them the attacker's session.  The attacker may or may not be 'authenticated' in that session - if not, the victim might log in, and the attacker may be able to take control of the victim's account or abuse the victim's authentication.  Alternatively, if the attacker is already authenticated, there are the same problems as those present in 'login CSRF'.  This type of attack can be achieved by an active network attacker (not in scope for HTTP connections), but it can also be achieved by someone with control of a sub-domain through the use of the wild-card cookies.   
     41There is also an attack related to 'CSRF + MITM' which is not necessarily 'CSRF', which is called 'session fixation': the opposite of session theft, a malicious agent sets the session cookie on a user's machine, giving them the attacker's session.  The attacker may or may not be 'authenticated' in that session - if not, the victim might authenticate, and the attacker may be able to take control of the victim's account or abuse the victim's authentication.  Alternatively, if the attacker is already authenticated, there are the same problems as those present in 'login CSRF'.  This type of attack can be achieved by an active network attacker (not in scope for HTTP connections), but it can also be achieved by someone with control of a sub-domain through the use of the wild-card cookies.   
    4242 
    4343(Question: if the sub-domain is unable to send cookies, is this attack foiled - or do you need to stop javascript as well?  The answer depends on browser policies about cookie setting, what happens when a page does {{{document.domain = 'example.com';}}} ?) 
     
    5555== Methods of token insertion == 
    5656 
    57  * Django 1.0 provided !CsrfResponseMiddleware which did automatic insertion of the token in outgoing pages, to all POST forms.  This has several problems: 
     57 * Django 1.0 and 1.1 provided !CsrfResponseMiddleware which did automatic insertion of the token in outgoing pages, to all POST forms.  This has several problems: 
    5858   * The performance hit from doing the post processing. 
    5959   * It removes the ability to do streaming of responses (should that become a possibility in future Django versions) 
     
    127127   * 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. 
    128128 
    129 Compared to Django 1.0: 
     129Compared to Django 1.1: 
    130130 * there is no dependence on the session framework, expanding the usefulness of this protection 
    131131 * the false positives caused by session cycling are eliminated 
    132  * the vulnerability caused by automatically including the CSRF token in all POST forms (including external targets) can be avoided much more easily. 
    133  * 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. 
    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)  
     132 * the vulnerability caused by automatically including the CSRF token in all POST forms (including external targets) can be avoided much more easily, and you are much more secure by default. 
     133 * 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 only be given to trusted parties. 
     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) 
     135 * 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. 
    135136 
     137This proposal is implemented in the lp-csrf_rework branch in http://bitbucket.org/spookylukey/django-trunk-lukeplant/ (with patches regularly copied to #9977) 
     138 
     139The docs for this branch, which contain upgrade information, are here: http://bitbucket.org/spookylukey/django-trunk-lukeplant/src/tip/docs/ref/contrib/csrf.txt 
    136140 
    137141= Further work = 
     
    139143 * Could examine use of Origin header for CSRF protection, in addition to this.   
    140144   * It's usefulness will really depend on whether browsers implement it, and how quickly - we won't be able to rely on it for a long time. 
    141    * Note that if we simply compare Origin and Host, we are still vulnerable to DNS rebinding attacks.  It would be better to use a setting that listed allowable values of Host.  (Or provide that as another middleware? If a request has the wrong Host value, should it automatically be assumed to be CSRF or suspicious?) 
     145   * Note that if we simply compare Origin and Host, we are still vulnerable to DNS rebinding attacks.  
     146 * General protection against DNS rebinding attacks.  This would require a setting that listed allowable values of Host.  This could be a separate middleware.