CSRF: я могу использовать куки?

Question

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

И если он безопасен, является ли он менее безопасным, чем вставка токена в URL-адреса?

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

Гдемогу ли я прочитать больше по теме?

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

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

Answer 1

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

Answer 2

Ознакомьтесь с шаблоном Encrypted Token , который обеспечивает защиту CSRF без сохранения состояния без необходимости хранить токены на сервере.

Answer 3

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

Дополнительная информация:

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

Answer 4

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

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

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

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

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

---

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

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

Answer 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 и отправляется вместе с сеансом.Это не останавливает небезопасное поведение.