[Django]-Django: csrftoken COOKIE vs. csrfmiddlewaretoken HTML Form value

by

22đź‘Ť

âś…

From Jeff Atwood’s blog entry:

Preventing CSRF and XSRF Attacks
(Oct 14, 2008)

The original post

The Felten and Zeller paper (pdf) recommends the “double-submitted
cookie” method to prevent XSRF:

When a user visits a site, the site should generate a
(cryptographically strong) pseudorandom value and set it as a
cookie on the user’s machine. The site should require every form
submission to include this pseudorandom value as a form value and
also as a cookie value. When a POST request is sent to the site,
the request should only be considered valid if the form value and
the cookie value are the same. When an attacker submits a form on
behalf of a user, he can only modify the values of the form. An
attacker cannot read any data sent from the server or modify cookie
values, per the same-origin policy. This means that while an
attacker can send any value he wants with the form, he will be
unable to modify or read the value stored in the cookie. Since the
cookie value and the form value must be the same, the attacker will
be unable to successfully submit a form unless he is able to guess
the pseudorandom value.

The advantage of this approach is that it requires no server state;
you simply set the cookie value once, then every HTTP POST checks to
ensure that one of the submitted values contains the exact
same cookie value. Any difference between the two means a possible
XSRF attack.

👤jd.

8đź‘Ť

The cookie is there for AJAX support. Quoting the Django docs:

While the above method can be used for AJAX POST requests, it has some inconveniences: you have to remember to pass the CSRF token in as POST data with every POST request. For this reason, there is an alternative method: on each XMLHttpRequest, set a custom X-CSRFToken header to the value of the CSRF token. This is often easier, because many javascript frameworks provide hooks that allow headers to be set on every request. In jQuery, you can use the ajaxSend event as follows:

$('html').ajaxSend(function(event, xhr, settings) {
    function getCookie(name) {
        var cookieValue = null;
        if (document.cookie && document.cookie != '') {
            var cookies = document.cookie.split(';');
            for (var i = 0; i < cookies.length; i++) {
                var cookie = jQuery.trim(cookies[i]);
                // Does this cookie string begin with the name we want?
                if (cookie.substring(0, name.length + 1) == (name + '=')) {
                    cookieValue = decodeURIComponent(cookie.substring(name.length + 1));
                    break;
                }
            }
        }
        return cookieValue;
    }
    if (!(/^http:.*/.test(settings.url) || /^https:.*/.test(settings.url))) {
        // Only send the token to relative URLs i.e. locally.
        xhr.setRequestHeader("X-CSRFToken", getCookie('csrftoken'));
    }
});

Adding this to a javascript file that is included on your site will ensure that AJAX POST requests that are made via jQuery will not be caught by the CSRF protection.

👤Mike DeSimone

6đź‘Ť

They spot two different problems.

Cookie is to authenticate the client machine making the connection.

The hidden form field is to authenticate the source of the form.

Example Scenario: User A, on the client machine could bookmark the form. User B logs on, gets a valid cookie from today. User A could submit the invalid form field from yesterday when the browser has a left-over cookie from user B’s session.

what client/browser resources are typically compromised,

None.

and how is it that these csrf fields help protect us from the forgery requests?

The CSRF tokens establish identity.

One (and only one) browser has a CSRF cookie token. But that browser could have multiple copies of a site open or bookmarked forms.

One (and only one) page form on that browser has a CSRF form token.

The browser and form cookies must match to assure one browser/one form.

👤S.Lott

Leave a comment