Защита от CSRF атак с CORS заголовок происхождения и CSRF токена

этот вопрос касается защиты только от атак подделки межсайтовых запросов.

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

пример:

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

Так:

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

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

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

примечание: Я не говорю о

  • нативные приложения,
  • манипулировать браузеры,
  • ошибки межсайтового скриптинга в example.com ' s page,
  • ...
2 78
javascript security cors csrf

2 ответа:

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

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

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

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

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

примечание: Я не говорю о

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

  • манипулировать браузеры,

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

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

33

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

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

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

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

25