← Client-side security / client-side-security

Устранение неполадок

Cloudflare собирает данные не по каждому просмотру страницы, а использует выборочный подход для эффективного сбора информации. Это означает, что доменам с меньшим трафиком может потребоваться больше времени для формирования первых отчётов, поскольку им нужно больше просмотров страниц для накопления достаточного количества выборок. Чтобы ускорить процесс формирования отчётов, рекомендуется активно генерировать трафик на ваше приложение после активация мониторинга клиентских ресурсов. Это предоставит Cloudflare больше данных для работы, что ускорит формирование отчетов.

Другие действия, которые помогут устранить эту проблему:

• Убедитесь, что мониторинг клиентских ресурсов включён.
• После включения мониторинга клиентских ресурсов и генерации трафика к вашему приложению (не менее 100 запросов) подождите примерно час, чтобы Cloudflare успел собрать и обработать достаточно данных для отображения в панели мониторинга клиентских ресурсов.
• Используйте инструменты разработчика в браузере (Сеть вкладку), чтобы проверить, content-security-policy-report-only HTTP-заголовок присутствует.
• Используйте панели аналитики, чтобы убедиться, что трафик проксируется через Cloudflare.
• Проверьте, не содержат ли ответы дублирующиеся или конфликтующие заголовки Content Security Policy (CSP). Возможно, ваш исходный сервер также добавляет заголовки CSP к ответу.

Скрипты часто ссылаются на другие скрипты за пределами вашего приложения.

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

Cloudflare использует Content Security Policy (CSP) директиву report-only, чтобы собрать список всех скриптов, выполняющихся в вашем приложении.

Некоторые браузеры отображают сообщения о скриптах в виде предупреждений на панели консоли инструментов разработчика. Например:

[Report Only] Refused to execute inline script because it violates
the following Content Security Policy directive: "script-src 'none'".

Either the 'unsafe-inline' keyword, a hash ('sha256-RFWPLDbv2BY+rCkDzsE+0fr8ylGr2R2faWMhq4lfEQc='), or a nonce ('nonce-...')
is required to enable inline execution.

Эти предупреждения можно спокойно игнорировать, так как они связаны с отчётами, которые нужны Cloudflare для обнаружения загружаемых скриптов. Дополнительные сведения см. в Как работает client-side security.

Нарушения правил, о которых сообщается через CSP директива report-only не учитывают переадресации или коды состояния HTTP для переадресации. Это по замыслу ↗ из соображений безопасности.

Некоторые сторонние сервисы, которые вы можете указать в правилах разрешения, выполняют перенаправления. Например, такой сервис как Google Ads, который плохо работает с политиками CSP ↗.

Например, если вы добавите adservice.google.com домен в правило Allow, вы можете получать отчёты о нарушении правил для этого домена из-за переадресаций на другой домен (отсутствующий в вашем правиле Allow). В этом случае отчёт о нарушении будет по-прежнему указывать исходный домен, а не домен конечной точки переадресации, что может вызвать путаницу.

Чтобы решить эту проблему, добавьте домен конечной точки переадресации в своё правило Allow. Из-за переадресаций в правило может потребоваться добавить несколько доменов.

Если в отчётах о нарушениях указаны домены, принадлежащие сервисам управления согласием пользователей или отслеживания поведения, вероятной причиной является расширение для блокировки рекламы, установленное в браузере посетителя.

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

Поскольку такое поведение вызывают только посетители с установленными этими расширениями, отчётов о нарушениях немного по сравнению с общим объёмом трафика вашего сайта.

Если вы управляете SSL for SaaS корневой зоны с custom hostnames, и вы настроили ограниченное оповещение с правилом безопасности контента, которое использует 'self' ключевое слово, вы будете получать оповещения о ресурсах, обнаруженных на всех пользовательских хостах в вашей корневой зоне, а не только в пределах вашего приложения.

Это ожидаемое поведение:

• SSL for SaaS применяет правило безопасности контента корневой зоны к каждому пользовательскому имени хоста, обслуживаемому в её рамках.
• 'self' ключевое слово в директиве CSP соответствует имени хоста обрабатываемого запроса. Когда пользовательский хост загружает собственные скрипты, эти скрипты соответствуют 'self' и срабатывает точечное оповещение.

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

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

• Используйте в правиле безопасности контента выражение, которое соответствует только тем путям страниц, которые вы контролируете (например, путям запросов, по которым собираются данные держателей карт).
• Замените 'self' с явным списком хостов, которые вы контролируете. Обратите внимание, что в масштабах SaaS это редко осуществимо, поскольку заголовки CSP имеют практические ограничения по размеру.
• Если ни один из этих способов не подходит, обратитесь в свою команду по работе с аккаунтом и сообщите о заинтересованности в том, чтобы правила безопасности контента можно было ограничивать только корневой зоной SaaS.

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

Cloudflare оценивает правила в определённый порядок на разных этапах. URL Rewrite Rules выполняются на раннем этапе жизненного цикла запроса, тогда как правила безопасности контента применяются позже, на этапах формирования ответа.

Это означает, что если правило безопасности контента сопоставляет входящие запросы на основе пути URI запроса (например, используя поле http.request.uri.path), правило безопасности контента будет применяться к переписанному пути, а не к исходному пути URI, запрошенному посетителем.

Чтобы устранить эту проблему, выберите один из следующих способов:

• Измените условие правила безопасности контента, чтобы оно соответствовало переписанному пути: Измените выражение правила так, чтобы оно соответствовало переписанному пути URI, а не исходному пути URI посетителя.

• Используйте необработанные поля, чтобы сопоставлять исходный путь URI: Используйте raw.http.request.uri.path поле вместо http.request.uri.path поле в выражении вашего правила безопасности контента. Необработанные поля сохраняют исходные значения запроса и не зависят от Transform Rules.

При устранении этой проблемы попробуйте использовать Cloudflare Trace чтобы проверить, как путь запроса изменяется при прохождении через разные фазы.

Если в ответах присутствуют дублирующиеся Content-Security-Policy или Content-Security-Policy-Report-Only заголовков, вероятная причина в том, что одновременно используются и client-side security, и правило преобразования заголовка ответа добавляя заголовок того же типа.

Правила безопасности контента автоматически добавляют заголовки CSP к ответам:

• Правила типа Log добавьте Content-Security-Policy-Report-Only заголовки.
• Правила Allow добавьте Content-Security-Policy заголовки.

Если у вас настроено правило Response Header Transform Rule с Add операция для одного и того же типа заголовка, в ответе будут присутствовать оба заголовка.

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

Если вам нужно использовать Response Header Transform Rules вместе с политиками client-side security, используйте Задать статическое значение или Включить динамический режим операций. Эти операции заменяют любое существующее значение заголовка, включая заголовки, добавленные функцией Client-Side Security от Cloudflare. При использовании этих операций ваше правило преобразования будет иметь приоритет над Client-Side Security.

Чтобы устранить эту проблему, выполните следующие действия:

1. Используйте инструменты разработчика в браузере (Сеть вкладку), чтобы просмотреть заголовки ответа и проверить наличие дублирующихся заголовков CSP.
2. Проверьте настроенные вами Response Header Transform Rules и проверьте, использует ли какой-либо из них Add операция для Content-Security-Policy или Content-Security-Policy-Report-Only заголовки.
3. Измените операцию с Add к Задать статическое значение или Включить динамический режим если хотите, чтобы правило Transform Rules переопределяло заголовки CSP client-side security.
4. Как вариант, отключите правило безопасности контента или измените его область действия, чтобы избежать пересечения с правилом transform rule.