Defaults.Exposed › Opravy › Content-Security-Policy (CSP)

Jak opravit Content-Security-Policy (CSP)

Content Security Policy je bezpečnostní pravidlo, které váš web předá prohlížeči každého návštěvníka a říká mu přesně, jaký kód smí spouštět. Bez něj, pokud se někdy dostane na stránku cokoli škodlivého — prostřednictvím komentářového pole, hacknutého pluginu nebo skriptu třetí strany — prohlížeč ho spustí volně, včetně kódu, který tiše sbírá čísla karet a hesla zákazníků při psaní, přičemž zámek stále svítí.

Výsledek pro vaše podnikání: Pokud je váš web někdy neoprávněně pozměněn, škodlivý kód může číst platební karty a přihlašovací údaje vašich zákazníků přímo z vašeho pokladního okna, zatímco vše vypadá zcela normálně — zanechávajíce vás s chargeback, podvodnými nároky, reportabilním narušením dat a selháním kontroly, které bezpečnostní týmy větších klientů používají k zastavení nebo zrušení obchodu.

Co vás to může stát

• Skrytý kód se vsune na jednu z vašich stránek a tiše kopíruje každé číslo karty a heslo, které vaši zákazníci zadají u pokladny, a odesílá je útočníkovi, zatímco váš web vypadá a funguje naprosto normálně — dozvíte se o tom až o týdny později, kdy přijdou stížnosti na podvod.
• Podvodník vloží falešný formulář 'plaťte zde' na váš skutečný web, který zachycuje platby na jeho vlastní účet; zákazníci si myslí, že platili vám, viní vás, když zboží nikdy nedorazí, a požadují peníze zpět.
• Bezpečnostní tým většího klienta prohledá váš web, uvidí tuto základní ochranu vypnutou a označí ho — zastavení nebo ztráta smlouvy, dokud nemůžete prokázat, že je opravena.
• Narušení vysledované k chybějícímu standardnímu ochranou se stane reportabilním incidentem: otázky regulátorů, oznámení zákazníků a poškození pověsti, které stojí daleko více než bezplatná oprava.

Proč na tom záleží. Zámek dokazuje, že připojení k vašemu webu je soukromé, ale nedělá nic pro kontrolu toho, jaký kód se spustí, jakmile je návštěvník na stránce. Content Security Policy je bezpečnostní opatření, které to dělá — říká prohlížečům ignorovat jakýkoliv skript, který nepochází ze zdroje, jemuž důvěřujete, takže jedno neoprávněně pozměněné pole, reklama nebo plugin nemůže být přeměněna na nástroj pro kradení peněz a dat vašich zákazníků. Je to hodnocená kontrola na vašem hodnotícím listu, stojící skutečné body, a jedna z prvních věcí, které profesionální bezpečnostní revize hledá.

Co to je, prostými slovy

Když někdo navštíví váš web, jejich prohlížeč stáhne vaši stránku a spustí jakýkoliv kód na ní — skripty, které způsobují, že menu se rozbaluje, tlačítka fungují, platební formuláře odesílají a tak dále. Ve výchozím nastavení mu prohlížeč důvěřuje vše. Nemá způsob, jak vědět, jaký kód je skutečně váš a jaký byl vsunut někým jiným.

Content Security Policy (často zkracována na CSP) je krátký seznam pravidel, který váš web připojí ke každé stránce a říká prohlížeči: “spouštěj pouze kód z těchto zdrojů, které jsem schválil, a odmítni vše ostatní.” Je to rozdíl mezi nočním klubem, který pustí kohokoliv, a tím, který má seznam hostů u dveří.

Důvod, proč na tom tak záleží, je ten, že webové stránky jsou neustále neoprávněně pozměňovány — ne vždy hackováním vašeho serveru, ale prostřednictvím zadních dveří, které většina webů ponechává otevřené: komentářové pole, vyhledávací pole, zastaralý plugin, skript třetí strany pro reklamy nebo analytiku nebo widget chatu. Pokud útočník dostane i jeden řádek svého vlastního kódu na jednu z vašich stránek, prohlížeč ho spustí, jako by byl váš. Odtud může číst vše, co vaši zákazníci zadají — čísla karet, hesla, adresy — a tiše to odesílat jinam. Content Security Policy zavírá tyto dveře tím, že odmítne spustit cokoliv ze zdroje, který jste neschválili.

Co vás to může stát

Toto není abstraktní. Útok, kterému Content Security Policy brání — kód vstřikovaný do stránky, který krade data od vašich zákazníků — je za některými z největších narušení skimmingu karet v záznamu. Zde je to, jak to obvykle vypadá pro normální firmu:

