Content Security Policy (CSP): Kompleksowy przewodnik po zapobieganiu XSS

W dzisiejszym krajobrazie cyfrowym bezpieczeństwo sieci jest sprawą nadrzędną. Ataki Cross-Site Scripting (XSS) pozostają powszechnym i niebezpiecznym zagrożeniem dla aplikacji internetowych na całym świecie. Content Security Policy (CSP) to potężny nagłówek odpowiedzi HTTP, który zapewnia dodatkową warstwę bezpieczeństwa, pomagając zmniejszyć ryzyko luk XSS. Ten przewodnik zawiera obszerne omówienie CSP, jego implementacji i najlepszych praktyk ochrony aplikacji internetowych przed atakami XSS.

Co to jest Cross-Site Scripting (XSS)?

Cross-Site Scripting (XSS) to rodzaj ataku polegającego na wstrzykiwaniu, w którym złośliwe skrypty są wstrzykiwane do zazwyczaj nieszkodliwych i zaufanych stron internetowych. Ataki XSS występują, gdy atakujący wykorzystuje aplikację internetową do wysłania złośliwego kodu, zazwyczaj w postaci skryptu po stronie przeglądarki, do innego użytkownika końcowego. Błędy, które umożliwiają powodzenie tych ataków, są dość powszechne i występują wszędzie tam, gdzie aplikacja internetowa wykorzystuje dane wejściowe od użytkownika w generowanych przez siebie danych wyjściowych bez ich walidacji lub kodowania.

Istnieją trzy główne rodzaje ataków XSS:

• Zapisane (trwałe) XSS: Złośliwy skrypt jest trwale przechowywany na serwerze docelowym (np. w bazie danych, forum wiadomości, dzienniku odwiedzin, polu komentarza itp.). Kiedy użytkownik odwiedza dotkniętą stronę, zapisany skrypt jest wykonywany.
• Odbite (nietrwałe) XSS: Złośliwy skrypt jest odbijany od serwera internetowego, na przykład w komunikacie o błędzie, wyniku wyszukiwania lub innej odpowiedzi, która zawiera część lub całość danych wejściowych wysłanych do serwera w ramach żądania. Użytkownik musi zostać nakłoniony do kliknięcia złośliwego linku lub przesłania formularza zawierającego złośliwy skrypt.
• XSS oparty na DOM: Podatność tkwi w samym kodzie po stronie klienta. Złośliwy skrypt jest wykonywany, ponieważ środowisko DOM przeglądarki jest manipulowane w celu włączenia skryptu atakującego.

Ataki XSS mogą mieć poważne konsekwencje, w tym:

• Kradzież danych uwierzytelniających użytkowników (ciasteczek, tokenów sesji).
• Defacement stron internetowych.
• Przekierowanie użytkowników na złośliwe strony.
• Instalacja złośliwego oprogramowania.
• Uzyskanie nieautoryzowanego dostępu do poufnych danych.

Co to jest Content Security Policy (CSP)?

Content Security Policy (CSP) to dodatkowa warstwa bezpieczeństwa, która pomaga wykrywać i łagodzić pewne rodzaje ataków, w tym ataki Cross-Site Scripting (XSS) i ataki polegające na wstrzykiwaniu danych. CSP jest implementowane za pomocą nagłówka odpowiedzi HTTP, który pozwala kontrolować zasoby (np. skrypty, arkusze stylów, obrazy, czcionki, ramki), które przeglądarka może ładować dla danej strony. Definiując ścisłą politykę CSP, można znacznie zmniejszyć powierzchnię ataku aplikacji internetowej i utrudnić atakującym wstrzykiwanie złośliwego kodu.

CSP działa poprzez definiowanie białej listy źródeł, z których przeglądarka może ładować zasoby. Dowolny zasób załadowany ze źródła, które nie jest jawnie dozwolone w CSP, zostanie zablokowany przez przeglądarkę. Zapobiega to wykonywaniu nieautoryzowanych skryptów i zmniejsza ryzyko ataków XSS.

Jak działa CSP: dyrektywy i źródła

