Changes between Version 2 and Version 3 of CsrfProtection


Ignore:
Timestamp:
May 12, 2009, 7:04:11 AM (15 years ago)
Author:
Luke Plant
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • CsrfProtection

    v2 v3  
    109109 4. Cross sub-domain CSRF: '''protected'''
    110110 5. Cross sub-domain login CSRF: '''protected'''
    111  6. Cross sub-domain session fixing: '''protected'''
     111 6. Cross sub-domain session fixing: '''not protected'' (out of scope)
    112112
    113113The big problem with strict Referer checking is that the Referer header is suppressed by some browsers and by some networks.  However, Barth et al have shown that for same-domain HTTPS requests, this is as little as 0.05% - 0.22%, and recommend that this method can be used for HTTPS connections.  Since HTTPS connections cannot be tampered with (apart from in some rare internal-network-with-proxy situations), suppression of the Referer header can only be done by the browser, so if a user is having problems due to use of this method, they can simply be instructed to configure their browser differently or use a different browser.
    … …  
    125125 * the false positives caused by session cycling are eliminated
    126126 * the vulnerability caused by automatically including the CSRF token in all POST forms (including external targets) can be avoided much more easily.
    127  * 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. 
     127 * 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.
    128128 * adding strict Referer checking closes the other vulnerabilities opened up in the case of HTTPS connections.
    129129
Back to Top