CSP dokáže omezit útoky typu Cross-site scripting (XSS) a data injection, tím že prohlížeči určíte pravidla pro načítání externího obsahu – externí obrázky, skripty, stránky vložené přes iframe apod.
Cross-domain script include
Během zkoumání zdrojového kódu aplikace můžete detekovat výskyt zranitelnosti Cross-domain script include. Tato zranitelnost vzniká díky volání externích skriptů, velmi často se jedná skripty pro statistiky, monitoring atd.
V případě, že webová aplikace načítá obsah z externích skriptů, je tento skript spouštěn v prohlížeči uživatele ve stejném bezpečnostním kontextu jako ostatní skripty webové aplikace. Skript má stejné možnosti, přístupy a práva. Pokud dojde ke kompromitaci externího skriptu, potenciální útočník může původní kód nahradit vlastním a skrze skript útočit na aplikaci.
Hrozí zde nebezpečí modifikace aplikace, odcizení citlivých informací, odcizení cookie a session ID atd. Riziko je velmi podobné útoku typu Cross-Site Scripting (XSS).
Rozhodli jste se vaši webovou aplikaci zabezpečit pomocí zásad CSP (Content Security Policy).
Výborně!
Kde začít?
Když už máte stávající aplikaci začněte na stránce s nastavením CSP s default-src 'none' a zkontrolujte zda se něco nerozbilo.
Postupně přidávejte jednotlivé sekce webu a kontrolujte, jestli vaše aplikace funguje. Přidáním např. script-src 'self' namísto default-src 'self' si uvědomíte, jaké prostředky vaše aplikace skutečně používá a zda jsou skutečně potřebné.
Nejspíše objevíte, že tu a tam spoléháte na nějaké závislosti JavaScriptu. Víte opravdu, co dělají? Co takhle přesunout blok kódu pro sledování Google Analytics do samostatného JS-souboru a sledovat inicializaci sami.
V mnoha reálných scénářích se to snáze řekne, než udělá, abyste měli skutečně přísnou politiku CSP.
Může vám také pomoct nástroj csp-evaluator.withgoogle.com
Ale není to nemožné! Někdy jsme nuceni povolit některé inline CSS a možná i inline JavaScript kvůli frameworkům nebo platformám, které jsou mimo náš dosah nebo kontrolu. Příkladem může být situace, kdy se spoléháme na CMS nebo jinou platformu s uživatelským rozhraním. Publikační platforma se může spoléhat na inline JavaScript, aby poskytla určité rozhraní pro editory. Jedním z řešení tohoto scénáře je mít různé politiky CSP založené na různých částech řešení. Můžete mít přísné zásady pro všechny veřejné klienty (externí uživatele), ale povolit některá zvláštní pravidla, pokud jste například přihlášeným editorem. Ať to však není výmluva! Pokud máte v některých částech volnější politiku, měli byste mít další opatření, která zajistí, že riziko jejího zneužití bude co nejmenší.
Uvědomte si také, že není možné povolit "unsafe-inline" pouze pro konkrétní externí zdroj. Pokud povolíte "unsafe-inline", vztahuje se to vlastně na všechny prostředky, které jsou pro danou část CSP povoleny. Musíte si položit otázku: Opravdu potřebuji tento kus kódu nebo tento doplněk, který mě nutí otevřít svou aplikaci, aby byla zranitelnější vůči útokům? Moje zkušenost je taková, že pokud se jako vývojář snažíte dodržovat přísné zásady (například nepoužívat inline JS), donutí vás to více přemýšlet o svém kódu a učinit ho bezpečnějším.