CSP jest konfigurowane za pomocą serii dyrektyw, z których każda określa politykę dla określonego typu zasobu. Każda dyrektywa składa się z nazwy, po której następuje lista dozwolonych źródeł. Oto niektóre z najczęściej używanych dyrektyw CSP:

• `default-src`: Określa domyślną politykę pobierania zasobów, jeśli inne dyrektywy specyficzne dla zasobów nie są obecne.
• `script-src`: Określa dozwolone źródła kodu JavaScript.
• `style-src`: Określa dozwolone źródła arkuszy stylów (CSS).
• `img-src`: Określa dozwolone źródła obrazów.
• `font-src`: Określa dozwolone źródła czcionek.
• `connect-src`: Określa dozwolone źródła dla żądań sieciowych (np. AJAX, WebSockets).
• `media-src`: Określa dozwolone źródła do ładowania zasobów wideo i audio.
• `object-src`: Określa dozwolone źródła wtyczek, takich jak Flash.
• `frame-src`: Określa dozwolone źródła do osadzania ramek (iframes).
• `base-uri`: Ogranicza adresy URL, które mogą być używane w elemencie <base> dokumentu.
• `form-action`: Ogranicza adresy URL, do których mogą być wysyłane formularze.
• `upgrade-insecure-requests`: Nakazuje przeglądarkom automatyczne uaktualnianie żądań niebezpiecznych (HTTP) do bezpiecznych (HTTPS).
• `block-all-mixed-content`: Zapobiega ładowaniu przez przeglądarkę jakichkolwiek zasobów za pomocą HTTP, gdy strona jest ładowana przez HTTPS.
• `report-uri`: Określa adres URL, na który przeglądarka powinna wysyłać raporty o naruszeniach CSP. Usunięto na rzecz `report-to`.
• `report-to`: Określa nazwany punkt końcowy, na który przeglądarka powinna wysyłać raporty o naruszeniach CSP.

Często używane wartości źródeł obejmują:

• `*`: Pozwala na zasoby z dowolnego źródła (niezalecane w środowiskach produkcyjnych).
• `'self'`: Pozwala na zasoby z tego samego pochodzenia (schemat, host i port) co chroniony dokument.
• `'none'`: Zabrania ładowania zasobów z jakiegokolwiek źródła.
• `data:`: Pozwala na ładowanie zasobów za pomocą schematu `data:` (np. osadzone obrazy).
• `'unsafe-inline'`: Pozwala na użycie wbudowanych skryptów JavaScript i stylów CSS (zdecydowanie odradzane).
• `'unsafe-eval'`: Pozwala na użycie `eval()` i podobnych funkcji (zdecydowanie odradzane).
• `'strict-dynamic'`: Określa, że zaufanie jawnie przyznane skryptowi obecnemu w znacznikach, poprzez dołączenie do niego nonce lub hasha, powinno być propagowane do wszystkich skryptów załadowanych przez ten główny skrypt.
• `'nonce-'`: Pozwala na skrypty lub style z pasującym atrybutem nonce.
• `'sha256-'`, `'sha384-'`, `'sha512-'`: Pozwala na skrypty lub style z pasującym hashem SHA.
• `https://example.com`: Pozwala na zasoby z określonej domeny.

Implementacja CSP

CSP można zaimplementować na dwa główne sposoby:

1. Nagłówek HTTP: Preferowaną metodą jest skonfigurowanie serwera internetowego tak, aby wysyłał nagłówek odpowiedzi HTTP `Content-Security-Policy`. Pozwala to na definiowanie CSP dla każdej strony lub zasobu na Twojej stronie internetowej.
2. Tag <meta>: CSP można również zdefiniować za pomocą tagu <meta> w sekcji <head> Twojego dokumentu HTML. Ta metoda jest jednak mniej elastyczna i ma ograniczenia w porównaniu do użycia nagłówka HTTP. Na przykład dyrektywy `frame-ancestors`, `sandbox` i `report-uri` nie mogą być używane w meta tagach HTML.

Używanie nagłówka HTTP

