Усиление безопасности фронтенда: Content Security Policy и CORS

В современном взаимосвязанном цифровом мире безопасность фронтенда имеет первостепенное значение. Веб-приложения все чаще становятся мишенью для изощренных атак, что делает надежные меры безопасности крайне необходимыми. Два критически важных компонента безопасной архитектуры фронтенда — это Content Security Policy (CSP) и Cross-Origin Resource Sharing (CORS). Это подробное руководство предлагает глубокий анализ этих технологий, практические примеры и действенные советы, которые помогут вам укрепить ваши веб-приложения против современных угроз.

Что такое Content Security Policy (CSP)?

Content Security Policy (CSP) — это дополнительный уровень безопасности, который помогает обнаруживать и предотвращать определенные типы атак, включая межсайтовый скриптинг (XSS) и атаки с внедрением данных. CSP реализуется путем отправки веб-сервером HTTP-заголовка ответа Content-Security-Policy в браузер. Этот заголовок определяет «белый список» источников, из которых браузеру разрешено загружать ресурсы. Ограничивая источники контента, которые может загружать браузер, CSP значительно усложняет злоумышленникам внедрение вредоносного кода на ваш сайт.

Как работает CSP

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

Директивы CSP: подробный обзор

Директивы CSP контролируют типы ресурсов, которые могут быть загружены из определенных источников. Вот разбор некоторых наиболее важных директив:

• default-src: Указывает источник по умолчанию для всех типов контента. Это резервная директива, которая применяется, когда отсутствуют другие, более специфичные директивы.
• script-src: Указывает источники, из которых могут загружаться скрипты. Это крайне важно для предотвращения XSS-атак.
• style-src: Указывает источники, из которых могут загружаться таблицы стилей.
• img-src: Указывает источники, из которых могут загружаться изображения.
• font-src: Указывает источники, из которых могут загружаться шрифты.
• media-src: Указывает источники, из которых могут загружаться аудио и видео.
• object-src: Указывает источники, из которых могут загружаться плагины (например, Flash). Часто устанавливается в 'none', чтобы полностью отключить плагины из-за присущих им рисков безопасности.
• frame-src: Указывает источники, из которых могут загружаться фреймы (например, <iframe>).
• connect-src: Указывает URL-адреса, к которым пользовательский агент может подключаться с помощью скриптовых интерфейсов, таких как XMLHttpRequest, WebSocket и EventSource.
• base-uri: Указывает URL-адреса, которые могут использоваться в элементе <base> документа.
• form-action: Указывает URL-адреса, на которые могут отправляться данные форм.
• upgrade-insecure-requests: Указывает пользовательскому агенту автоматически обновлять небезопасные запросы (HTTP) до безопасных (HTTPS).
• report-uri: Указывает URL-адрес, куда браузер должен отправлять отчеты о нарушениях CSP. Эта директива устарела в пользу `report-to`.
• report-to: Указывает имя группы отчетов, определенное в заголовке `Report-To`, куда браузер должен отправлять отчеты о нарушениях CSP.

Ключевые слова для списка источников CSP

В директивах CSP можно использовать ключевые слова для определения разрешенных источников. Вот некоторые из распространенных ключевых слов:

• 'self': Разрешает ресурсы с того же источника (схема и хост), что и документ.
• 'none': Запрещает ресурсы из всех источников.
• 'unsafe-inline': Разрешает использование встраиваемых (inline) скриптов и стилей (например, теги <script> и атрибуты style). Используйте с крайней осторожностью, так как это значительно ослабляет защиту CSP от XSS.
• 'unsafe-eval': Разрешает использование функций динамического выполнения кода, таких как eval() и Function(). Используйте с крайней осторожностью, так как это создает значительные риски безопасности.
• 'unsafe-hashes': Разрешает определенные встраиваемые обработчики событий или теги <style>, соответствующие указанному хешу. Требует поддержки браузером. Используйте с осторожностью.
• 'strict-dynamic': Указывает, что доверие, явно предоставленное скрипту в разметке путем сопровождения его nonce-значением или хешем, должно распространяться на все скрипты, загружаемые этим корневым скриптом.
• data: Разрешает data: URI (например, встраиваемые изображения, закодированные в base64). Используйте с осторожностью.
• https:: Разрешает загрузку ресурсов по HTTPS с любого домена.
• [hostname]: Разрешает ресурсы с определенного домена (например, example.com). Также можно указать номер порта (например, example.com:8080).
• [scheme]://[hostname]:[port]: Полностью определенный URI, разрешающий ресурсы с указанной схемы, хоста и порта.

