Установите границы для выполнения вашего JavaScript с помощью CSP, чтобы противостоять широкому спектру угроз безопасности

Насколько вы уверены, что ваш код JavaScript защищен от злоумышленников? И почему вас это должно волновать? Когда мы смотрим на современные веб-приложения, общим является то, что все они используют JavaScript. В некоторых приложениях преобладает JavaScript, внося свой вклад в большую часть кода. Одним из важных свойств JavaScript является то, что код, который мы пишем, выполняется в браузере пользователя, к которому у нас ограниченный доступ.

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

Знаете ли вы, можете ли вы указать браузеру, чтобы он соответствовал ряду рекомендаций и выполнял ваш код JavaScript?

Прочитав эту статью, вы узнаете об общих атрибутах политик безопасности контента и о том, как их можно использовать для защиты кода JavaScript во время выполнения.

Политика безопасности контента

Политика безопасности контента (CSP) - это дополнительный уровень безопасности, который помогает обнаруживать и смягчать определенные типы атак, включая атаки с использованием межсайтовых сценариев (XSS) и атаки путем внедрения данных. Эти атаки используются для всего: от кражи данных до искажения сайта и распространения вредоносного ПО.

Как следует из названия, CSP - это набор инструкций, которые вы можете отправить с кодом JavaScript в браузер для управления его выполнением. Например, вы можете настроить CSP, чтобы ограничить выполнение JavaScript набором доменов из белого списка и игнорировать любые встроенные скрипты и обработчики событий для защиты от XSS-атак. Кроме того, вы можете указать, что все сценарии должны загружаться через HTTPS, чтобы снизить риск атак с перехватом пакетов.

Итак, как мне настроить CSP для веб-приложения?

Есть два способа настроить CSP. Один из подходов - вернуть определенный HTTP-заголовокContent-Security-Policy.. Другой - указать элемент <meta> на вашей HTML-странице.

Совет. Используйте Bit (Github) для совместного использования, документирования и управления повторно используемыми компонентами из разных проектов. Это отличный способ увеличить повторное использование кода, ускорить разработку и создавать масштабируемые приложения.

Bit поддерживает Vanilla JS, TypeScript, React, Angular, Vue и многие другие.

Давайте посмотрим на образец CSP

Предположим, вы установили следующееContent-Security-Policy для своего веб-приложения.

Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com;

Затем это разрешит загрузку сценариев JavaScripts, как из https://example.com/js/*, но будет блокировать https://someotherexample.com/js/* браузером, как указано в CSP. Более того, любые встроенные скрипты также блокируются по умолчанию, если только вы не используете хэши или одноразовые коды для их выполнения.

Если вы не слышали о хэшах или объявлениях, я настоятельно рекомендую обратиться к этой ссылке в качестве примера, чтобы понять ее истинный потенциал.

Вкратце, с помощью операции хеширования вы можете указать хеш файла JavaScript в качестве атрибута блока Script, где браузер сначала проверяет хеш перед его выполнением.

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

Как узнать, есть ли нарушения CSP?

Прелесть CSP заключается в том, что он учитывает сценарий сообщения о нарушениях вам. В рамках CSP вы можете определить URL-адрес, по которому браузер пользователя будет автоматически отправлять отчет о нарушении обратно на ваш сервер для дальнейшего анализа.

Для этого вам необходимо настроить конечную точку, которая обрабатывает полезные данные POST, отправленные браузером как отчет о нарушении CSP. Ниже показан пример указания пути /csp-incident-reports для получения полезных данных отчета о нарушении.

Content-Security-Policy: default-src 'self'; report-uri /csp-incident-reports

Если мы включим JavaScript или стиль за пределами собственного происхождения сайта (например, otherdomain.com), скажем случайно, когда мы посетим URL-адрес сайта (например, example.com), вышеуказанная политика отклонит его от загрузки в браузер и отправьте следующий отчет о нарушении в качестве полезной нагрузки HTTP POST.

{
  "csp-report": {
    "document-uri": "http://example.com/index.html",
    "referrer": "",
    "blocked-uri": "http://otherdomain.com/css/style.css",
    "violated-directive": "default-src 'self'",
    "original-policy": "default-src 'self'; report-uri /csp-incident-reports"
  }
}

Поддержка браузера и инструменты

Как видите, все основные браузеры поддерживают функцию CSP. Это хорошая новость, поскольку инвестиции, которые мы вложили в создание CSP, направлены на расширение пользовательской базы.

Кроме того, браузеры, такие как Chrome, пошли еще дальше, предоставив инструменты для проверки атрибутов CSP. Например, если вы определяете хэш сценариев JavaScripts, Консоль разработчика Chrome будет предлагать разработчикам правильный хеш для исправления любой ошибки.

Кроме того, если вы используете Webpack для объединения своих сценариев JavaScripts, вы можете найти плагин Webpack с именем CSP HTML Webpack Plugin, чтобы добавить хэш во время сборки, чтобы автоматизировать этот процесс.

Резюме

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

Однако также важно провести надлежащий анализ всех ресурсов, используемых в приложении, перед созданием CSP. Благодаря этому вы можете создать более строгий CSP, добавив в белый список все известные ресурсы и заблокировав другие по умолчанию.

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