Aby zaimplementować CSP za pomocą nagłówka HTTP, musisz skonfigurować swój serwer internetowy tak, aby uwzględniał nagłówek `Content-Security-Policy` w swoich odpowiedziach. Konkretne kroki konfiguracji będą się różnić w zależności od używanego serwera internetowego.

Oto przykłady dla popularnych serwerów internetowych:

• Apache: Dodaj następującą linię do swojego pliku `.htaccess` lub konfiguracji wirtualnego hosta:

            Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://example.com; img-src 'self' data:;"
            

              
                Copy
              
            
          

• Nginx: Dodaj następującą linię do konfiguracji swojego bloku serwera:

            add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://example.com; img-src 'self' data:";
            

              
                Copy
              
            
          

• Node.js (Express): Użyj pośrednika do ustawienia nagłówka:

            app.use(function(req, res, next) {
  res.setHeader("Content-Security-Policy", "default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://example.com; img-src 'self' data:");
  next();
});
            

              
                Copy
              
            
          

Używanie tagu <meta>

Aby zaimplementować CSP za pomocą tagu <meta>, dodaj następujący tag do sekcji <head> swojego dokumentu HTML:

            <meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://example.com; img-src 'self' data:";>
            

              
                Copy
              
            
          

Ważne uwagi:

• Atrybut `http-equiv` musi być ustawiony na "Content-Security-Policy".
• Atrybut `content` zawiera dyrektywy CSP.
• Pamiętaj o ograniczeniach dotyczących używania tagów <meta>, jak wspomniano wcześniej.

Przykłady CSP

Oto kilka przykładów CSP wraz z wyjaśnieniami:

1. Podstawowa CSP:

            Content-Security-Policy: default-src 'self';
            

              
                Copy
              
            
          

Ta polityka pozwala na zasoby tylko z tego samego pochodzenia.

2. Pozwolenie na skrypty z określonej domeny:

            Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com;
            

              
                Copy
              
            
          

Ta polityka pozwala na zasoby z tego samego pochodzenia i skrypty z `https://example.com`.

3. Pozwolenie na style z CDN:

            Content-Security-Policy: default-src 'self'; style-src 'self' https://cdn.example.com;
            

              
                Copy
              
            
          

Ta polityka pozwala na zasoby z tego samego pochodzenia i style z `https://cdn.example.com`.

4. Pozwolenie na obrazy z dowolnego źródła:

            Content-Security-Policy: default-src 'self'; img-src *;
            

              
                Copy
              
            
          

Ta polityka pozwala na zasoby z tego samego pochodzenia i obrazy z dowolnego źródła (niezalecane dla produkcji).

5. Raportowanie naruszeń CSP:

            Content-Security-Policy: default-src 'self'; report-uri /csp-report-endpoint;
            

              
                Copy
              
            
          

Ta polityka pozwala na zasoby z tego samego pochodzenia i wysyła raporty o naruszeniach na adres `/csp-report-endpoint`. Zaleca się używanie `report-to` zamiast `report-uri`.

6. Używanie `report-to` i `report-uri` razem dla kompatybilności:

            Content-Security-Policy: default-src 'self'; report-uri /csp-report-endpoint; report-to csp-endpoint;
Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report-endpoint; report-to csp-endpoint;
Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"/csp-report-endpoint"}]}
            

              
                Copy
              
            
          

Ten przykład pokazuje ustawienie zarówno punktu końcowego `report-uri` (dla starszych przeglądarek), jak i `report-to`, wraz z konfiguracją samego nagłówka `Report-To`. Upewnij się, że Twój serwer poprawnie obsługuje nagłówek `Report-To`, ustawiając prawidłowo `group`, `max_age` i `endpoints`.

7. Używanie Nonce dla skryptów wbudowanych:

            Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-rAnd0mN0nc3Str1nG';
            

              
                Copy
              
            
          

Ta polityka pozwala na zasoby z tego samego pochodzenia i skrypty wbudowane z pasującym atrybutem nonce.

            <script nonce="rAnd0mN0nc3Str1nG">
  // Twój kod skryptu wbudowanego tutaj
</script>
            

              
                Copy
              
            
          

CSP w trybie raportowania

CSP można zaimplementować w dwóch trybach:

