Я пытаюсь понять всю проблему с CSRF и соответствующие способы предотвратить это. (Ресурсы, которые я прочитал, понимаю и согласен с:Шпаргалка OWASP CSRF Prevention, Вопросы о CSRF.)

Насколько я понимаю, уязвимость вокруг CSRF вводится в предположении, что (с точки зрения веб-сервера) действительный файл cookie сеанса во входящем HTTP-запросе отражает пожелания аутентифицированного пользователя. Но все файлы cookie для домена происхождения магически связаны с запросом браузера, поэтому на самом деле все, что сервер может сделать вывод из наличия действительного файла cookie сеанса в запросе, состоит в том, что запрос поступает от браузера, который имеет аутентифицированный сеанс; он не может далее предполагать что-либо окод работает в этом браузере, или действительно ли он отражает пожелания пользователя. Способ предотвратить это состоит в том, чтобы включить в запрос дополнительную информацию для аутентификации («токен CSRF»), передаваемую с помощью других средств, помимо автоматической обработки файлов cookie браузером. Проще говоря, cookie сеанса аутентифицирует пользователя / браузер, а токен CSRF аутентифицирует код, выполняемый в браузере.

Таким образом, в двух словах: если вы используете cookie-файл сеанса для аутентификации пользователей вашего веб-приложения, вы также должны добавить токен CSRF к каждому ответу и требовать соответствующий токен CSRF в каждом (мутирующем) запросе. Затем токен CSRF отправляется обратно от сервера к браузеру обратно на сервер, доказывая серверу, что страница, выполняющая запрос, одобрена (сгенерирована даже этим сервером).

На мой вопрос, который касается конкретного метода транспорта, используемого для этого токена CSRF в этом двустороннем сообщении.

Это кажется распространенным (например, вAngularJS, Джанго, Рельсы) для отправки токена CSRF с сервера на клиент в виде файла cookie (т. е. в заголовке Set-Cookie), а затем с помощью Javascript на клиенте очистить его от файла cookie и прикрепить в виде отдельного заголовка XSRF-TOKEN для отправки обратно сервер.

(Альтернативным методом является метод, рекомендованный, например,экспрессгде токен CSRF, сгенерированный сервером, включен в тело ответа посредством расширения шаблона на стороне сервера, прикрепленного непосредственно к коду / разметке, который будет передавать его обратно на сервер, например, в качестве скрытой формы ввода. Этот пример представляет собой более привычный способ работы с веб-версией 1.0, но в целом подходит для более насыщенного JS-клиента.)

Почему так часто используют Set-Cookie в качестве нисходящего транспорта для токена CSRF / почему это хорошая идея? Я полагаю, что авторы всех этих фреймворков тщательно продумали свои варианты и не ошиблись. Но на первый взгляд использование cookie-файлов для обхода того, что по сути является ограничением дизайна cookie-файлов, кажется глупым. Фактически, если вы использовали файлы cookie в качестве транспорта туда-обратно (Set-Cookie: заголовок ниже по потоку для сервера, чтобы сообщить браузеру токен CSRF, и заголовок Cookie: вверх по потоку для браузера, чтобы браузер возвратил его на сервер), вы бы снова представили уязвимость, которую вы пытаемся исправить.

Я понимаю, что вышеупомянутые фреймворки не используют куки-файлы для всего обхода для токена CSRF; они используют Set-Cookie в нисходящем направлении, затем что-то еще (например, заголовок X-CSRF-Token) в восходящем направлении, и это закрывает уязвимость. Но даже использование Set-Cookie в качестве нижестоящего транспорта потенциально вводит в заблуждение и опасно; теперь браузер будет прикреплять токен CSRF к каждому запросу, включая подлинные вредоносные запросы XSRF; в лучшем случае это делает запрос больше, чем нужно, а в худшем случае какой-то благонамеренный, но ошибочный кусок серверного кода может попытаться его использовать, что было бы очень плохо. И далее, поскольку фактическим предполагаемым получателем токена CSRF является клиентский Javascript, это означает, что этот файл cookie не может быть защищен только с помощью http. Поэтому отправка токена CSRF в нисходящем направлении в заголовке Set-Cookie представляется мне неоптимальной.