Как определить Политику безопасности контента (CSP), которая использует «строго-динамический», но включает запасной вариант для использования «unsafe-inline»? - PullRequest
Новая
       31

Как определить Политику безопасности контента (CSP), которая использует «строго-динамический», но включает запасной вариант для использования «unsafe-inline»?

0 голосов
/ 18 декабря 2018

Я внедряю заголовок CSP на веб-сайте, который должен динамически загружать некоторые скрипты по разным причинам (в основном плагины).Это легко достигается определением script-src с использованием 'строгого-динамического' вместе с хэшем / одноразовым номером для нединамических сценариев.

В рекомендациях везде предлагается также включить некоторые высокоуровневые источники / схемы и 'небезопасныеinline 'как запасной вариант, если браузер не поддерживает CSPv3 и, следовательно, не поддерживает' строго-динамическую 'и динамическую загрузку: 

script-src: 'strict-dynamic' 'sha256-somesortofhash...' https: 'unsafe-inline';

Этот резервный метод будет хорошо работать для браузеров, которые поддерживают толькоCSPv1:

  • «строго-динамический» игнорируется (не распознается).
  • значение хеш-функции игнорируется (не распознается).
  • https: и «unsafe-inline»

Но, похоже, не работает для браузеров CSPv2:

  • строгий-динамический игнорируется (не распознается).
  • хэшзначение принудительно.
  • https: принудительно.
  • «unsafe-inline» игнорируется (из-за принудительного применения хэша).

Как определитьполитика с правильным резервом для браузеров CSPv2 также?

1 Ответ

0 голосов
/ 02 мая 2019

'strict-dynamic' предназначен в основном для работы в сочетании с одноразовыми номерами.Вы правы - не существует идеального отката CSPv2 при использовании в сочетании с хешами.

Непокрытый случай - это динамически генерируемые встроенные сценарии - по моему опыту, это редкий шаблон: 

var s = document.createElement('script');
s.innerText = 'alert(1)';
document.body.appendChild(s);

будетне работают в CSPv2-совместимых браузерах, и лучшее решение в этом случае - это анализировать UA и вообще не отправлять политику.

Сценарии с исходным кодом будут работать просто отлично.

С другой стороныстороны, основанная на одноразовых значениях политика, такая как: 

script-src 'nonce-r4nd0m' 'strict-dynamic' 'unsafe-inline' https:

изящно отступит, потому что для случая выше вы всегда можете установить одноразовый номер вручную: 

var s = document.createElement('script');
s.setAttribute('nonce', 'df7Af03DRTs66pP');
s.innerText = 'alert(1)';
document.body.appendChild(s);

Подробнее о backwardсовместимость и ошибки в наших презентациях [1] [2] .

[1] https://speakerdeck.com/mikispag/content-security-policy-a-successful-mess-between-hardening-and-mitigation?slide=52

[2] https://speakerdeck.com/mikispag/so-we-broke-all-csps-dot-dot-dot-you-wont-guess-what-happened-next-michele-spagnuolo-and-lukas-weichselbaum?slide=15

...