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

Защита от 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.

Это может быть НАМНОГО проще в реализации, чем шаблон «Синхронизирующий токен», так как вам не нужно устанавливать токен для каждого вызова каждой формы, и проверка также относительно проста (просто проверьте, совпадает ли cookie с заголовком), а не отслеживает Срок действия токенов CSRF. Все, что вам нужно, это установить cookie на случайное значение для каждой сессии.

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

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