• Neviditelný skimmer pokladny. Útočník vsune pár řádků kódu na vaši stránku pokladny prostřednictvím zranitelného pluginu nebo kompromitovaného skriptu třetí strany. Každé číslo karty, jméno a CVV, které vaši zákazníci zadají, je zkopírováno a odesláno útočníkovi v reálném čase. Váš web vypadá a funguje perfektně; zámek je tam. Dozvíte se o tom o týdny později, když váš platební poskytovatel zavolá o shluku podvodných hlášení, která se vracejí k vašemu obchodu. Nyní čelíte chargeback, nucenému bezpečnostnímu auditu, možné ztrátě práv na zpracování karet a narušení, které možná musíte právně hlásit.

• Falešný platební formulář. Podvodník vstříkne přesvědčivé pole “plaťte zde” na váš skutečný web. Zákazníci zadají své údaje důvěřujíce vaší značce; peníze a data jdou útočníkovi. Zákazníci viní vás — a nejsou v tom nesprávní, protože se to stalo na vašem webu.

• Ztracená smlouva. Bezpečnostní tým většího zákazníka spustí automatický sken vašeho webu jako součást vendor due diligence. Chybějící Content Security Policy se okamžitě zobrazí jako mezera vysoké závažnosti. Pro nákupního nebo bezpečnostního recenzenta tato jediná chybějící bezpečnostní opatření říká “tento dodavatel nedělá základy” — a obchod stagnuje, zatímco žádají o nápravu nebo tiše jdou ke konkurenci, který prošel.

• Reportabilní narušení. Když je narušení dat vysledováno k chybějící, standardní, bezplatné bezpečnostní opatření, přestane být smůlou a začne vypadat jako nedbalost. To mění otázky regulátorů, povinnost oznámení zákazníkům a náklady — jak pokutu, tak poškození pověsti, které přetrvává dlouho po uzavření incidentu.

• Kompromitovaná reklama nebo widget. Mnoho webů načítá kód od externích stran — reklamní sítě, písma, podpůrný chat, analytika. Pokud je kterýkoliv z nich narušen, škodlivý kód se vezme přímo na vaše stránky. Content Security Policy omezuje poloměr výbuchu tím, že povolí pouze konkrétní externí zdroje, kterým důvěřujete, takže narušení jednoho dodavatele se automaticky nestane vaším.

Co to vlastně je (detail)

Content Security Policy je doručena jako jediná hlavička HTTP odpovědi — řádek, který váš webový server pošle s každou stránkou. Jeho hodnota je sada direktiv, každá pojmenovávající typ obsahu a zdroje povolené pro něj. Například:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self'

Prostými slovy to říká: ve výchozím nastavení načítejte věci pouze z mého vlastního webu; spouštějte pouze skripty z mého vlastního webu; nepovolujte žádné staré pluginy; a nedovolte jiným webům vložit mě do rámce.

Jak vypadá ‘dobré’ nastavení. Naše kontrola nehledá pouze přítomnost hlavičky — čte politiku direktivu po direktivě a hodnotí, jak silná skutečně je, tak jak by to udělal bezpečnostní recenzent. Silná politika:

• Nastaví omezující výchozí nastavení (default-src 'self') a rozšiřuje ho pouze pro konkrétní důvěryhodné třetí strany, které skutečně používáte.
• Vyhýbá se mezerám. Nepoužívá 'unsafe-inline' nebo 'unsafe-eval' pro skripty a nepoužívá zástupný znak (*) nebo holé zdrojové schémata (jako https:) pro skripty — tyto fakticky znovu otevírají dveře, které politika má uzavřít. Tam kde jsou inline skripty skutečně potřebné, používá nonce nebo hash, takže spouštět se může pouze váš konkrétní schválený kód.
• Uzamkne rámování pomocí frame-ancestors 'self' (toto také blokuje útok “vložte váš web k oklamání zákazníků”) a zakáže starší pluginy pomocí object-src 'none'.
• Je vynucovací, nikoli pouze hlásit. Hlavička Content-Security-Policy-Report-Only pouze sleduje; poskytuje nulovou ochranu za běhu. Naše kontrola jí dá zlomek kreditu a nikdy nezaznamená jako průchod. Jste chráněni teprve po vynucení politiky.

Politika, která existuje, ale spoléhá na 'unsafe-inline', 'unsafe-eval' nebo zástupné znaky, bude stále skórovat špatně — protože v praxi poskytuje malou skutečnou ochranu. Cílem je přísná politika, nikoli jen jakákoliv politika.

Jak to opravit (zdarma, ~1–2 hodiny)

