CSP (Content Security Policy)

CSP (Content Security Policy) to mechanizm, w którym witryna przekazuje przeglądarce zestaw instrukcji ograniczających to, co kod strony może robić ^[1]. Najważniejszym zastosowaniem jest kontrola tego, jakie zasoby, przede wszystkim skrypty JavaScript, dokument może wczytać, co stanowi obronę przed XSS ^[1]. OWASP opisuje politykę CSP jako skuteczną drugą warstwę ochrony przed różnymi podatnościami, zwłaszcza XSS ^[2]. Polityka CSP nie usuwa podatności w kodzie serwera; ogranicza skutki jej wykorzystania w przeglądarce.

Jak działa

Serwer wysyła politykę w nagłówku odpowiedzi HTTP Content-Security-Policy ^[1]. Można ją też umieścić w elemencie meta, ale ta droga ma ograniczenia: nie obsługuje między innymi dyrektyw dotyczących osadzania w ramkach ani raportowania ^[2]. Polityka składa się z dyrektyw rozdzielonych średnikami; każda ma nazwę i listę dozwolonych źródeł ^[1].

Content-Security-Policy: default-src 'self'; img-src 'self' example.com

Przeglądarka porównuje każde żądanie zasobu z polityką. Jeśli skrypt, styl albo obrazek pochodzi spoza listy, nie zostanie wczytany. Jeśli polityka zawiera dyrektywę default-src albo script-src, skrypty w linii, atrybuty obsługi zdarzeń i adresy javascript: nie wykonają się bez dodatkowego oznaczenia ^[1]. Tak samo blokowane są eval() i podobne funkcje ^[1]. Wstrzyknięty przez atakującego fragment kodu nie ma właściwego oznaczenia, więc przeglądarka go odrzuca.

Wdrożenie polityki zwykle przebiega etapami, co pokazuje schemat poniżej.

RYS. 1Wdrażanie polityki CSP

Odmiany

MDN wyróżnia dwa podejścia do kontroli skryptów ^[1]. Polityka oparta na liście dozwolonych domen wymienia serwery, z których wolno ładować skrypty. Polityka ścisła (strict CSP) opiera się na jednorazowych wartościach albo skrótach kryptograficznych ^[1]. OWASP ocenia podejście ścisłe jako łatwiejsze we wdrożeniu i trudniejsze do obejścia niż listy dozwolonych domen ^[2].

Nonce musi być nieprzewidywalny i nowy przy każdej odpowiedzi, bo inaczej atakujący mógłby go skopiować do własnego skryptu. MDN nazywa nonce zalecanym sposobem ograniczania ładowania elementów script i style ^[1]. Słowo kluczowe 'unsafe-inline' dopuszcza wszystkie skrypty w linii i według MDN niweczy sens polityki ^[1].

Poza skryptami CSP obejmuje inne dyrektywy. frame-ancestors określa, które dokumenty mogą osadzić stronę w ramce, i jest elastycznym następcą nagłówka X-Frame-Options ^[1]; to podstawowa ochrona przed clickjacking. upgrade-insecure-requests każe przeglądarce zamieniać żądania HTTP na HTTPS, co pomaga usunąć mixed content, ale według MDN nie zastępuje nagłówka HSTS ^[1].

W WordPressie

WordPress wypisuje na stronie wiele skryptów w linii, a wtyczki i motywy dokładają własne, często z zewnętrznych serwerów. Z tego powodu polityka CSP dla witryny WordPress zwykle wymaga długiego etapu testów w trybie raportowania. Nagłówek ustawia się w konfiguracji serwera, na przykład w pliku .htaccess, w konfiguracji Nginx albo w kodzie wtyczki.

Od wersji 5.7 rdzeń ma funkcje wp_get_script_tag(), wp_print_script_tag(), wp_get_inline_script_tag() i wp_print_inline_script_tag() ^[5]. Pozwalają one dodawać do znaczników skryptów własne atrybuty, w tym nonce, i według zapowiedzi tworzą infrastrukturę pod zgodność z CSP w rdzeniu, wtyczkach i motywach ^[5]. Atrybuty można zmieniać filtrem wp_script_attributes ^[5]. Zapowiedź przypomina, że przy ścisłej polityce każdy element script musi mieć atrybut nonce zgodny z wartością w polityce ^[5]. Wtyczka, która wypisuje skrypt bez tych funkcji, pominie nonce i jej skrypt zostanie zablokowany.

Przykładowa polityka ścisła wysyłana przez serwer wygląda tak; wartość nonce musi być generowana na nowo przy każdym żądaniu.

Content-Security-Policy: script-src 'nonce-R4nd0mWart0sc' 'strict-dynamic'; object-src 'none'; base-uri 'none'

Zagrożenia i skutki

Brak polityki CSP nie jest sam w sobie podatnością, ale oznacza, że każdy błąd XSS w motywie lub wtyczce działa w pełnym zakresie. Wstrzyknięty skrypt może wtedy wczytywać kod z dowolnego serwera, co wykorzystuje między innymi web skimming w sklepach internetowych.

Źle napisana polityka daje fałszywe poczucie ochrony. Obecność 'unsafe-inline' w script-src wyłącza najważniejszą ochronę przed skryptami w linii ^[1]. OWASP ostrzega też, że CSP nie powinna być jedynym mechanizmem obrony przed XSS ^[2]. MDN podkreśla, że polityka nie zastępuje czyszczenia danych wejściowych i strona powinna stosować oba środki jednocześnie ^[1]. Zbyt restrykcyjna polityka potrafi z kolei zablokować legalne skrypty, na przykład formularz płatności albo statystyki.

Jak się bronić

• Najpierw usuwać przyczyny XSS: escapowanie danych przy wyjściu i sanityzacja danych wejściowych. CSP jest drugą warstwą ^[2].
• Zaczynać od nagłówka Content-Security-Policy-Report-Only. Polityka nie jest wtedy egzekwowana, a naruszenia trafiają do wskazanego punktu raportowania ^[1]. Polityki w tym trybie nie da się dostarczyć w elemencie meta ^[1].
• Preferować politykę ścisłą z nonce lub skrótami zamiast długich list domen ^[2].
• Ustawić object-src 'none' i base-uri 'none', jak w przykładowej polityce ścisłej MDN ^[1], oraz frame-ancestors dla ochrony przed osadzaniem w ramkach.
• Traktować CSP jako część szerszego zestawu nagłówków bezpieczeństwa HTTP i przeglądać politykę po każdej zmianie wtyczek.

Historia i przykłady

Standard rozwija grupa robocza W3C ds. bezpieczeństwa aplikacji webowych ^[4]. Sekurak w artykule z 3 lutego 2014 roku podał, że autorami specyfikacji są Adam Barth i Mike West z Google oraz Dan Veditz z Mozilla Foundation, a za aktualną wersję uznawał wtedy CSP 1.1 ^[6]. Druga wersja, Content Security Policy Level 2, ma status rekomendacji W3C z 15 grudnia 2016 roku; dokument zaznacza, że prace nad nią zakończono w 2014 roku ^[4]. Trzecia wersja, Level 3, jest w dniu aktualizacji tego artykułu projektem roboczym W3C z 16 września 2026 roku ^[3]. Definiuje ona między innymi nagłówek Content-Security-Policy-Report-Only i dyrektywę frame-ancestors ^[3]. W 2014 roku Sekurak szacował, że CSP obsługuje około 60% zainstalowanych przeglądarek ^[6].