Практические примеры CSP

Рассмотрим несколько практических примеров заголовков CSP:

Пример 1: Базовый CSP с 'self'

Эта политика разрешает ресурсы только с того же источника:

            Content-Security-Policy: default-src 'self'
            

              
                Copy
              
            
          

Пример 2: Разрешение скриптов с определенного домена

Эта политика разрешает скрипты с вашего собственного домена и доверенного CDN:

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

              
                Copy
              
            
          

Пример 3: Отключение встраиваемых скриптов и стилей

Эта политика запрещает встраиваемые скрипты и стили, что является сильной защитой от XSS:

            Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'
            

              
                Copy
              
            
          

Важно: Отключение встраиваемых скриптов требует рефакторинга вашего HTML для перемещения встраиваемых скриптов во внешние файлы.

Пример 4: Использование Nonce для встраиваемых скриптов

Если вам необходимо использовать встраиваемые скрипты, используйте nonce (криптографически случайные, одноразовые токены), чтобы добавить определенные блоки встраиваемых скриптов в «белый список». Это более безопасно, чем 'unsafe-inline'. Сервер должен генерировать уникальный nonce для каждого запроса и включать его как в заголовок CSP, так и в тег <script>.

            Content-Security-Policy: default-src 'self'; script-src 'nonce-r4nd0mN0nc3'; style-src 'self'
            

              
                Copy
              
            
          

            <script nonce="r4nd0mN0nc3"> console.log('Inline script'); </script>
            

              
                Copy
              
            
          

Примечание: Не забывайте генерировать новый nonce для каждого запроса. Не используйте nonce повторно!

Пример 5: Использование хешей для встраиваемых стилей

Подобно nonce, хеши можно использовать для добавления в «белый список» определенных встраиваемых блоков <style>. Это делается путем генерации хеша SHA256, SHA384 или SHA512 от содержимого стиля.

            Content-Security-Policy: default-src 'self'; style-src 'sha256-HASHEDSTYLES'
            

              
                Copy
              
            
          

            <style sha256="HASHEDSTYLES"> body { background-color: #f0f0f0; } </style>
            

              
                Copy
              
            
          

Примечание: Хеши менее гибки, чем nonce, поскольку любое изменение содержимого стиля сделает хеш недействительным.

Пример 6: Отправка отчетов о нарушениях CSP

Для мониторинга нарушений CSP используйте директиву report-uri или report-to:

            Content-Security-Policy: default-src 'self'; report-to csp-endpoint;
            

              
                Copy
              
            
          

Вам также потребуется настроить заголовок Report-To. Заголовок Report-To определяет одну или несколько групп отчетов, которые указывают, куда и как следует отправлять отчеты.

            Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"https://example.com/csp-report"}]}
            

              
                Copy
              
            
          

Тестирование и развертывание CSP

Внедрение CSP требует тщательного планирования и тестирования. Начните с ограничительной политики и постепенно ослабляйте ее по мере необходимости. Используйте заголовок Content-Security-Policy-Report-Only для тестирования вашей политики без блокировки ресурсов. Этот заголовок сообщает о нарушениях, не применяя политику, что позволяет выявлять и исправлять проблемы перед развертыванием политики в производственной среде.

            Content-Security-Policy-Report-Only: default-src 'self'; report-to csp-endpoint;
            

              
                Copy
              
            
          

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

Лучшие практики для CSP

• Начинайте с default-src: Всегда определяйте default-src, чтобы установить базовую политику.
• Будьте конкретны: Используйте конкретные директивы и ключевые слова списка источников, чтобы ограничить область действия вашей политики.
• Избегайте 'unsafe-inline' и 'unsafe-eval': Эти ключевые слова значительно ослабляют CSP и их следует избегать по возможности.
• Используйте nonce или хеши для встраиваемых скриптов и стилей: Если вам необходимо использовать встраиваемые скрипты или стили, используйте nonce или хеши для добавления определенных блоков кода в «белый список».
• Отслеживайте нарушения CSP: Используйте директиву report-uri или report-to для мониторинга нарушений CSP и соответствующей корректировки вашей политики.
• Тщательно тестируйте: Используйте заголовок Content-Security-Policy-Report-Only для тестирования вашей политики перед развертыванием в производственной среде.
• Итерируйте и улучшайте: CSP — это не одноразовая настройка. Постоянно отслеживайте и совершенствуйте свою политику, чтобы адаптироваться к изменениям в вашем приложении и ландшафте угроз.

