Разница между CSFR и X-CSRF-токеном
В чем разница между использованием X-CSRF-Token в заголовке или токена в скрытом поле?
Когда использовать скрытое поле и когда использовать заголовок и почему?
Я думаю, что X-CSRF-Token - это когда я использую javascript/ajax, но я не уверен
1 answers
Защита CSRF осуществляется несколькими способами.
Традиционный способ (шаблон "токен синхронизатора") обычно включает установку уникального допустимого значения токена для каждого запроса, а затем проверку этого уникального значения при последующей отправке запроса. Обычно это делается путем установки скрытого поля формы. Значение токена обычно недолговечно и связано с этим сеансом, поэтому, если хакер попытается повторно использовать значение, которое он видел ранее на странице, или попытается угадать значение, которое он скорее всего, потерпит неудачу. Таким образом, будут работать только запросы из вашего приложения, а поддельные запросы из-за пределов вашего приложения/домена (также известные как подделка межсайтовых запросов) завершатся неудачей.
Недостатком этого является то, что ваше приложение должно установить этот скрытый маркер во всех HTML-формах. Эти страницы теперь должны динамически создаваться приложением, хотя, возможно, ранее они были статическим HTML. Теперь вам также необходимо отслеживать действительные токены на стороне сервера и проверять, чтобы все запросы использовали действительный знак. Это может потребовать немало дополнительных усилий для реализации и поддержания в дальнейшем.
Альтернативный подход заключается в том, чтобы установить файл cookie один раз за сеанс, и чтобы JavaScript прочитал этот файл cookie и установил пользовательский заголовок HTTP (часто называемый X-CSRF-ТОКЕНОМ) с этим значением. Любые запросы будут отправлять как заголовок (установленный Javascript), так и файл cookie (установленный браузером в качестве стандартного заголовка HTTP), а затем сервер может проверить, что значение в заголовке X-CSRF-ТОКЕНА совпадает со значением в файле cookie заголовок. Идея заключается в том, что только JavaScript, запущенный в том же домене, будет иметь доступ к файлу cookie, поэтому JavaScript из другого домена не сможет установить для этого заголовка правильное значение (при условии, что страница не уязвима для XSS, которые предоставляют доступ к этому файлу cookie). Даже поддельные ссылки (например, в фишинговом электронном письме) также не будут работать, так как, хотя они, по-видимому, исходят из правильного домена, будет установлен только файл cookie, но не заголовок X-CSRF-ТОКЕНА.
Это может быть НАМНОГО проще реализовать чем шаблон "токен синхронизатора", так как вам не нужно устанавливать токен для каждого вызова каждой формы, и проверка также относительно проста (просто проверьте, соответствует ли файл cookie заголовку), а не отслеживает действительность токенов CSRF. Все, что вам нужно, это установить для файла cookie случайное значение для каждого сеанса.
Недостатком является то, что для работы требуется JavaScript (но это может не быть проблемой, если ваше приложение в принципе не работает без JavaScript в любом случае), а также оно будет работать только для запросов JavaScript делает (например, запросы XHR) - обычные запросы HTML-форм не задают заголовок. Кроме того, шаблон токена синхронизатора может разрешить дополнительные элементы управления для обеспечения потока (например, токен CSRF скрытого поля будет установлен только тогда, когда приложение решит, что вы отправили действительный запрос для получения этой формы).
О, и некоторые проверки безопасности выявят тот факт, что файл cookie не установлен с флагом ТОЛЬКО HTTP, поэтому его можно прочитать с помощью JavaScript, но это сделано намеренно, так как он должен уметь читать этим! Ложная тревога. Вы могли бы подумать, что до тех пор, пока вы используете общее имя, такое как X-CSRF-ТОКЕН, они знали бы, что не следует отмечать это, но часто видели, как это помечается.