• Tryb egzekwowania: Przeglądarka blokuje zasoby, które naruszają CSP.
• Tryb raportowania: Przeglądarka raportuje naruszenia CSP do określonego punktu końcowego, nie blokując żadnych zasobów.

Tryb raportowania jest przydatny do testowania i dostrajania CSP przed jego egzekwowaniem. Aby włączyć tryb raportowania, użyj nagłówka HTTP `Content-Security-Policy-Report-Only` zamiast nagłówka `Content-Security-Policy`.

Przykład:

            Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report-endpoint;
            

              
                Copy
              
            
          

Ta konfiguracja wyśle raporty do `/csp-report-endpoint` bez blokowania żadnych zasobów.

Najlepsze praktyki wdrażania CSP

Oto kilka najlepszych praktyk skutecznego wdrażania CSP:

1. Zacznij od ścisłej polityki: Zacznij od restrykcyjnej polityki, która zezwala na zasoby tylko z tego samego pochodzenia, a następnie stopniowo ją rozluźniaj w miarę potrzeb.
2. Używaj Nonce lub Hashy dla skryptów i stylów wbudowanych: Unikaj używania `'unsafe-inline'` i używaj nonce lub hashy, aby zezwolić na określone skrypty i style wbudowane.
3. Unikaj `'unsafe-eval'`: Jeśli to możliwe, unikaj używania `'unsafe-eval'`, ponieważ może ona wprowadzać ryzyko bezpieczeństwa. Rozważ alternatywne podejścia do dynamicznego wykonywania kodu.
4. Używaj HTTPS: Upewnij się, że wszystkie zasoby są ładowane przez HTTPS, aby zapobiec atakom typu man-in-the-middle. Użyj dyrektywy `upgrade-insecure-requests`, aby automatycznie uaktualniać niebezpieczne żądania.
5. Monitoruj naruszenia CSP: Skonfiguruj punkt końcowy raportowania, aby monitorować naruszenia CSP i identyfikować potencjalne problemy z bezpieczeństwem.
6. Dokładnie przetestuj swoje CSP: Przetestuj swoje CSP w różnych przeglądarkach i środowiskach, aby upewnić się, że działa zgodnie z oczekiwaniami.
7. Iteruj i udoskonalaj: Implementacja CSP jest procesem iteracyjnym. Ciągle monitoruj i udoskonalaj swoje CSP w miarę rozwoju aplikacji.
8. Rozważ dyrektywę `strict-dynamic`: Użyj `strict-dynamic`, aby zmniejszyć złożoność CSP poprzez propagowanie zaufania do skryptów ładowanych przez zaufane skrypty.

Narzędzia do CSP

Kilka narzędzi może pomóc w generowaniu, testowaniu i monitorowaniu CSP:

• Generatory CSP: Narzędzia online, które generują dyrektywy CSP na podstawie zasobów Twojej witryny.
• Narzędzia dla deweloperów przeglądarek: Większość nowoczesnych przeglądarek oferuje narzędzia dla deweloperów, które mogą pomóc w analizie naruszeń CSP.
• Usługi monitorowania CSP: Usługi, które zbierają i analizują raporty o naruszeniach CSP.

CSP a frameworki/biblioteki

Podczas korzystania z frameworków i bibliotek ważne jest prawidłowe skonfigurowanie CSP, aby zapewnić kompatybilność i zapobiec problemom z bezpieczeństwem. Oto kilka uwag:

• Frameworki JavaScript (np. React, Angular, Vue.js): Te frameworki często używają stylów wbudowanych lub generowania kodu na żywo, co może wymagać specjalnych konfiguracji CSP (np. nonce, hashe, `'unsafe-eval'`).
• Frameworki CSS (np. Bootstrap, Tailwind CSS): Te frameworki mogą używać stylów wbudowanych lub zewnętrznych arkuszy stylów, które muszą być dozwolone w Twojej CSP.
• Biblioteki stron trzecich: Upewnij się, że wszelkie używane przez Ciebie biblioteki stron trzecich są zgodne z Twoją CSP i nie wprowadzają luk w zabezpieczeniach.

