Content Security Policy patří mezi nejúčinnější ochrany proti XSS a dalším útokům založeným na spuštění cizího kódu v prohlížeči. Přesto ji řada webů stále nepoužívá – nebo ji má nastavenou tak benevolentně, že část jejího smyslu mizí.

Důvod je jednoduchý. CSP se snadno vysvětluje, ale podstatně hůř nasazuje na existující web, který používá analytiku, CDN, fonty, externí obrázky, widgety a JavaScript třetích stran.

Když jsme v Testomatu začali na žádost zákazníka připravovat možnost monitorovat Content-Security-Policy, zjistili jsme trochu ironickou věc, že náš vlastní web ji v té době taky neměl.

Rozhodli jsme se tedy projít celým procesem sami.

Co vlastně CSP dělá

Content Security Policy umožňuje webu určit, odkud smí prohlížeč načítat jednotlivé typy prostředků.

Pomocí HTTP hlavičky lze například řídit:

• odkud se smí načítat JavaScript,
• které servery mohou poskytovat obrázky a fonty,
• kam může aplikace navazovat spojení,
• kdo může web zobrazit v iframe,
• kam mohou formuláře odesílat data,
• nebo zda jsou povoleny elementy <object> a <embed>.

Velmi jednoduchá politika může vypadat například takto:

Content-Security-Policy: default-src 'self'Code language: JavaScript (javascript)

Taková konfigurace říká prohlížeči, aby prostředky načítal pouze ze stejného originu.

Na většině dnešních webů by ale podobné pravidlo okamžitě způsobilo problémy. Stačí Google Analytics, obrázky z CDN, externí fonty nebo několik řádků inline JavaScriptu.

Proto je lepší CSP nezapínat rovnou „naostro“.

Začněte režimem Report-Only

Pro CSP existuje speciální hlavička:

Content-Security-Policy-Report-Only

Používá stejnou syntaxi jako běžná CSP, ale porušení pravidel nezablokuje.

Prohlížeč pouze oznámí, co by podle dané politiky nebylo povolené. Díky tomu lze CSP nejprve bezpečně otestovat na reálném provozu.

Praktický postup může vypadat takto:

1. vytvořit počáteční CSP,
2. nasadit ji jako Content-Security-Policy-Report-Only,
3. sledovat porušení,
4. doplnit legitimní zdroje,
5. odstranit zbytečné výjimky,
6. přepnout politiku do ostrého režimu.

Při nasazení na Testomato jsme tímto způsobem objevili několik zdrojů, na které jsme při přípravě politiky původně zapomněli – například externí obrázky a skripty používané pouze na některých stránkách.

Direktiva default-src nestačí

CSP se skládá z jednotlivých direktiv pro různé typy obsahu.

Typická politika používá například:

default-src
script-src
style-src
img-src
font-src
connect-src
frame-src
frame-ancestors
form-action
base-uri
object-srcCode language: JavaScript (javascript)

default-src funguje jako výchozí pravidlo. Konkrétnější direktivy jej mohou přepsat:

Content-Security-Policy:
    default-src 'self';
    img-src 'self' https://images.example.com;Code language: JavaScript (javascript)

V tomto případě lze obrázky načítat také z images.example.com, ale ostatní prostředky pouze z vlastního originu.

unsafe-inline je pohodlné, ale problematické

Při nasazování CSP často narazíte na hodnoty:

'unsafe-inline'
'unsafe-eval'Code language: JavaScript (javascript)

Jejich přidání dokáže rychle vyřešit problémy s nefunkčním webem, současně ale výrazně oslabuje ochranu.

Lepší možností jsou nonce nebo hashe.

Například:

<script nonce="RANDOM_VALUE">
    // ...
</script>Code language: HTML, XML (xml)

a odpovídající CSP:

Content-Security-Policy:
    script-src 'nonce-RANDOM_VALUE'Code language: JavaScript (javascript)

Prohlížeč pak spustí pouze skripty s odpovídajícím nonce.

Nasazení je o něco složitější, ale výsledná politika je výrazně bezpečnější než CSP postavená na unsafe-inline.

CSP je potřeba kontrolovat i po nasazení

Jednou správně nastavená CSP není konečný stav. Web se průběžně mění. Přidáte nový analytický nástroj, aktualizujete frontend, změníte CDN nebo konfiguraci proxy. A stejně snadno může během deploymentu bezpečnostní hlavička úplně zmizet. Proto je užitečné rozlišovat dvě věci:

CSP reporting říká, co se prohlížeče návštěvníků pokoušejí načíst a co politika blokuje.

Monitoring samotné CSP hlavičky ověřuje, že je politika stále správně nasazená a obsahuje očekávaná pravidla.

Obě kontroly se doplňují.

Co má smysl automaticky hlídat

U produkčního webu lze pravidelně kontrolovat například:

Content-Security-Policy existuje
script-src neobsahuje 'unsafe-inline'
frame-ancestors existuje
object-src je 'none'
base-uri je správně nastavenéCode language: JavaScript (javascript)

Taková kontrola dokáže upozornit na regresi ještě předtím, než si jí někdo všimne ručně.

Právě zde dává smysl využít externí monitoring. V Testomatu lze kromě dostupnosti webu kontrolovat také HTTP odpovědi a jejich hlavičky. CSP tak můžete zahrnout mezi ostatní automatické kontroly produkce a nechat si například hlídat, zda hlavička nezmizela nebo zda stále obsahuje očekávanou direktivu.

Výhodou je, že podobnou kontrolu nemusíte řešit jako samostatný bezpečnostní nástroj. Může být součástí stejného monitoringu, který už kontroluje dostupnost webu, HTTP stavové kódy, přesměrování nebo SSL certifikát.

Dobrá CSP nemusí být dokonalá od prvního dne

Při zavádění CSP je snadné skončit u dvou extrémů. Buď nasadíte příliš přísnou politiku a rozbijete části webu, nebo naopak povolíte tolik výjimek, že CSP ztratí většinu svého významu.

Lepší je iterovat:

bez CSP
↓
Report-Only
↓
sběr dat
↓
úprava politiky
↓
ostrý režim
↓
monitoring
↓
postupné zpřísňování

Nemusíte mít perfektní CSP první den. Důležité je vědět, co aplikace skutečně používá, co politika dovoluje a zda se konfigurace časem nezměnila.

Bezpečnostní hlavičky jsou součást produkce

CSP dobře ukazuje obecnější princip: bezpečnostní konfigurace není něco, co jednou nastavíte a už se k tomu nevracíte. Stejně jako monitorujeme dostupnost webu, expiraci SSL certifikátu nebo správnou HTTP odpověď, má smysl průběžně kontrolovat také bezpečnostní hlavičky.

Pro CSP se osvědčuje kombinovat:

1. Report-Only při zavádění nové politiky,
2. reporting porušení pravidel z prohlížečů,
3. externí monitoring samotné CSP hlavičky.

První pomáhá politiku bezpečně vytvořit. Druhé ukazuje reálné chování návštěvníků. A třetí hlídá, že konfigurace na produkci stále skutečně existuje. Bezpečnostní hlavička je totiž nakonec pořád jen konfigurace. A konfigurace se mění, rozbíjí a občas při deploymentu jednoduše zmizí.

---

Článek vychází ze zkušeností týmu Testomato s nasazováním a monitorováním Content Security Policy. Testomato je služba pro automatické testování a monitoring webů, dostupnosti, HTTP odpovědí, SSL a dalších vlastností produkčních webů.