Защита CSRF с помощью заголовка CORS Origin против токена CSRF

Этот вопрос касается защиты от атак типа Cross Site Request Forgery.

Речь идет конкретно о: Защита через заголовок Origin (CORS) так же хорошо, как защита через токен CSRF?

Пример:

  • Алиса вошла в систему (используя файл cookie) со своим браузером, чтобы " https://example.com". Я предполагаю, что она использует современный браузер.
  • Алиса посещает " https://evil.com", а код клиента evil.com выполняет какой-то запрос на " https://example.com" (классический сценарий CSRF).

Итак:

  • Если мы не проверяем заголовок Origin (серверная сторона) и не токены CSRF, у нас есть дыра безопасности CSRF.
  • Если мы проверим токен CSRF, мы будем в безопасности (но это немного утомительно).
  • Если мы проверим заголовок Origin, запрос с кодового кода на стороне evil.com должен быть заблокирован так же хорошо, как и при использовании токена CSRF - кроме того, если возможно как-то для кода evil.com установить Заголовок заголовка.

Я знаю, что это невозможно с помощью XHR (см., например, Безопасность для совместного использования ресурсов для разных источников), по крайней мере, нет, если мы доверяем спецификации W3C для правильной реализации во всех современных браузерах (можно?)

Но как насчет других видов запросов - например, Форма отправить? Загрузка тега script/img/...? Или любой другой способ, которым страница может использовать (юридически) создание запроса? Или, может быть, некоторые известные JS-хаки?

Примечание: я не говорю о

  • родные приложения,
  • управляемые браузеры,
  • ошибки на сценарии межсайтового скрипта на странице example.com,
  • ...

ОТВЕТЫ

Ответ 1

знать, что это не должно быть возможно с XHR (см., например, "Безопасность для совместного использования ресурсов между разными источниками" ), по крайней мере, нет, если мы доверяем спецификации W3C, которая будет правильно реализована во всех современных браузерах (можем ли мы?)

В конце дня вам нужно "доверять" браузеру клиента, чтобы безопасно хранить пользовательские данные и защищать клиентскую сторону сеанса. Если вы не доверяете браузеру клиента, вы должны прекратить использовать веб-сайт вообще для чего-либо, кроме статического контента. Даже с использованием токенов CSRF вы доверяете браузеру клиента правильно подчиняться политике одинакового происхождения.

Несмотря на наличие ранее уязвимостей браузера, таких как те, что находятся в IE 5.5/6.0, где злоумышленники могли обойти политику одинакового происхождения и выполнить атаки, вы обычно могут ожидать, что они будут исправлены, как только они будут обнаружены, и с большинством браузеров, автоматически обновляющихся, этот риск будет в основном смягчен.

Но как насчет других видов запросов - например, Форма отправить? Загрузка тега script/img/...? Или любой другой способ, которым страница может использовать (юридически) создание запроса? Или, может быть, некоторые известные JS-хаки?

Заголовок Origin обычно отправляется только для междоменных запросов XHR. Запросы изображений не содержат заголовок.

Примечание: я не говорю о

  • собственные приложения,

  • управляемые браузеры,

  • Ошибки межсайтового скриптинга на странице example.com,

Я не уверен, попадает ли это под манипулируемые браузеры или нет, но старые версии Flash позволяют устанавливать произвольные заголовки, которые позволят злоумышленнику отправить запросить с поддельным заголовком referer с компьютера-жертвы, чтобы выполнить атаку.

Ответ 2

Веб-контент не может вмешиваться в заголовок Origin. Кроме того, по одной и той же исходной политике одно происхождение не может даже отправлять пользовательские заголовки в другое происхождение. [1]

Таким образом, проверка заголовка Origin так же хороша при блокировании атак, как использование токена CSRF.

Основная проблема, связанная с этим, заключается в том, разрешает ли она выполнение всех законных запросов. Об этом вопрошает айзер и задал вопрос, чтобы исключить основные случаи (без старых браузеров, только HTTPS).

Поставщики браузеров следуют этим правилам, но как насчет плагинов? Они не могут, но вопрос игнорирует "манипулируемые браузеры". Как насчет ошибок в браузере, которые позволяют злоумышленнику подделывать заголовок Origin? Могут быть ошибки, которые позволяют токену CSRF просачиваться по истокам, поэтому потребовалось бы больше работы, чтобы утверждать, что один лучше другого.