Django: csrftoken COOKIE vs. csrfmiddlewaretoken Значение формы HTML

Попытка узнать о безопасности. Любопытно, почему в джанго, когда представляя форму (POST), есть два отдельных "элемента", которые содержат одно и то же значение токена csrf:

- the csrftoken cookie:
     COOKIES:{'csrftoken': '1effe96056e91a8f58461ad56c0d4ddc', ...

- the Form hidden csrfmiddlewaretoken:
     POST:<QueryDict: {u'csrfmiddlewaretoken': 
                       [u'1effe96056e91a8f58461ad56c0d4ddc'], ...

Если django вставляет скрытое поле csrf/значение в формы, когда он отправляет его в браузер (GET), и ожидает, что то же значение возвращается при получении POST, то почему это необходимо также установить cookie?

Более общий вопрос, если какой-либо из них отсутствует (форма, cookie), вы могли бы представить сценарий, объясняющий, как это можно использовать? (атака безопасности)?

Кстати, я провел несколько простых тестов, чтобы убедиться, что django проверял действительность каждого отдельно и действительно это:

если я изменил значение формы csrf перед выполнением POST, Я возвращаю эту ошибку отладки:

Недопустимый токен CSRF или неверный
если я удалю cookie csrf перед выполнением POST, Я получаю другую ошибку:

cookie CSRF не установлен.

Я просто знаком с основными концепциями csrf и хочу узнайте, как django помогает защитить от этих типов атак.

Спасибо,

update:

Хотя оба ответа (S.Lott и M. DeSimone) были информативными и Имеют смысл, я думал, что может быть более подробное объяснение для требования наличия значения безопасности как в форме, так и в в печенье. Во время поиска вне stackoverflow.com я столкнулся сообщение в блоге из... Джеффа Этвуда.

Я включил третий ответ (извините, что ответил на мой собственный вопрос, но Я думаю, что это релевантная дополнительная информация), которая относится к блогу сообщение от Джеффа и включает цитату.

Ответ 1

Из записи блога Джеффа Атвуда:

Предотвращение нападений CSRF и XSRF (14 октября 2008 г.)

Оригинальное сообщение

В документе Фельтена и Целлера (pdf) рекомендуется "двойное представление" cookie "для предотвращения XSRF:

Когда пользователь посещает сайт, сайт должен генерировать (криптографически сильное) псевдослучайное значение и установить его как cookie на машине пользователя. Сайт должен содержать все формы чтобы включить это псевдослучайное значение в качестве значения формы и также как значение cookie. Когда POST-запрос отправляется на сайт, запрос должен считаться действительным только в том случае, если значение формы и значение cookie одинаково. Когда злоумышленник представляет форму на от имени пользователя, он может изменять только значения формы. злоумышленник не может читать данные, отправленные с сервера или изменять файлы cookie значения в соответствии с политикой одного и того же происхождения. Это означает, что атакующий может отправить любое значение, которое он хочет с помощью формы, он будет неспособный изменить или прочитать значение, хранящееся в файле cookie. Поскольку значение cookie и значение формы должны быть одинаковыми, атакующий будет не сможет успешно отправить форму, если он не в состоянии угадать псевдослучайное значение.

Преимущество такого подхода заключается в том, что он не требует состояния сервера; вы просто устанавливаете значение cookie один раз, затем каждый HTTP POST проверяет убедитесь, что одно из представленных значений содержит то же значение cookie. Любая разница между ними означает Атака XSRF.

Ответ 2

Они выявляют две разные проблемы.

Cookie - это аутентификация клиентской машины, создающей соединение.

Поле скрытой формы - это аутентификация источника формы.

Пример сценария: пользователь A на клиентской машине может занести в закладки эту форму. Пользователь B регистрируется, получает действительный файл cookie с сегодняшнего дня. Пользователь A может отправить недопустимое поле формы со вчерашнего дня, когда браузер имеет куки файл с открытым кодом из сеанса пользователя B.

какие ресурсы клиента/браузера обычно скомпрометированы,

Отсутствует.

и как получается, что эти поля csrf помогают защитить нас от запросов подделки?

Тоны CSRF устанавливают идентичность.

Один (и только один) браузер имеет токен CSRF cookie. Но этот браузер может иметь несколько копий открытых или закладок на сайте.

Одна (и только одна) форма страницы в этом браузере имеет маркер формы CSRF.

Файлы cookie браузера и формы должны совпадать, чтобы обеспечить один браузер/одну форму.

Ответ 3

Файл cookie существует для поддержки AJAX. Цитирование Django docs:

В то время как вышеупомянутый метод может использоваться для запросов AJAX POST, у него есть некоторые неудобства: вы должны помнить о передаче токена CSRF в качестве данных POST с каждым запросом POST. По этой причине существует альтернативный метод: на каждом XMLHttpRequest установите собственный заголовок X-CSRFToken на значение токена CSRF. Это часто бывает проще, потому что многие фреймворки javascript предоставляют перехваты, которые позволяют устанавливать заголовки для каждого запроса. В jQuery вы можете использовать событие ajaxSend следующим образом:

$('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'));
    }
});

Добавление этого файла в javascript, который включен на ваш сайт, гарантирует, что запросы AJAX POST, созданные через jQuery, не будут защищены системой CSRF.