понимание CSRF в скрытом поле Django в форме и CSRFCookie - PullRequest
6 голосов
/ 30 марта 2012

Я записываю свое понимание механизма csrf protcetion в django. Пожалуйста, исправьте меня, если он неисправен.

csrfViewMiddleware создает уникальную строку и сохраняет ее в скрытом поле «csrfmiddlewaretoken» формы, исходящей с хоста. Поскольку вредоносный веб-сайт, имитирующий эту форму, не будет знать о значении этого поля, он не сможет использовать ее .

Когда кто-то пытается опубликовать форму, веб-сайт проверяет поле 'csrfmiddlewaretoken' и его значение. Если оно неверно или не задано, то обнаруживается попытка csrf.

Но тогда, что именно является CSRFCookie? В документе сказано, что уникальное значение установлено в CSRFCookie, а также в hidden field. Это то, где я запутался. Отправляется ли cookie в браузер со встроенной уникальной строкой? Я хочу кого-нибудь могу объяснить это немного ясно.

спасибо,

Ответы [ 2 ]

5 голосов
/ 30 марта 2012

Хорошо, вот мое объяснение:

Django назначает аутентифицированному пользователю токен CSRF, который хранится в cookie.Значение в этом файле cookie читается каждый раз, когда пользователь делает запрос, который считается «небезопасным» (а именно POST, PUT, DELETE), для проверки того, что пользователь, а не злонамеренная третья сторона, выполняет запрос.

Тег CSRF, который вы помещаете в форму, на самом деле извлекает токен CSRF из файла cookie, а затем передает его как переменную POST при отправке формы.

Надеюсь, это немного прояснит ситуацию.

1 голос
/ 23 мая 2014

С моим нынешним пониманием я не совсем удовлетворен подтвержденным ответом.

Вы можете найти мою версию здесь .

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

Злоумышленник не может получить токен из cookie-файла и поэтому не может подделать вредоносный код, содержащий этот токен.

В конечном итоге важно то, что пользователь может отправить токен csrf, а сервер может его проверить. Использование файла cookie является удобным способом сделать это, но это может быть реализовано по-другому (например, сервер может сохранять токены CSRF для каждого сеанса, например).

Я не специалист, но я так понимаю. Надеюсь, это поможет.

...