анти-CSRF токен и Javascript - PullRequest
Новая
       22

анти-CSRF токен и Javascript

28 голосов
/ 08 сентября 2010

Я пытаюсь защитить приложение (php и множество JS) от CSRF.

Я хочу использовать токены.

Многие операции выполняются с AJAX, поэтому я должен передать токен в Javascript. Если я хочу сгенерировать 1 токен за сеанс или загрузку страницы, это просто - я генерирую новый токен, помещаю его где-то в DOM, а затем нахожу его с помощью Javascript и отправляю на сторону обработки.

Но что, если я хочу использовать новый токен для каждой операции? Я думал о том, чтобы выполнить ajax-вызов для регенерации токена, а затем передать результат на страницу обработки.

Увеличивает ли это риск для безопасности? Я думал о том, чтобы заманить пользователя на страницу с помощью скрипта, который будет запрашивать токен, а затем использовать его для выполнения запроса, но опять же междоменный Javascript запрещен. Можно ли это сделать со вспышкой?

Может быть, другой подход для защиты вызовов ajax от CSRF?

Спасибо!

1 Ответ

27 голосов
/ 08 сентября 2010

Существует несколько методов, которые при совместном использовании обеспечивают достаточную защиту CSRF.

Уникальный токен

Один токен, специфичный для сеанса, подходит для большинстваПриложения.Просто убедитесь, что на вашем сайте нет XSS-уязвимостей, в противном случае любой используемый вами метод токена является пустой тратой.

Вызов AJAX для регенерации токена - плохая идея.Кто будет охранять охрану?Если сам вызов AJAX уязвим для CSRF, он как бы побеждает цель.Несколько жетонов с AJAX вообще плохая идея.Это вынуждает вас сериализовать ваши запросы, т.е. только один AJAX-запрос разрешен за один раз.Если вы готовы жить с этим ограничением, вы, возможно, можете использовать токен для второго вызова AJAX в ответ на первый запрос.

Лично я считаю, что лучше провести повторную аутентификацию пользователя для критических транзакций,и защитите оставшиеся транзакции с помощью специфичного для сеанса токена.

Настраиваемый заголовок HTTP

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

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

Проверка Referrer

Проверка заголовка Referrer также хороша для защиты CSRF в новых браузерах.Подделать этот заголовок невозможно, хотя это было возможно в более старых версиях Flash.Таким образом, хотя он и не защищен от ошибок, он все же добавляет некоторую защиту.

Решающая капча

Заставление пользователя выполнить проверку капчи также эффективно против CSRF.Это чертовски неудобно, но довольно эффективно.Это, пожалуй, единственная защита CSRF, которая работает, даже если у вас есть уязвимости XSS.

Сводка

  1. Используйте токен на основе сеанса, но повторно аутентифицируйтесь для высокогозначение транзакции
  2. Добавьте пользовательский заголовок http, а также проверьте наличие реферера.Оба сами по себе не защищены от дурака, но не причиняют вреда
...