Этот вопрос касается только защиты от атак с подделкой межсайтовых запросов.
В частности, речь идет о том, насколько эффективна защита с помощью заголовка 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 может каким-то образом установить заголовок Origin.
Я знаю, что это невозможно с XHR (см., Например, Безопасность для совместного использования ресурсов между источниками ), по крайней мере, нет, если мы верим, что спецификация W3C будет правильно реализована во всех современных браузерах (можем ли мы?)
Но как насчет других типов запросов - например, отправки формы? Загружаете тег script / img / ...? Или каким-либо другим способом, который страница может использовать для (легального) создания запроса? А может, какой-нибудь известный взлом JS?
Примечание: я не говорю о
- нативные приложения,
- манипулируемые браузеры,
- ошибки межсайтового скриптинга на странице example.com,
- ...
javascript
security
cors
csrf
Крис Леркер
источник
источник
Origin? Это свело бы на нет защиту CORS.Ответы:
В конце концов, вы должны «доверять» клиентскому браузеру безопасное хранение данных пользователя и защиту клиентской части сеанса. Если вы не доверяете клиентскому браузеру, вам следует вообще прекратить использование Интернета для чего-либо, кроме статического контента. Даже с использованием токенов CSRF вы доверяете клиентскому браузеру правильно соблюдать политику одного и того же происхождения .
Хотя в браузере уже были уязвимости, например, в IE 5.5 / 6.0, когда злоумышленники могли обойти политику одного и того же происхождения и выполнить атаки, обычно вы можете ожидать, что они будут исправлены, как только обнаружены, и большинство браузеров будут автоматически обновляться. , этот риск будет в основном снижен.
OriginЗаголовок , как правило , отправляется только для запросов кросс-доменных XHR. Запросы изображений не содержат заголовок.Я не уверен, относится ли это к управляемым браузерам или нет, но старые версии Flash допускали установку произвольных заголовков, которые позволяли бы злоумышленнику отправить запрос с поддельным
refererзаголовком с машины жертвы для выполнения атаки.источник
crossdomain.xmlвозможность включения междоменного взаимодействия.Веб-контент не может вмешиваться в заголовок Origin. Более того, согласно той же политике происхождения, один источник не может даже отправлять настраиваемые заголовки в другие источники. [1]
Таким образом, проверка заголовка Origin так же хорошо блокирует атаки, как и использование токена CSRF.
Основное беспокойство при использовании этого метода заключается в том, позволяет ли он работать всем законным запросам. Спрашивающий знает об этой проблеме и установил вопрос, чтобы исключить основные случаи (без старых браузеров, только HTTPS).
Производители браузеров следуют этим правилам, но как насчет плагинов? Может и нет, но вопрос не принимает во внимание «манипулируемые браузеры». А как насчет ошибок в браузере, которые позволяют злоумышленнику подделать заголовок Origin? Могут быть ошибки, которые позволяют токену CSRF просачиваться через источники, поэтому потребуется больше работы, чтобы доказать, что один лучше, чем другой.
источник