Политика безопасности контента (CSP) помогает гарантировать, что владелец сайта доверяет любому контенту, загружаемому на страницу. CSP смягчают атаки с использованием межсайтовых сценариев (XSS), поскольку они могут блокировать небезопасные сценарии, внедряемые злоумышленниками. Однако CSP можно легко обойти, если он недостаточно строг. Для получения дополнительной информации ознакомьтесь со статьей «Устранение межсайтового скриптинга (XSS) с помощью строгой политики безопасности контента (CSP)» . Lighthouse собирает CSP, примененные к основному документу, и сообщает о проблемах в CSP Evaluator, если их можно обойти.
Необходимые практики для необходимого CSP
Внедрите следующие методы, чтобы гарантировать невозможность обхода вашего CSP. Если CSP можно обойти, Lighthouse выдаст предупреждение высокой степени серьезности.
CSP нацелен на XSS
Чтобы настроить XSS, CSP должен включать директивы script-src , object-src и base-uri . CSP также не должен содержать синтаксических ошибок.
script-src и object-src защищают страницу от небезопасных скриптов и небезопасных плагинов соответственно. Альтернативно, default-src можно использовать для настройки широкой политики вместо многих директив, включая script-src и object-src .
base-uri предотвращает внедрение неавторизованных тегов <base> , которые можно использовать для перенаправления всех относительных URL-адресов (например, сценариев) в домен, контролируемый злоумышленником.
CSP использует одноразовые номера или хэши, чтобы избежать обхода белого списка.
CSP, который настраивает список разрешений для script-src исходит из предположения, что все ответы, поступающие из доверенного домена, безопасны и могут выполняться как сценарии. Однако это предположение не справедливо для современных приложений; некоторые распространенные, безопасные шаблоны, такие как раскрытие интерфейсов JSONP и размещение копий библиотеки AngularJS, позволяют злоумышленникам выйти за пределы CSP.
На практике, хотя это может быть неочевидно для авторов приложений, большинство списков разрешений script-src могут быть обойти злоумышленником с помощью XSS-ошибки и обеспечить слабую защиту от внедрения скриптов. Напротив, подходы на основе nonce и хэша не страдают от этих проблем и упрощают принятие и поддержку более безопасной политики.
Например, этот код использует конечную точку JSONP, размещенную в доверенном домене, для внедрения сценария, контролируемого злоумышленником:
КСП:
script-src https://trusted.example.com
HTML:
<script src="https://trusted.example.com/path/jsonp?callback=alert(document.domain)//"></script>
Чтобы избежать обхода, CSP должен разрешать сценариям индивидуальное использование одноразовых номеров или хешей и использовать «строго-динамический» вместо списка разрешений.
Дополнительные рекомендации для безопасного CSP
Внедрите следующие методы для повышения безопасности и совместимости. Если CSP не выполнит одну из рекомендаций, Lighthouse выдаст предупреждение средней степени серьезности.
Настройка отчетов CSP
Настройка места назначения отчетов поможет отслеживать любые сбои. Вы можете установить место назначения отчетов, используя директивы report-uri или report-to . report-to в настоящее время поддерживается не всеми современными браузерами, поэтому рекомендуется использовать оба или только report-uri .
Если какой-либо контент нарушает CSP, браузер отправит отчет в настроенное место назначения. Убедитесь, что в этом пункте назначения настроено приложение, обрабатывающее эти отчеты.
Определите CSP в заголовке HTTP
CSP можно определить в метатеге следующим образом:
<meta http-equiv="Content-Security-Policy" content="script-src 'none'">
Однако по возможности вам следует определить CSP в заголовке ответа HTTP. Внедрение перед метатегом обойдет CSP. Кроме того, в CSP метатегов не поддерживаются frame-ancestors , sandbox и отчеты.
Убедитесь, что CSP обратно совместим
Не все браузеры поддерживают одноразовые номера/хэши CSP, поэтому рекомендуется добавить unsafe-inline в качестве запасного варианта для несовместимых браузеров. Если браузер поддерживает nonce/хэши, unsafe-inline будет игнорироваться.
Аналогично, strict-dynamic поддерживается не всеми браузерами. Рекомендуется установить белый список в качестве запасного варианта для любых несовместимых браузеров. Белый список будет игнорироваться в браузерах, поддерживающих strict-dynamic .
Как разработать строгий CSP
Ниже приведен пример использования строгого CSP с политикой на основе nonce.
КСП:
script-src 'nonce-random123' 'strict-dynamic' 'unsafe-inline' https:;
object-src 'none';
base-uri 'none';
report-uri https://reporting.example.com;
HTML:
<script nonce="random123" src="https://trusted.example.com/trusted_script.js"></script>
random123 будет любая строка base64, генерируемая на стороне сервера каждый раз, когда загружается страница. unsafe-inline и https: игнорируются в современных браузерах из-за nonce и strict-dynamic . Дополнительные сведения о принятии строгого CSP см. в руководстве Strict CSP .
Вы можете проверить CSP на наличие потенциальных обходов с помощью Lighthouse и CSP Evaluator . Если вы хотите протестировать новый CSP без риска повреждения существующих страниц, определите CSP в режиме «только отчет», используя Content-Security-Policy-Report-Only в качестве имени заголовка. При этом нарушения CSP будут отправляться в любые пункты назначения отчетов, которые вы настроили с помощью report-to и report-uri , но фактически это не приведет к принудительному применению CSP.