CSP a CDN (sieci dostarczania treści)

CDN są powszechnie używane do hostowania zasobów statycznych, takich jak pliki JavaScript, arkusze stylów CSS i obrazy. Aby zezwolić na zasoby z CDN w Twojej CSP, musisz jawnie umieścić domeny CDN na białej liście.

Przykład:

            Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.jsdelivr.net; style-src 'self' https://cdnjs.cloudflare.com;
            

              
                Copy
              
            
          

Ta polityka zezwala na skrypty z jsDelivr i style z cdnjs Cloudflare.

Częste błędy CSP, których należy unikać

Oto kilka częstych błędów CSP, których należy unikać:

• Używanie `*` jako źródła: Pozwolenie na zasoby z dowolnego źródła może zniweczyć korzyści płynące z CSP.
• Używanie `'unsafe-inline'` i `'unsafe-eval'` bez uzasadnienia: Te dyrektywy mogą wprowadzać ryzyko bezpieczeństwa i należy ich unikać, jeśli to możliwe.
• Niemonitorowanie naruszeń CSP: Niezastosowanie się do monitorowania naruszeń CSP może uniemożliwić identyfikację i rozwiązanie problemów z bezpieczeństwem.
• Niedokładne testowanie CSP: Niewystarczające testowanie może prowadzić do nieoczekiwanych zachowań i luk w zabezpieczeniach.
• Błędne konfigurowanie Nonce i Hashy: Błędnie skonfigurowane Nonce i Hashe mogą uniemożliwić ładowanie legalnych skryptów i stylów.

Zaawansowane koncepcje CSP

Poza podstawami, kilka zaawansowanych koncepcji CSP może dodatkowo wzmocnić Twoje bezpieczeństwo sieci:

• Dyrektywa `frame-ancestors`: Określa dozwolonych rodziców, którzy mogą osadzać ramkę (iframe) na Twojej stronie. Chroni przed atakami clickjacking.
• Dyrektywa `sandbox`: Włącza piaskownicę dla żądanego zasobu, stosując ograniczenia jego możliwości (np. zapobieganie wykonywaniu skryptów, wysyłaniu formularzy).
• Dyrektywa `require-sri-for`: Wymaga Subresource Integrity (SRI) dla skryptów lub stylów ładowanych z zewnętrznych źródeł. SRI zapewnia, że pliki nie zostały naruszone.
• API Trusted Types: Pomaga zapobiegać atakom XSS opartym na DOM poprzez egzekwowanie bezpieczeństwa typów dla ujść DOM.

Przyszłość CSP

CSP stale ewoluuje, aby sprostać nowym wyzwaniom w zakresie bezpieczeństwa. Przyszłe rozwój mogą obejmować:

• Ulepszone wsparcie przeglądarek: Ciągłe ulepszenia wsparcia przeglądarek dla funkcji CSP.
• Nowe dyrektywy i funkcje: Wprowadzenie nowych dyrektyw i funkcji w celu rozwiązania pojawiających się zagrożeń bezpieczeństwa.
• Integracja z narzędziami bezpieczeństwa: Główniejsza integracja z narzędziami i platformami bezpieczeństwa w celu automatyzacji zarządzania i monitorowania CSP.

Wnioski

Content Security Policy (CSP) to potężne narzędzie do łagodzenia ataków XSS i zwiększania bezpieczeństwa sieci. Definiując ścisłą politykę CSP, możesz znacznie zmniejszyć powierzchnię ataku swojej aplikacji internetowej i chronić użytkowników przed złośliwym kodem. Skuteczna implementacja CSP wymaga starannego planowania, dokładnego testowania i ciągłego monitorowania. Przestrzegając najlepszych praktyk przedstawionych w tym przewodniku, możesz wykorzystać CSP do poprawy postawy bezpieczeństwa swoich aplikacji internetowych i ochrony swojej obecności online w globalnym ekosystemie cyfrowym.

Pamiętaj, aby regularnie przeglądać i aktualizować swoją CSP, aby dostosować się do ewoluujących zagrożeń bezpieczeństwa i zapewnić ochronę swoich aplikacji internetowych.