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

Ответ 1

Защита от CSRF возможна несколькими способами.

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

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

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

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

Недостатком является то, что для работы требуется JavaScript (но это может и не быть проблемой, если ваше приложение в любом случае не работает без JavaScript), а также оно будет работать только для запросов, которые выполняет JavaScript (например, запросов XHR) - обычных запросов HTML-форм не будет устанавливать заголовок. Вариант этого (шаблон "Double Submit Cookie") помещает значение X-CSRF-TOKEN в скрытое поле формы, а не в заголовок HTTP, чтобы обойти это, но при этом сохраняет логику на стороне сервера проще, чем традиционный шаблон токенов Synchronizer., Однако следует отметить, что OWASP заявляет о некоторых недостатках метода Double Submit, когда злоумышленник может установить cookie (что часто проще, чем чтение cookie), поэтому рекомендует в этом случае проверить токен CSRF.

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

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

Ответ 2

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

csrf:

• Используется в HTML-формах (не ajax)
• мы не можем установить заголовок запроса в HTML-формах, поэтому мы должны отправить его через ввод формы в виде скрытого поля.

х-CSRF-маркер:

• Добавляется в заголовок запроса для запросов ajax.
• При использовании laravel в качестве бэкэнда. laravel автоматически проверяет этот заголовок и сравнивает его с действительным csrf в базе данных.

х-XSRF-маркер:

• Добавляется в заголовок запроса для запросов ajax.
• Популярные библиотеки, такие как angular и axios, автоматически получают значение этого заголовка из cookie xsrf-token и отправляют его при каждом запросе.
• Поскольку laravel пользуется популярностью, он создает этот файл cookie в каждом ответе.
• поэтому, когда вы используете, например, axios и laravel, вам не нужно ничего делать. Пользователь просто должен войти в систему, а затем с помощью промежуточного программного обеспечения 'auth' все сделает.
• Это большая строка по сравнению с x-csrf-token, потому что куки шифруются в laravel.