Что такое Cross-Origin Resource Sharing (CORS)?

Cross-Origin Resource Sharing (CORS) — это механизм, который позволяет веб-страницам с одного источника (домена) получать доступ к ресурсам с другого источника. По умолчанию браузеры применяют Политику одного источника (Same-Origin Policy), которая запрещает скриптам делать запросы к источнику, отличному от того, с которого был загружен сам скрипт. CORS предоставляет способ выборочно ослабить это ограничение, разрешая легитимные междоменные запросы и защищая от вредоносных атак.

Понимание Политики одного источника

Политика одного источника — это фундаментальный механизм безопасности, который предотвращает доступ вредоносного скрипта с одного веб-сайта к конфиденциальным данным на другом. Источник определяется схемой (протоколом), хостом (доменом) и портом. Два URL-адреса имеют один и тот же источник, если и только если у них совпадают схема, хост и порт.

Например:

• https://www.example.com/app1/index.html и https://www.example.com/app2/index.html имеют один и тот же источник.
• https://www.example.com/index.html и http://www.example.com/index.html имеют разные источники (разная схема).
• https://www.example.com/index.html и https://sub.example.com/index.html имеют разные источники (разный хост).
• https://www.example.com:8080/index.html и https://www.example.com:80/index.html имеют разные источники (разный порт).

Как работает CORS

Когда веб-страница делает междоменный запрос, браузер сначала отправляет серверу «предварительный» (preflight) запрос. Предварительный запрос использует метод HTTP OPTIONS и включает заголовки, указывающие метод HTTP и заголовки, которые будет использовать фактический запрос. Затем сервер отвечает заголовками, указывающими, разрешен ли междоменный запрос.

Если сервер разрешает запрос, он включает заголовок Access-Control-Allow-Origin в ответ. Этот заголовок указывает источник(и), которым разрешен доступ к ресурсу. Затем браузер переходит к фактическому запросу. Если сервер не разрешает запрос, он не включает заголовок Access-Control-Allow-Origin, и браузер блокирует запрос.

Заголовки CORS: детальный взгляд

CORS использует HTTP-заголовки для обмена данными между браузером и сервером. Вот ключевые заголовки CORS:

• Access-Control-Allow-Origin: Указывает источник(и), которым разрешен доступ к ресурсу. Этот заголовок может содержать конкретный источник (например, https://www.example.com), подстановочный знак (*) или null. Использование * разрешает запросы с любого источника, что обычно не рекомендуется по соображениям безопасности. Использование `null` подходит только для «непрозрачных ответов», например, когда ресурс извлекается с использованием протокола `file://` или data URI.
• Access-Control-Allow-Methods: Указывает HTTP-методы, разрешенные для междоменного запроса (например, GET, POST, PUT, DELETE).
• Access-Control-Allow-Headers: Указывает HTTP-заголовки, разрешенные в междоменном запросе. Это важно для обработки пользовательских заголовков.
• Access-Control-Allow-Credentials: Указывает, должен ли браузер включать учетные данные (например, cookie, заголовки авторизации) в междоменный запрос. Этот заголовок должен быть установлен в true, чтобы разрешить передачу учетных данных.
• Access-Control-Expose-Headers: Указывает, какие заголовки могут быть доступны клиенту. По умолчанию доступен только ограниченный набор заголовков.
• Access-Control-Max-Age: Указывает максимальное время (в секундах), в течение которого браузер может кешировать предварительный запрос.
• Origin: Это заголовок запроса, отправляемый браузером для указания источника запроса.
• Vary: Общий HTTP-заголовок, но важный для CORS. Когда `Access-Control-Allow-Origin` генерируется динамически, заголовок `Vary: Origin` должен быть включен в ответ, чтобы указать кеширующим механизмам, что ответ зависит от заголовка запроса `Origin`.

Практические примеры CORS

Рассмотрим несколько практических примеров конфигураций CORS:

Пример 1: Разрешение запросов с определенного источника

Эта конфигурация разрешает запросы только с https://www.example.com:

            Access-Control-Allow-Origin: https://www.example.com
            

              
                Copy
              
            
          

Пример 2: Разрешение запросов с любого источника (не рекомендуется)

Эта конфигурация разрешает запросы с любого источника. Используйте с осторожностью, так как это может создать риски безопасности:

            Access-Control-Allow-Origin: *
            

              
                Copy
              
            
          

Пример 3: Разрешение определенных методов и заголовков

Эта конфигурация разрешает методы GET, POST и PUT, а также заголовки Content-Type и Authorization:

            Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
            

              
                Copy
              
            
          

Пример 4: Разрешение передачи учетных данных

Чтобы разрешить передачу учетных данных (например, cookie), вам нужно установить Access-Control-Allow-Credentials в true и указать конкретный источник (вы не можете использовать * при разрешении учетных данных):

            Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Credentials: true
            

              
                Copy
              
            
          

Вам также нужно установить credentials: 'include' в вашем JavaScript-запросе fetch/XMLHttpRequest.

            fetch('https://api.example.com/data', {
  credentials: 'include'
})
            

              
                Copy
              
            
          

Предварительные запросы CORS (Preflight)

Для определенных типов междоменных запросов (например, запросов с пользовательскими заголовками или методами, отличными от GET, HEAD или POST с Content-Type application/x-www-form-urlencoded, multipart/form-data или text/plain), браузер отправляет предварительный запрос с использованием метода OPTIONS. Сервер должен ответить на предварительный запрос соответствующими заголовками CORS, чтобы указать, разрешен ли фактический запрос.

Вот пример предварительного запроса и ответа:

Предварительный запрос (OPTIONS):

            OPTIONS /data HTTP/1.1
Origin: https://www.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type, Authorization
            

              
                Copy
              
            
          

Ответ на предварительный запрос (200 OK):

            HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400
            

              
                Copy
              
            
          

Заголовок Access-Control-Max-Age указывает, как долго браузер может кешировать ответ на предварительный запрос, уменьшая количество таких запросов.

CORS и JSONP

JSON с набивкой (JSONP) — это старая техника для обхода Политики одного источника. Однако JSONP сопряжен со значительными рисками безопасности, и его следует избегать в пользу CORS. JSONP основан на внедрении тегов <script> на страницу, что может привести к выполнению произвольного кода. CORS предоставляет более безопасный и гибкий способ обработки междоменных запросов.

Лучшие практики для CORS

• Избегайте использования *: Избегайте использования подстановочного знака (*) в заголовке Access-Control-Allow-Origin, так как это разрешает запросы с любого источника. Вместо этого указывайте конкретный(е) источник(и), которым разрешен доступ к ресурсу.
• Будьте конкретны с методами и заголовками: Указывайте точные HTTP-методы и заголовки, разрешенные в заголовках Access-Control-Allow-Methods и Access-Control-Allow-Headers.
• Используйте Access-Control-Allow-Credentials с осторожностью: Включайте Access-Control-Allow-Credentials только в том случае, если вам нужно разрешить передачу учетных данных (например, cookie) в междоменных запросах. Помните о последствиях для безопасности при разрешении учетных данных.
• Защищайте ваши предварительные запросы: Убедитесь, что ваш сервер правильно обрабатывает предварительные запросы и возвращает правильные заголовки CORS.
• Используйте HTTPS: Всегда используйте HTTPS как для источника, так и для ресурсов, к которым вы обращаетесь междоменно. Это помогает защититься от атак «человек посередине».
• Vary: Origin: Если вы динамически генерируете заголовок `Access-Control-Allow-Origin`, всегда включайте заголовок `Vary: Origin`, чтобы предотвратить проблемы с кешированием.

CSP и CORS на практике: комбинированный подход

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

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

Пример: защита API с помощью CSP и CORS

Предположим, у вас есть API, размещенный по адресу https://api.example.com, который должен быть доступен только с https://www.example.com. Вы можете настроить свой сервер так, чтобы он возвращал следующие заголовки:

Заголовки ответа API (https://api.example.com):

            Access-Control-Allow-Origin: https://www.example.com
Content-Type: application/json
            

              
                Copy
              
            
          

И вы можете настроить ваш веб-сайт (https://www.example.com) на использование следующего заголовка CSP:

Заголовок CSP веб-сайта (https://www.example.com):

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

              
                Copy
              
            
          

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

Заключение

Content Security Policy (CSP) и Cross-Origin Resource Sharing (CORS) — это важные инструменты для усиления безопасности ваших фронтенд-приложений. Тщательно настраивая CSP и CORS, вы можете значительно снизить риск XSS-атак, атак с внедрением данных и других уязвимостей безопасности. Не забывайте начинать с ограничительной политики, тщательно тестировать и постоянно отслеживать и совершенствовать вашу конфигурацию, чтобы адаптироваться к изменениям в вашем приложении и развивающемуся ландшафту угроз. Отдавая приоритет безопасности фронтенда, вы можете защитить своих пользователей и обеспечить целостность ваших веб-приложений в современном, все более сложном цифровом мире.