Changes between Version 15 and Version 16 of CsrfProtection


Ignore:
Timestamp:
Sep 6, 2010, 1:23:29 PM (14 years ago)
Author:
Luke Plant
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • CsrfProtection

    v15 v16  
    104104   * 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.
    105105   * other login methods are '''not protected'''.
    106  3. CSRF + MITM, under HTTPS: '''protected'''
    107    * 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.
    108    * but related session fixing vulnerabilities are not protected, essentially due to a flaw in cookies (see Barth et al).
     106 3. CSRF + MITM, under HTTPS: '''possibly protected'''
     107   * The CSRF token is tied to the session.  If the session ID has been revealed over HTTP (SESSION_COOKIE_SECURE = False, the default), then the MITM will be able to retrieve the CSRF token corresponding to it fairly easily.  Otherwise, he will not be able to do so, and so will not be able to abuse the user's session. (However, if the session ID has been revealed over HTTP, more direct session theft attacks are probably going to be more of an issue).
     108   * If the site is not using Django's session framework, there is no protection against this attack.
     109   * Related session fixing vulnerabilities are not protected, essentially due to a flaw in cookies (see Barth et al).
    109110 4. Cross sub-domain CSRF: same as normal CSRF (1) above
    110111 5. Cross sub-domain login CSRF: same as normal login CSRF (2) above
Back to Top