Разница между CSFR и X-CSRF-токеном

Question

В чем разница между использованием X-CSRF-Token в заголовке или токене в скрытом поле?

При использовании скрытого поля и при использовании заголовка и почему?

Я думаю, что X-CSRF-Token когда я использую JavaScript/Ajax, но им не уверен, что

Answer 1

защита CSRF приходит в ряде методов.

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

Недостатком этого является то, что приложение требует установить этот скрытый токен во всех HTML-формах. Эти страницы теперь должны динамически генерироваться приложением, если раньше они были статическими HTML. Теперь вам также нужно отслеживать действительные токены на стороне сервера и проверять, что в каких-либо запросах используется действительный токен. Это может принести немало дополнительных усилий для внедрения и поддержки в будущем.

Альтернативный подход состоит в том, чтобы установить Cookie один раз за сеанс, и JavaScript прочитал этот файл cookie и установил собственный HTTP-заголовок (часто называемый X-CSRF-TOKEN) с этим значением. Любые запросы отправят как заголовок (установленный Javascript), так и файл cookie (установленный браузером в качестве стандартного HTTP-заголовка), а затем сервер может проверить, что это значение в заголовке X-CSRF-TOKEN соответствует значению в заголовке файла cookie. Идея состоит в том, что только JavaScript, работающий в том же домене, будет иметь доступ к файлу cookie, поэтому JavaScript из другого домена не смог бы установить этот заголовок в правильное значение (если страница не уязвима для XSS, которая дает доступ к этому файлу cookie) , Даже поддельные ссылки (например, в фишинговом письме) тоже не будут работать, так как даже если они появятся из нужного домена, будет установлен только файл cookie, но не заголовок X-CSRF-TOKEN.

Это может быть намного проще реализовать, чем шаблон «Synchronizer token», поскольку вам не нужно устанавливать токен для каждого вызова в каждую форму, а проверка относительно проста (просто проверьте, соответствует ли файл cookie заголовку), а не отслеживание действительности токенов CSRF. Все, что вам нужно, - установить cookie на случайное значение для каждого сеанса.

Недостатком является то, что для работы JavaScript требуется JavaScript (но это может и не быть проблемой, если ваше приложение в принципе не работает без JavaScript), а также оно будет работать только для запросов, которые делает JavaScript (например, запросы XHR) - регулярные запросы формы HTML не задавали заголовок. Кроме того, шаблон токенов Synchronizer может позволить дополнительным элементам управления для обеспечения потока (например, токен CSRF скрытого поля будет установлен только тогда, когда приложение считает, что вы отправили действительный запрос для получения этой формы).

О, и некоторые проверки безопасности поймут тот факт, что cookie не установлен с флагом HTTP-ONLY, поэтому его можно прочитать на JavaScript, но это преднамеренно, поскольку он должен быть в состоянии прочитать это! Ложное предупреждение. Вы могли бы подумать, что пока вы используете общее имя, такое как X-CSRF-TOKEN, они не знали бы, что это не флаг, но часто видели его.