Předejte tuto část vašemu IT pracovníkovi nebo tomu, kdo provozuje váš web — oprava sama o sobě je zcela zdarma. Účtujeme pouze monitoring, zda zůstane na místě a bude správná v čase; zapnutí nestojí nic. Důvod, proč to trvá hodinu nebo dvě místo minut, je pečlivý zkušební krok, který zabrání omylovému zablokování části vašeho vlastního webu.

1. Začněte v režimu pouze hlásit — zatím nevynucujte. Přidejte hlavičku HTTP odpovědi Content-Security-Policy-Report-Only. Toto sleduje a zaznamenává, co by bylo zablokováno, aniž by cokoliv skutečně blokovalo, takže živý web bude fungovat, zatímco se učíte, na čem každá stránka skutečně závisí. (Důležité: pouze hlásit sám o sobě nedává návštěvníkům žádnou ochranu — je to pouze bezpečný první krok.)

2. Sestavte politiku z toho, co váš web skutečně používá. Zkontrolujte přehledy, abyste našli každý legitimní zdroj skriptů, stylů, písem a obrázků — vaše vlastní doménu, vaši analytiku, vašeho platebního poskytovatele, hostitele písem, widget chatu — a uveďte je jako povolené zdroje. Solidní výchozí bod je default-src 'self' plus explicitní záznamy pro důvěryhodné třetí strany, které skutečně používáte.

3. Vyhýbejte se mezerám, které porazí celý smysl. Vyhýbejte se 'unsafe-inline' a 'unsafe-eval' pro skripty a vyhýbejte se zástupným znakům jako * a holým schématům jako https: pro skripty — tyto znovu otevírají přesně tu mezeru, kterou politika má uzavřít. Kde jsou inline skripty nevyhnutelné, použijte nonce nebo hash, takže spouštět se může pouze váš konkrétní schválený kód.

4. Uzamkněte rámování a pluginy. Přidejte frame-ancestors 'self' (toto také zastaví jiné weby v vložení vašeho webu k oklamání zákazníků a splňuje to související kontrolu clickjackingu) a object-src 'none' pro blokování útoků na starší pluginy.

5. Přepněte z pouze hlásit na vynucování. Jakmile jsou přehledy čisté a web funguje, změňte název hlavičky z Content-Security-Policy-Report-Only na Content-Security-Policy. Toto je krok, který skutečně přináší ochranu — politika pouze hlásit to nedělá a neprojde kontrolou.

   Kde nastavit hlavičku závisí na vaší platformě:

   • Cloudflare: Pravidla → Transformační pravidla → Upravit hlavičku odpovědi → nastavte Content-Security-Policy.
   • Nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';" always;
   • Apache: Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';"
   • IIS (web.config): přidejte vlastní hlavičku HTTP odpovědi s názvem Content-Security-Policy a politikou jako hodnotou.
   • Google Workspace / Microsoft 365: tyto spouštějí váš e-mail, nikoli váš veřejný web, takže politika se nastavuje kdekoliv je váš web skutečně hostován (Cloudflare nebo váš webhosting výše), nikoli v konzoli správce e-mailu.

6. Znovu zkontrolujte svou doménu a potvrďte, že politika nyní ukazuje jako zapnutá a vynucovací, bez oslabovacích mezer.

Běžné chyby

• Zastavení na pouze hlásit. Jediná nejčastější chyba: politika je přidána v režimu pouze hlásit, všichni se posunou dál a web není nikdy skutečně chráněn. Pouze hlásit nic neblokuje. Musíte přepnout na vynucování.
• Sáhnutí po 'unsafe-inline', aby to ‘prostě fungovalo.’ Když politika zablokuje legitimní inline skript, rychlá oprava je povolit všechny inline skripty — ale to znovu otevírá přesně tu díru, kterou politika měla uzavřít. Použijte místo toho nonce nebo hash.
• Použití zástupného znaku. Holý * (nebo https:) v script-src povoluje skripty odkudkoliv, což znamená, že politika poskytuje téměř žádnou skutečnou ochranu a bude stále skórovat nízko.
• Zapomenutí zdrojů třetích stran. Vynucení přísné politiky bez předchozího výpisu legitimních externích služeb, které používáte (analytika, písma, platební widgety), může rozbít části vašeho vlastního webu — přesně proto existuje zkušební krok pouze hlásit.
• Nastavení pouze na domovskou stránku. Politika musí pokrývat každou stránku, zejména pokladnu, přihlášení a stránky účtu — to jsou ty, které stojí za útok.
• Zacházení s ní jako náhradou za zámek. Content Security Policy a HTTPS/HSTS chrání různé věci. Chcete všechny z nich; jeden nezakrývá za druhý.

Časté dotazy