Настройка script-src

Что такое CSP?



Политика безопасности контента (CSP)
Политика безопасности контента (CSP) — это дополнительный уровень безопасности, который помогает обнаруживать и смягчать определенные типы атак…разработчик. mozilla.org





CSP мертв, да здравствует CSP! О небезопасности белых списков и будущем безопасности контента…
Политика безопасности контента — это механизм веб-платформы, предназначенный для предотвращения межсайтового скриптинга (XSS), наивысшего уровня безопасности… ай.гугл



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

Давайте сосредоточимся на script-src, важной директиве, определяющей допустимый исполняемый JavaScript.

`script-src` позволит вам предоставить домены из белого списка в форме ‹host-source› вместе с self' исходным доменом.

Content-Security-Policy: script-src 'self' https://abc.com/

Таким образом, с такой политикой веб-сайт сможет получать JavaScript только с "я" (текущий домен) и abc.com, и больше ничего не будет работать. Встроенные скрипты, а также встроенные обработчики событий не будут работать.

Вы можете заставить работать встроенные скрипты и обработчики событий, добавив «unsafe-inline»:

Content-Security-Policy: script-src 'unsafe-inline' 'self' https://abc.com/;

но это сводит на нет нашу цель, и, кроме того, встроенные обработчики событий, такие как onclick, onerror, НЕТ.

Избавьтесь от них уже.

Чтобы избежать использования 'unsafe-inline', CSP предоставляет две мощные схемы, которые блокируют встроенные обработчики событий:

  1. ‘nonce-‹base64-value›’
Content-Security-Policy: script-src 'nonce-2726c7f26c'
<script nonce="2726c7f26c">
  var inline = True;
</script>
<script >
  var evil = True;
</script>

В приведенном выше фрагменте вредоносный скрипт не будет выполняться.

В соответствии с этим вы можете внести в белый список известные встроенные сценарии, прикрепив атрибут случайная строка к своим встроенным сценариям.

Этот одноразовый номер в идеале должен быть для каждого запроса, если вы не добавляете встроенные скрипты на лету.

В моем случае мы добавляли встроенные скрипты на лету, поэтому мы сохраняли их для каждой сессии.

2. ‹алгоритм хеширования›-‹значение base64›

При этом проверяется целостность встроенного скрипта. Для каждого встроенного скрипта необходимо будет сгенерировать хеш для всех ваших встроенных скриптов (только содержимое).

//Nodejs
const crypto = require('crypto');
const shasum = crypto.createHash('sha1')
shasum.update('var inline=true;') // generated the hash  
//Get the hash in hexadecimal format
const generatedHash = shasum.digest('hex');

«Сгенерированный хэш» будет частью CSP следующим образом:

Content-Security-Policy: script-src 'sha256-'ea0aa06d4917a188f91ded433a238f77915ae89d542810b6a07542b419dd647d'

Это вам нужно будет предоставить для всех встроенных скриптов. Более того, как только вы измените встроенные скрипты, хэш необходимо будет сгенерировать заново. Возможно, вы можете автоматизировать этот процесс, если у вас есть рендеринг на стороне сервера.

Оба вышеупомянутых подхода добавляют ваш встроенный скрипт в белый список, но в то же время запрещают встроенные обработчики. Если вы все еще хотите сохранить их, проверьте директиву fetch: unsafe-hashes.

К вашему сведению, CSP оказывает влияние на весь веб-сайт/продукт, и его рекомендуется использоватьContent-Security-Policy-Report-Only.

Вам нужно будет предоставить директиву report-uri, которая будет прослушивать любые нарушения CSP. Если вы получите какие-либо ответы здесь, то, скорее всего, вы что-то пропустили, или CSP выполняет свою работу, и кто-то пытается использовать ваш веб-сайт не по назначению.

Спасибо за чтение.