CSRF: Можно ли использовать файл cookie?

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

И если он защищен, он менее защищен, чем помещает токен в URL?

Есть ли другой метод?

Где я могу узнать больше по этому вопросу?

UPDATE. Пока никто не может сказать мне, как метод cookie небезопасен, если ему все еще нужно сопоставить токен из формы, которую злоумышленник не сможет получить, если только он использует другой взлом, такой как XSS, который является другим делом и по-прежнему не влияет на использование маркера cookie и url.

ОБНОВЛЕНИЕ 2. Хорошо, похоже, что некоторые известные фреймворки используют этот метод, поэтому все должно быть хорошо. Благодаря

Ответ 1

Использование файлов cookie работает, и это обычная практика (например, Django использует ее). Злоумышленник не может прочитать или изменить значение файла cookie из-за политики одного и того же происхождения и, следовательно, не может угадать правильный параметр GET/POST.

Ответ 2

Просмотрите Зашифрованный шаблон токена, который позволяет безстоящую защиту CSRF без необходимости хранить токены на сервере.

Ответ 3

"CSRF работает, потому что многие сайты используют запросы GET для выполнения команд". Поэтому многие сайты не используют метод GET, как ожидалось, потому что этот запрос должен быть идемпотентным: см. rfc2616.

"Параметр CSRF уже присутствует в файле cookie, и он отправляется вместе с сеансом.", так как?

В cookie используется только хранилище токенов, как DOM, когда мы устанавливаем токен в скрытом поле ввода. Часть javascript должна получить значение маркера из этого файла cookie и установить его как параметр в URL-адресе, в теле запроса или в заголовке запроса. Это будет проверка на сервере со значением, хранящимся в сеансе. Это способ Django для обработки токена CSRF.

Javascript не может получить доступ к файлу cookie из другого домена из-за защиты браузера кросс-домена, поэтому я не знаю, как злоумышленник может заставить кого-то отправить правильный токен по поддельному запросу. С XSS да, но XSS поражает общие контрмеры CSRF.

Я предпочитаю давать это разъяснение, потому что я думаю, что это важный вопрос и не так просто обрабатывать.

Запрос GET должен использоваться для получения ресурса и/или отображения его данных, не должен использоваться для изменения его состояния (удаление, добавление свойства или любые изменения).

Проверка CSRF должна выполняться на стороне сервера, это кажется очевидным, но я упомянул это как напоминание. Этот метод не может быть вектором атаки, если вы соблюдаете эти рекомендации.

Ответ 4

Если вы решили поместить CSRF-токен в файл cookie, то не забудьте отметить этот файл cookie как HttpOnly. Если ваш сайт имеет уязвимость межсайтового скриптинга, хакер не сможет прочитать токен CSRF. Вы можете проверить файлы cookie, которые могут быть прочитаны с помощью JavaScript, с помощью команды console.log(document.cookie) в любой современной консоли браузера. Если у вас есть файлы cookie сеанса или другие чувствительные файлы cookie, они также должны быть помечены как HttpOnly.

Дальнейшее чтение:

https://www.owasp.org/index.php/HttpOnly

Ответ 5

Использование файла cookie поражает цель CSRF. Вот почему:

CSRF работает, потому что многие сайты используют запросы GET для выполнения команд. Поэтому скажите, что у Боба есть какая-то административная учетная запись в Интернете, и он вошел в нее. Некоторый запрос можно сделать следующим образом:

http://somesite.com/admin/whatever.php?request=delete_record&id=4

Итак, теперь Боб связывается с сайтом атаки (кто-то пытается испортить его данные). Затем злоумышленник загружает вышеуказанный URL-адрес в изображение, возможно, с другим идентификатором и удаляет некоторую другую запись. Браузер загружает его, потому что Боб уже зарегистрирован на своем сайте администратора, поэтому у него есть действующий сеанс.

CSRF пытается устранить это, добавив в транзакцию безопасный параметр. Этот параметр должен вращаться при каждом запросе, а затем быть брошен браузером. Создание URL-адреса выглядит примерно так:

http://somesite.com/admin/whatever.php?request=delete_record&id=4&csrf=<some long checksum>

Идея заключается в том, что теперь атакующий должен угадать "некоторую длинную контрольную сумму" для создания атаки. И если эта контрольная сумма вращается по каждому запросу, это должно быть практически невозможно.

НО, если вы сохраните эту контрольную сумму в файле cookie, вы вернетесь на квадрат 1. Злоумышленнику больше не нужно его угадывать. Он просто создает исходный URL-адрес. Параметр CSRF уже присутствует в файле cookie и отправляется вместе с сеансом. Это не останавливает небезопасное поведение.