← Client-side security / client-side-security

Řešení potíží

Cloudflare neshromažďuje data z každého jednotlivého zobrazení stránky. Místo toho využívá vzorkovací přístup, aby efektivně získávalo informace. To znamená, že u domén s nižším provozem může vytvoření počátečních reportů trvat déle, protože tyto domény potřebují více zobrazení stránek, aby nashromáždily dostatek vzorků. Chcete-li tento proces urychlit, doporučujeme aktivně generovat provoz do vaší aplikace po aktivace sledování prostředků na straně klienta. Cloudflare tak bude mít k dispozici více dat, což vede k rychlejšímu generování reportů.

Další kroky, které můžete podniknout při řešení tohoto problému:

• Ověřte, že sledování prostředků na straně klienta je zapnuté.
• Po zapnutí monitorování prostředků na straně klienta a vygenerování určitého provozu ve vaší aplikaci (alespoň 100 požadavků) počkejte přibližně jednu hodinu, aby Cloudflare stihl shromáždit a zpracovat dostatek dat k zobrazení v dashboardu monitorování prostředků na straně klienta.
• Použijte nástroje pro vývojáře ve svém prohlížeči (Síť kartu) a zkontrolujte, zda content-security-policy-report-only hlavička HTTP je přítomen.
• Pomocí analytických řídicích panelů ověřte, zda provoz prochází přes Cloudflare.
• Zkontrolujte, zda odpovědi neobsahují duplicitní nebo konfliktní hlavičky Content Security Policy (CSP). Váš origin server možná do odpovědi přidává hlavičky CSP.

Skripty často odkazují na jiné skripty mimo vaši aplikaci.

Pokud však ve svém dashboardu monitorování prostředků uvidíte neočekávané skripty, zkontrolujte je, zda nevykazují známky škodlivé aktivity.

Cloudflare používá Content Security Policy (CSP) direktivu report-only ke shromáždění seznamu všech skriptů běžících ve vaší aplikaci.

Některé prohlížeče zobrazují hlášené skripty jako varování v panelu konzole svých vývojářských nástrojů. Například:

[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.

Tato upozornění můžete bez obav ignorovat, protože souvisejí s hlášeními, která Cloudflare potřebuje k detekci načtených skriptů. Další informace najdete v Jak funguje client-side security.

Porušení pravidel nahlášená prostřednictvím direktivy CSP direktiva report-only neberou v úvahu žádná přesměrování ani jejich stavové kódy HTTP. Toto je záměrně ↗ z bezpečnostních důvodů.

Některé služby třetích stran, které možná budete chtít zahrnout do svých povolovacích pravidel, provádějí přesměrování. Příkladem takové služby jsou Google Ads, které nefunguje dobře se zásadami CSP ↗.

Pokud například přidáte adservice.google.com domény do pravidla allow rule, můžete pro tuto doménu začít dostávat hlášení o porušení pravidel kvůli přesměrování na jinou doménu (která ve vašem pravidle allow rule není uvedena). V takovém případě bude hlášení o porušení stále uvádět původní doménu, a nikoli doménu cílového přesměrování, což může být matoucí.

Tento problém můžete vyřešit tak, že do pravidla povolení přidáte doménu cílového přesměrování. Vzhledem k přesměrováním možná budete muset do pravidla přidat několik domén.

Pokud se hlášení o porušení odkazují na domény patřící službám pro správu souhlasu uživatelů nebo sledování chování, pravděpodobnou příčinou je rozšíření prohlížeče pro blokování reklam nainstalované v prohlížeči návštěvníka.

Taková rozšíření obvykle požadavky na tyto domény blokují, často tak, že je přesměrují na místní prostředek, místo aby je nechala dosáhnout cíle. Jelikož hlášení o porušení uvádí původní doménu požadovanou stránkou, nikoli tento blokovaný nebo přesměrovaný cíl, můžete narazit na hlášení o porušení u domény, kterou jste už zařadili na allowlist.

Protože toto chování spouští pouze návštěvníci s nainstalovanými těmito rozšířeními, hlášení o porušeních jsou ve srovnání s celkovým objemem provozu vašeho webu vzácná.

Pokud provozujete SSL for SaaS kořenovou zónu s vlastními hostiteli a nakonfigurovali jste vymezené upozornění s pravidlem zabezpečení obsahu, které používá 'self' klíčové slovo, budete dostávat upozornění na zdroje zjištěné napříč všemi custom hostnames obsluhovanými v rámci vaší kořenové zóny, nejen v rámci vašich vlastních aplikací.

Toto je očekávané chování:

• SSL for SaaS aplikuje pravidlo zabezpečení obsahu vaší kořenové zóny na každý vlastní hostname obsluhovaný v jejím rámci.
• 'self' klíčové slovo ve směrnici CSP odpovídá hostname obsluhovaného požadavku. Když custom hostname načte své vlastní skripty, tyto skripty odpovídají 'self' a cílené upozornění se spustí.

Ve velkém měřítku SaaS to může vytvořit vysoký objem upozornění napříč hostname, které nemáte pod správou, a znesnadňuje to omezit rozsah vlastních auditů shody (například na konkrétní stránky, kde shromažďujete údaje o platebních kartách).

V současné době neexistuje způsob, jak omezit pravidlo zabezpečení obsahu pouze na kořenovou zónu a vyloučit vlastní hostname. Pokud potřebujete sledovat pouze plochy vlastní aplikace, zvažte jednu z následujících možností:

• Použijte výraz pravidla zabezpečení obsahu, který odpovídá pouze konkrétním cestám stránek, které máte pod kontrolou (například cestám požadavků, kde shromažďujete údaje o držiteli karty).
• Nahraďte 'self' s explicitním seznamem hostitelů, které máte pod kontrolou. Mějte na paměti, že v měřítku SaaS to bývá málokdy proveditelné, protože hlavičky CSP mají praktické limity velikosti.
• Pokud vám nevyhovuje žádné z alternativních řešení, obraťte se na tým odpovědný za váš účet a nahlaste zájem o omezení pravidel zabezpečení obsahu pouze na kořenovou zónu SaaS.

Pokud jste nakonfigurovali pravidlo zabezpečení obsahu, ale očekávaná hlavička CSP se do odpovědí nepřidává, Transform Rules může přepisovat cestu požadavku ještě předtím, než se pravidlo content security rule vyhodnotí.

Cloudflare vyhodnocuje pravidla v konkrétní pořadí napříč různými fázemi. URL Rewrite Rules se spouštějí brzy v životním cyklu požadavku, zatímco pravidla zabezpečení obsahu se vyhodnocují později, ve fázích odpovědi.

To znamená, že pokud vaše pravidlo zabezpečení obsahu vyhodnocuje příchozí požadavky na základě cesty URI požadavku (například pomocí pole http.request.uri.path), pravidlo zabezpečení obsahu se vyhodnotí vůči přepsané cestě, nikoli vůči původní cestě URI, kterou požadoval návštěvník.

Chcete-li tento problém vyřešit, zvolte jeden z následujících postupů:

• Aktualizovat podmínku pravidla zabezpečení obsahu tak, aby odpovídala přepsané cestě: Změňte výraz svého pravidla tak, aby odpovídal přepsané cestě URI, a ne původní cestě URI návštěvníka.

• Použít nezpracovaná pole pro shodu s původní cestou URI: Použijte raw.http.request.uri.path pole místo http.request.uri.path pole ve výrazu vašeho pravidla content security rule. Nezpracovaná pole zachovávají původní hodnoty požadavku a nejsou ovlivněny pravidly Transform Rules.

Při řešení tohoto problému zvažte použití Cloudflare Trace k ověření, jak se cesta požadavku mění při průchodu jednotlivými fázemi.

Pokud odpovědi obsahují duplicitní Content-Security-Policy nebo Content-Security-Policy-Report-Only hlaviček, je to pravděpodobně způsobeno tím, že máte současně nastavené client-side security a pravidlo transformace hlaviček odpovědi přidávají stejný typ hlavičky.

Pravidla zabezpečení obsahu automaticky přidávají do odpovědí hlavičky CSP:

• Pravidla typu Log přidejte Content-Security-Policy-Report-Only hlaviček.
• Pravidla typu Allow přidejte Content-Security-Policy hlaviček.

Pokud máte nakonfigurované pravidlo Response Header Transform Rule s Přidat operaci pro stejný typ hlavičky, budou v odpovědi přítomny obě hlavičky.

Když prohlížeče narazí na více hlaviček CSP, vynutí je všechny a platí nejpřísnější zásada. To může vést k neočekávanému blokování legitimních prostředků.

Pokud potřebujete používat Response Header Transform Rules společně se zásadami client-side security, použijte Nastavit staticky nebo Nastavit dynamické operace. Tyto operace nahradí veškerou existující hodnotu hlavičky, včetně hlaviček přidaných funkcí Client-Side Security od Cloudflare. Použití těchto operací způsobí, že vaše transformační pravidlo bude mít přednost před Client-Side Security.

Při řešení tohoto problému postupujte podle následujících kroků:

1. Použijte nástroje pro vývojáře ve svém prohlížeči (Síť kartu) a zkontrolujte hlavičky odpovědi, zda neobsahují duplicitní hlavičky CSP.
2. Zkontrolujte nakonfigurované Response Header Transform Rules a zkontrolujte, zda některé z nich nepoužívají Přidat operace pro Content-Security-Policy nebo Content-Security-Policy-Report-Only hlaviček.
3. Změňte operaci z Přidat na Nastavit staticky nebo Nastavit dynamické pokud chcete, aby transform rule přepsalo hlavičky CSP nastavené prostřednictvím client-side security.
4. Případně zakažte pravidlo zabezpečení obsahu nebo upravte jeho rozsah tak, aby se nekrylo s vaším transform rule.