Polityka bezpieczeństwa treści

Polityka bezpieczeństwa treści (CSP) to nagłówek odpowiedzi HTTP (i odpowiednik metatagu), który informuje przeglądarkę, które źródła mogą ładować zasoby, które skrypty wbudowane mogą być uruchamiane i gdzie należy wysyłać raporty o naruszeniach. Dobrze skonfigurowany CSP radykalnie zmniejsza wpływ luk w zabezpieczeniach związanych z iniekcjami; źle skonfigurowana zapewnia fałszywą pewność przy niewielkiej rzeczywistej ochronie.

Co kontroluje CSP

Zasada składa się z dyrektyw, z których każda określa dozwolone źródła dla typu zasobu:

• script-src — źródła JavaScript mogą ładować i wykonaj
• style-src — źródła CSS
• img-src — źródła obrazów
• connect-src — XHR, fetch, WebSocket targets
• font-src — źródła czcionek
• media-src — źródła audio i wideo
• frame-src — co można załadować iframes
• frame-ancestors — co może obramować tę stronę (zastępuje opcje X-Frame)
• form-action — gdzie można przesyłać formularze
• base-uri — jakie mogą być adresy URL ustaw jako base
• upgrade-insecure-requests — automatyczna aktualizacja HTTP do HTTPS
• default-src — rezerwa dla nieokreślonych dyrektyw

A rozsądny start polityka

Polityka bezpieczeństwa treści:
  default-src 'self';
  script-src 'self' 'nonce-randomBase64Value';
  style-src „self” „niebezpieczne-inline”;
  img-src Dane własne: https:;
  connect-src „self” https://api.example.com;
  przodkowie ramek „brak”;
  podstawa-uri „ja”;
  forma-akcja „ja”;
  report-uri https://example.com/csp-reports

Ta zasada mówi: domyślnie ładuj tylko z tego samego źródła, skrypty muszą mieć to samo pochodzenie lub zawierać pasującą wartość nonce, nie wolno osadzać w ramkach iframe z innych witryn itp. Podejście oparte na nonce zapobiega większości wbudowanych skryptów XSS, jednocześnie zezwalając na legalne skrypty wbudowane, które serwer emituje z poprawnymi nonce.

Nonces vs hashe vs whitelists

Trzy sposoby zezwalania na określone skrypty inline:

• Oparte na nonce. Serwer generuje nową losową wartość nonce na żądanie i dołącza ją do CSP oraz do każdego dozwolonego skryptu inline. Ścisłe i dynamiczne, zalecane w przypadku nowych wdrożeń.
• Oparte na hashu. CSP określa skróty SHA dozwolonych skryptów wbudowanych. Przeglądarka miesza skrypty wbudowane i porównuje. Działa w przypadku skryptów statycznych, których zawartość się nie zmienia.
• Biała lista źródeł. Zezwalaj na skrypty z określonych domen zewnętrznych. Łatwe, ale stwarza duże obszary ataku — jeśli domena znajdująca się na białej liście zostanie naruszona lub zawiera otwarte przekierowania, zasada zostaje ominięta.

Słowo kluczowe strict-dynamic (dodane w CSP 3) dodatkowo ogranicza skrypty: tylko skrypty niedozwolone mogą same ładować inne skrypty, przerywając typowe łańcuchy XSS.

Kult cargo anti-pattern

Wiele witryn wdraża CSP z unsafe-inline i unsafe-eval w script-src, aby uniknąć uszkodzenia istniejącego kodu. Zasadniczo nie jest to w ogóle CSP — chodzi o to, aby uniemożliwić uruchamianie wbudowanych skryptów, a unsafe-inline usuwa tę ochronę. Witryny z tą konfiguracją mają nagłówki CSP bez korzyści CSP.

Ścieżka do rzeczywistej wartości CSP: usuń unsafe-inline, zrefaktoryzuj kod, aby używać wartości jednorazowych lub skrótów, i zajmuj się naruszeniami jeden po drugim. Bolesne, ale realne.

Tryb tylko do raportowania

CSP można wdrożyć w trybie tylko do raportów — przeglądarka zgłasza naruszenia skonfigurowanego URI, ale ich nie egzekwuje. Przydatne do testowania nowej polityki pod kątem rzeczywistego ruchu bez zakłócania działania witryny:

Content-Security-Policy-Report-Only: ...

Wdrożenie standardowe: wdrożenie w trybie tylko do raportowania, zbieranie naruszeń przez kilka tygodni, naprawianie uzasadnionych, przejście do trybu egzekwowania. W tym cyklu iteracji wiele dużych witryn wdraża CSP przez wiele miesięcy.

CSP i XSS

Główna korzyść: nawet jeśli wstrzyknięcie XSS się powiedzie, wstrzyknięty skrypt nie będzie mógł zostać uruchomiony, jeśli nie ma ważnej wartości jednorazowej. Na stronę trafia ładunek atakującego; przeglądarka odmawia jego wykonania. Luka w zabezpieczeniach jest nadal obecna, ale jej wpływ został radykalnie ograniczony.

Nie zastępuje to naprawy XSS — to głęboka obrona. Obie warstwy powinny być obecne.

Obsługa przeglądarek CSP

Wszystkie główne przeglądarki od 2016 roku. Funkcje CSP 3 (nonces, strict-dynamic, hashe) mają szerokie wsparcie. Pozostałe luki dotyczą obsługi przypadków brzegowych — interakcja ramek-przodków z opcjami X-Frame, różne zachowanie report-uri w porównaniu z report-to, specyficzne dla przeglądarki dziwactwa w raportowaniu błędów.

Złożoność operacyjna

Wdrożenie CSP w świecie rzeczywistym jest trudniejsze, niż się wydaje:

• Tpotrzebowanie skryptów innych firm (analiza, reklamy, monitorowanie) znajdować się w zasadach lub zawieść
• Inline procedury obsługi zdarzeń (onclick="...") naruszają CSP, chyba że wyraźnie na to zezwolono
• Jednostronicowe aplikacje z zawartością dynamiczną wymagają ostrożnej obsługi nonce
• Rozszerzenia przeglądarki mogą czasami wstrzykiwać treść naruszającą CSP, generując noise
• Różne zespoły mogą potrzebować różnych fragmentów CSP; łączenie zasad nie jest trywialne

Wiele witryn, które powinny mieć CSP, tego nie robi, ponieważ koszty operacyjne wydają się wyższe niż postrzegane korzyści w zakresie bezpieczeństwa. Koszt jest realny; korzyść jest również realna, ale niewidoczna (nie widać ataków, które nie miały miejsca).