Политика безопасности контента (CSP)
Политика безопасности контента доставляется через заголовок ответа HTTP, как и HSTS, и определяет утвержденные источники контента, которые может загружать браузер. Это может быть эффективным средством противодействия атакам с использованием межсайтовых сценариев (XSS), а также широко поддерживается и обычно легко развертывается.
Зачем нам CSP?
Когда ваш браузер загружал эту страницу, он загружал вместе с ней множество других ресурсов. Существуют таблицы стилей и шрифты для загрузки вместе с довольно большим количеством файлов javascript
. Один для системы комментариев Disqus, один для Google Analytics и др. Ваш браузер загружает эти ресурсы, потому что это указано в исходном коде страницы. У него нет возможности узнать, нужно или нет загружать какие-либо из этих файлов.
Злоумышленник мог разместить специально созданный комментарий в разделе комментариев, чтобы загрузить вредоносный javascript
из стороннего домена, и он также будет загружен вашим браузером, поскольку он был включен вместе со страницей. У вашего браузера нет причин не доверять контенту сайта и нет возможности узнать, что контент является вредоносным. Здесь на помощь приходит CSP.
Внесение разрешенных источников в белый список
Заголовок CSP позволяет вам определять утвержденные источники контента на вашем сайте, который может загружать браузер. Указав только те источники, из которых вы хотите, чтобы браузер загружал контент, вы можете защитить своих посетителей от целого ряда проблем. Вот основной заголовок ответа CSP.
Content-Security-Policy: script-src 'self'
Возвращаясь к приведенному выше примеру, когда злоумышленник использует специально созданный комментарий для загрузки JavaScript из другого домена, этот заголовок CSP предотвратит загрузку содержимого браузером из сайта. В script-src
директиве определяется белый список источников, что браузер может загружать.
Что мы можем защитить?
CSP поставляется с широким набором директив, которые можно использовать для обеспечения соблюдения политики в отношении всего контента и обстоятельств.
Вот список всех доступных директив вместе с кратким описанием, любезно предоставленный OWASP:
https://owasp.org/www-community/attacks/Content_Security_Policy
Читать
Вот звезды сошлись:)) Тоже недавно для поставил YetiForceCRM посмотреть, в админке рисует, что не все в порядке...
Кто знает где менять эти параметры?
И вот еще одна загадка:))
Можете подсказать что за cron (CLI)... Прошу извинить если не совсем в тему, админ если что - удали.
Я даже не знаю, что такое YetiFroce CRM, пришлось гуглить. На первом фото, заголовки, например: X-Robots-Tag. А на втором фото, посмотрите настройку Opcache:
https://yandex.ru/support/webmaster/controlling-robot/meta-robots.html
Да я смотрел, в ISPmanager все меняется для режимов php: apache, CGI, PHP-FPM... А что за cron (CLI) сие неведомая тайна для меня:)) Здесь смотрел /etc/php/7.4/cli/php.ini но ничего не нашел там... В поддержку хостинга написал - там просят какие то ошибки им пошагово воспроизвести:)) Говорю нет ошибок - как поменять третий столбец?:))
Мне понравилось, как эта политика была реализована в Discourse и решил тут повторить это. Пусть будет ещё одной линией обороны. ) Однако, проверять сценарий желательно с выключенной политикой. Иногда есть тенденции, что ставку делают на неё только. Не особо верно. Без неё всё должно быть нормально, и тогда её включаем.