Токен защиты от CSRF и Javascript

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

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

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

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

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

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

Спасибо!


security ajax csrf antiforgerytoken
person Leonti    schedule 08.09.2010    source источник
comment
Ответ на тот же вопрос: stackoverflow.com/questions/33574343/ говорит, что AJAX разрешен для получения токенов CSRF   -  person M-A-X    schedule 26.02.2019

Ответы (1)


arrow_upward
27
arrow_downward

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

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

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

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

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

Пользовательский заголовок HTTP

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

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

Проверка реферера

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

Решение CAPTCHA

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

Сводка

  1. Используйте токен на основе сеанса, но повторно аутентифицируйте для транзакций с высокой стоимостью
  2. Добавьте собственный заголовок http, а также проверьте реферер. Оба ненадежны сами по себе, но не причиняют вреда
person Sripathi Krishnan    schedule 08.09.2010
comment
Добавление настраиваемого заголовка http меня беспокоит, я почти уверен, что вы можете подделать настраиваемые заголовки http с помощью flash и отправить запрос на другой сервер, если элемент заголовка не находится в черном списке. Я просмотрел недавние изменения во flash (за последние 3 месяца), и они исправили возможность управления всем сегментом POST, который был необходим для атак с загрузкой файлов между сайтами. Кроме этого, я думаю, что это хорошая информация, и я дал вам +1. - person rook; 08.09.2010
comment
Ага, вот черный список, конечно реферер не разрешен, но буквально все остальное разрешено. kb2.adobe.com/cps/403/kb403030.html - person rook; 08.09.2010
comment
@Ладья - Re. Добавление пользовательских заголовков — см. adobe.com/devnet/flashplayer/articles/. В частности, см. раздел «Разрешения на отправку заголовков». Цитирую When a SWF file wishes to send custom HTTP headers anywhere other than its own host of origin, there must be a policy file on the HTTP server to which the request is being sent. Помните, что stackoverflow.com/questions/2609834/? Вот где я узнал этот факт на собственном горьком опыте .. - person Sripathi Krishnan; 08.09.2010
comment
@SripathiKrishnan: во многих ответах на этом сайте упоминается, что токен должен быть указан в скрытом поле вместе с файлом cookie. Если значения обоих из них не совпадают, то это возможная ошибка CSRF. Я знаю, что из-за той же политики происхождения злоумышленники не могут просто прочитать или изменить файлы cookie в браузере жертвы. В дополнение к этой проверке необходимо ли видеть, совпадает ли значение этого токена с сохраненным в сеансе? Это нигде не упоминается. Это не должно иметь решающего значения, но я не уверен в этом. - person Tiny; 30.04.2013
comment
@SripathiKrishnan Почему вызов AJAX уязвим для CSRF? - person M-A-X; 26.02.2019