Nagłówki bezpieczeństwa WWW: Content Security Policy i wykonywanie kodu JavaScript

W dzisiejszym złożonym cyfrowym krajobrazie bezpieczeństwo aplikacji internetowych jest sprawą nadrzędną. Jedną z najskuteczniejszych metod obrony przed różnymi atakami, zwłaszcza Cross-Site Scripting (XSS), jest stosowanie nagłówków bezpieczeństwa WWW. Wśród nich Content Security Policy (CSP) wyróżnia się jako potężny mechanizm kontroli zasobów, które przeglądarka może załadować dla danej strony. Ten artykuł stanowi kompleksowy przewodnik po zrozumieniu i skutecznym wdrażaniu CSP w celu ochrony aplikacji internetowych i użytkowników.

Zrozumienie nagłówków bezpieczeństwa WWW

Nagłówki bezpieczeństwa WWW to nagłówki odpowiedzi HTTP, które dostarczają przeglądarce instrukcji, jak ma się zachowywać podczas obsługi określonych typów treści. Są one kluczowym elementem strategii obrony w głąb (defense-in-depth), współpracując z innymi środkami bezpieczeństwa w celu łagodzenia ryzyka.

Niektóre z najczęściej używanych nagłówków bezpieczeństwa WWW to:

• Content Security Policy (CSP): Kontroluje zasoby, które agent użytkownika (przeglądarka) może załadować.
• HTTP Strict Transport Security (HSTS): Wymusza na przeglądarkach używanie protokołu HTTPS.
• X-Frame-Options: Chroni przed atakami typu Clickjacking.
• X-Content-Type-Options: Zapobiega podatnościom związanym z MIME-sniffing.
• Referrer-Policy: Kontroluje, ile informacji o stronie odsyłającej powinno być dołączanych do żądań.
• Permissions-Policy (dawniej Feature-Policy): Umożliwia szczegółową kontrolę nad funkcjami przeglądarki.

Ten artykuł skupia się głównie na Content Security Policy (CSP) i jej wpływie na wykonywanie kodu JavaScript.

Czym jest Content Security Policy (CSP)?

CSP to nagłówek odpowiedzi HTTP, który pozwala zdefiniować białą listę źródeł, z których przeglądarka może ładować zasoby. Obejmuje to JavaScript, CSS, obrazy, czcionki i inne zasoby. Poprzez jawne zdefiniowanie tych zaufanych źródeł można znacznie zmniejszyć ryzyko ataków XSS, w których złośliwe skrypty są wstrzykiwane na stronę internetową i wykonywane w kontekście przeglądarek użytkowników.

Można myśleć o CSP jak o zaporze sieciowej dla przeglądarki, ale zamiast blokować ruch sieciowy, blokuje ona wykonywanie niezaufanego kodu.

Dlaczego CSP jest ważne dla wykonywania kodu JavaScript?

JavaScript to potężny język, który można wykorzystać do tworzenia dynamicznych i interaktywnych doświadczeń internetowych. Jednak jego elastyczność sprawia również, że jest on głównym celem atakujących. Ataki XSS często polegają na wstrzyknięciu złośliwego kodu JavaScript na stronę internetową, który może być następnie użyty do kradzieży danych uwierzytelniających użytkowników, przekierowywania na strony phishingowe lub zniekształcania witryny.

CSP może skutecznie zapobiegać tym atakom, ograniczając źródła, z których JavaScript może być ładowany i wykonywany. Domyślnie CSP blokuje cały wbudowany JavaScript (kod wewnątrz tagów <script>) oraz JavaScript ładowany z zewnętrznych domen. Następnie selektywnie włącza się zaufane źródła za pomocą dyrektyw CSP.

Dyrektywy CSP: Elementy składowe Twojej polityki

Dyrektywy CSP definiują typy zasobów, które mogą być ładowane, oraz źródła, z których mogą być ładowane. Oto niektóre z najważniejszych dyrektyw:

• default-src: Służy jako domyślna reguła dla innych dyrektyw pobierania. Jeśli określona dyrektywa nie jest zdefiniowana, używana jest default-src.
• script-src: Określa dozwolone źródła dla kodu JavaScript.
• style-src: Określa dozwolone źródła dla arkuszy stylów CSS.
• img-src: Określa dozwolone źródła dla obrazów.
• font-src: Określa dozwolone źródła dla czcionek.
• media-src: Określa dozwolone źródła dla plików audio i wideo.
• object-src: Określa dozwolone źródła dla wtyczek (np. Flash).
• frame-src: Określa dozwolone źródła dla ramek (<frame>, <iframe>).
• connect-src: Określa dozwolone źródła dla żądań sieciowych (np. XMLHttpRequest, Fetch API, WebSockets).
• 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ć przesyłane formularze.
• upgrade-insecure-requests: Nakazuje przeglądarce uaktualnienie wszystkich niezabezpieczonych adresów URL (HTTP) do bezpiecznych adresów URL (HTTPS).
• block-all-mixed-content: Zapobiega ładowaniu przez przeglądarkę jakichkolwiek zasobów przez HTTP, gdy strona jest ładowana przez HTTPS.

Każda dyrektywa może przyjmować różne wyrażenia źródłowe, w tym:

• *: Zezwala na zasoby z dowolnego źródła (generalnie niezalecane).
• 'self': Zezwala na zasoby z tego samego źródła (schemat, host i port) co dokument.
• 'none': Zabrania zasobów ze wszystkich źródeł.
• 'unsafe-inline': Zezwala na użycie wbudowanego JavaScript i CSS (zdecydowanie odradzane).
• 'unsafe-eval': Zezwala na użycie funkcji eval() i pokrewnych (zdecydowanie odradzane).
• 'unsafe-hashes': Zezwala na określone wbudowane procedury obsługi zdarzeń na podstawie ich skrótu SHA256, SHA384 lub SHA512 (używać z ostrożnością).
• data:: Zezwala na identyfikatory URI typu data: (np. obrazy wbudowane zakodowane jako base64).
• https://example.com: Zezwala na zasoby z określonej domeny (i opcjonalnie portu) przez HTTPS.
• *.example.com: Zezwala na zasoby z dowolnej subdomeny example.com.
• nonce-{random-value}: Zezwala na określone skrypty wbudowane lub style, które mają pasujący atrybut nonce (zalecane dla kodu wbudowanego).
• sha256-{hash-value}: Zezwala na określone skrypty wbudowane lub style, które mają pasujący skrót SHA256 (alternatywa dla nonces).

Implementacja CSP: Praktyczne przykłady

Istnieją dwa podstawowe sposoby implementacji CSP:

1. Nagłówek HTTP: Wysłanie nagłówka Content-Security-Policy w odpowiedzi HTTP. Jest to preferowana metoda.
2. Tag <meta>: Użycie tagu <meta> w sekcji <head> dokumentu HTML. Ta metoda ma ograniczenia i generalnie nie jest zalecana.

Użycie nagłówka HTTP

Aby ustawić nagłówek CSP, należy skonfigurować serwer WWW. Dokładne kroki będą się różnić w zależności od serwera (np. Apache, Nginx, IIS).

Oto kilka przykładów nagłówków CSP:

Podstawowe CSP

Ta polityka zezwala tylko na zasoby z tego samego źródła:

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

              
                Copy
              
            
          

Zezwalanie na zasoby z określonych domen

Ta polityka zezwala na JavaScript z https://cdn.example.com i obrazy z https://images.example.net:

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

              
                Copy
              
            
          

Używanie nonce dla skryptów wbudowanych

Ta polityka zezwala na skrypty wbudowane, które mają pasujący atrybut nonce:

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

              
                Copy
              
            
          

W kodzie HTML:

            <script nonce="rAnd0mN0nc3">
 // Twój skrypt wbudowany
</script>
            

              
                Copy
              
            
          

Uwaga: Wartość nonce powinna być generowana losowo dla każdego żądania, aby uniemożliwić atakującym obejście CSP.

Używanie skrótów (hashy) dla skryptów wbudowanych

Ta polityka zezwala na określone skrypty wbudowane na podstawie ich skrótu SHA256:

            Content-Security-Policy: default-src 'self'; script-src 'self' 'sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=';
            

              
                Copy
              
            
          

Aby wygenerować skrót SHA256, można użyć różnych narzędzi online lub narzędzi wiersza poleceń (np. openssl dgst -sha256 -binary input.js | openssl base64).

Użycie tagu <meta>

Chociaż nie jest to zalecane dla złożonych polityk, tag <meta> może być użyty do ustawienia podstawowego CSP. Na przykład:

            <meta http-equiv="Content-Security-Policy" content="default-src 'self';">
            

              
                Copy
              
            
          

Ograniczenia tagu <meta>:

• Nie można go użyć do określenia dyrektywy report-uri.
• Nie jest tak szeroko wspierany jak nagłówek HTTP.
• Jest mniej elastyczny i trudniejszy w zarządzaniu dla złożonych polityk.

Tryb CSP Report-Only (tylko raportowanie)

Przed wdrożeniem CSP w trybie blokującym, zaleca się użycie nagłówka Content-Security-Policy-Report-Only. Pozwala to na monitorowanie wpływu polityki bez faktycznego blokowania jakichkolwiek zasobów. Przeglądarka będzie raportować wszelkie naruszenia na określony adres URL, co pozwala na dostrojenie polityki przed jej wdrożeniem w środowisku produkcyjnym.

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

              
                Copy
              
            
          

Należy skonfigurować punkt końcowy po stronie serwera (np. /csp-report), aby odbierać i przetwarzać raporty CSP. Raporty te są zazwyczaj obiektami JSON, które zawierają informacje o naruszonej dyrektywie, zablokowanym URI i innych istotnych szczegółach.

Częste błędy w CSP i jak ich unikać

Implementacja CSP może być wyzwaniem i łatwo popełnić błędy, które mogą osłabić bezpieczeństwo lub zepsuć działanie strony internetowej. Oto kilka częstych pułapek, których należy unikać:

• Używanie 'unsafe-inline' i 'unsafe-eval': Te dyrektywy w zasadzie wyłączają ochronę oferowaną przez CSP i należy ich unikać, gdy tylko jest to możliwe. Używaj nonce lub skrótów dla skryptów wbudowanych i unikaj używania eval().
• Używanie *: Zezwalanie na zasoby z dowolnego źródła niweczy cel CSP. Bądź jak najbardziej precyzyjny podczas definiowania polityki.
• Niewystarczające testowanie: Zawsze testuj CSP w trybie report-only przed jego wdrożeniem w trybie blokującym. Monitoruj raporty i dostosowuj politykę w razie potrzeby.
• Nieprawidłowa konfiguracja report-uri: Upewnij się, że punkt końcowy report-uri jest poprawnie skonfigurowany do odbierania i przetwarzania raportów CSP.
• Brak aktualizacji CSP: W miarę ewolucji strony internetowej, Twoje CSP może wymagać aktualizacji, aby odzwierciedlić zmiany w zależnościach zasobów.
• Zbyt restrykcyjne polityki: Polityki, które są zbyt restrykcyjne, mogą zepsuć działanie strony i frustrować użytkowników. Znajdź równowagę między bezpieczeństwem a użytecznością.

CSP a biblioteki stron trzecich

Wiele stron internetowych opiera się na bibliotekach i usługach stron trzecich, takich jak sieci CDN, dostawcy analityki i widżety mediów społecznościowych. Podczas wdrażania CSP ważne jest, aby uwzględnić te zależności i upewnić się, że polityka pozwala im poprawnie ładować zasoby.

Oto kilka strategii postępowania z bibliotekami stron trzecich:

• Jawne dodanie do białej listy domen zaufanych dostawców zewnętrznych: Na przykład, jeśli używasz jQuery z sieci CDN, dodaj domenę CDN do dyrektywy script-src.
• Używanie Subresource Integrity (SRI): SRI pozwala zweryfikować, czy pliki ładowane ze źródeł zewnętrznych nie zostały zmodyfikowane. Aby użyć SRI, należy wygenerować kryptograficzny skrót pliku i dołączyć go do tagu <script> lub <link>.
• Rozważenie hostowania bibliotek stron trzecich na własnym serwerze: Daje to większą kontrolę nad zasobami i zmniejsza zależność od zewnętrznych dostawców.

Przykład użycia SRI:

            <script
 src="https://cdn.example.com/jquery.min.js"
 integrity="sha384-vtXRMe3mGCkKsTB9UMvnoknreNzcMRujMQFFSQhtI2zxLlClmHsfq9em6JzhbqQ"
 crossorigin="anonymous"></script>
            

              
                Copy
              
            
          

CSP a aplikacje jednostronicowe (SPA)

Aplikacje SPA często w dużym stopniu polegają na JavaScript i dynamicznym generowaniu kodu, co może utrudnić implementację CSP. Oto kilka wskazówek dotyczących zabezpieczania SPA za pomocą CSP:

• Unikaj używania 'unsafe-eval': Aplikacje SPA często używają silników szablonów lub innych technik, które opierają się na eval(). Zamiast tego rozważ użycie alternatywnych podejść, które nie wymagają eval(), takich jak prekompilowane szablony.
• Używaj nonce lub skrótów dla skryptów wbudowanych: Aplikacje SPA często dynamicznie wstrzykują kod JavaScript. Używaj nonce lub skrótów, aby upewnić się, że wykonywany jest tylko zaufany kod.
• Starannie skonfiguruj dyrektywę connect-src: Aplikacje SPA często wysyłają żądania API do różnych punktów końcowych. Upewnij się, że na białej liście w dyrektywie connect-src znajdują się tylko niezbędne domeny.
• Rozważ użycie frameworka świadomego CSP: Niektóre frameworki JavaScript zapewniają wbudowane wsparcie dla CSP, co ułatwia implementację i utrzymanie bezpiecznej polityki.

CSP a internacjonalizacja (i18n)

Podczas tworzenia aplikacji internetowych dla globalnej publiczności ważne jest, aby wziąć pod uwagę wpływ CSP na internacjonalizację (i18n). Oto kilka czynników, o których należy pamiętać:

• Sieci dostarczania treści (CDN): Jeśli używasz sieci CDN do dostarczania zasobów swojej witryny, upewnij się, że domeny CDN znajdują się na białej liście w Twoim CSP. Rozważ użycie różnych sieci CDN dla różnych regionów w celu optymalizacji wydajności.
• Czcionki zewnętrzne: Jeśli używasz czcionek zewnętrznych (np. Google Fonts), upewnij się, że domeny dostawców czcionek znajdują się na białej liście w dyrektywie font-src.
• Treści zlokalizowane: Jeśli udostępniasz różne wersje swojej witryny dla różnych języków lub regionów, upewnij się, że CSP jest poprawnie skonfigurowane dla każdej wersji.
• Integracje z usługami stron trzecich: Jeśli integrujesz się z usługami stron trzecich, które są specyficzne dla określonych regionów, upewnij się, że domeny tych usług znajdują się na białej liście w Twoim CSP.

Najlepsze praktyki CSP: Perspektywa globalna

Oto kilka ogólnych najlepszych praktyk dotyczących wdrażania CSP, uwzględniając perspektywę globalną:

• Zacznij od restrykcyjnej polityki: Rozpocznij od polityki, która domyślnie wszystko blokuje, a następnie selektywnie włączaj zaufane źródła.
• Najpierw użyj trybu report-only: Przetestuj CSP w trybie report-only przed jego wdrożeniem w trybie blokującym, aby zidentyfikować potencjalne problemy.
• Monitoruj raporty CSP: Regularnie przeglądaj raporty CSP, aby identyfikować potencjalne luki w zabezpieczeniach i udoskonalać swoją politykę.
• Używaj nonce lub skrótów dla skryptów wbudowanych: Unikaj używania 'unsafe-inline' i 'unsafe-eval'.
• Bądź precyzyjny w listach źródeł: Unikaj używania symboli wieloznacznych (*), chyba że jest to absolutnie konieczne.
• Używaj Subresource Integrity (SRI) dla zasobów stron trzecich: Weryfikuj integralność plików ładowanych z sieci CDN.
• Utrzymuj swoje CSP na bieżąco: Regularnie przeglądaj i aktualizuj swoje CSP, aby odzwierciedlało zmiany w Twojej witrynie i zależnościach.
• Edukuj swój zespół: Upewnij się, że Twoi programiści i zespół ds. bezpieczeństwa rozumieją znaczenie CSP i wiedzą, jak je poprawnie wdrożyć.
• Rozważ użycie generatora lub narzędzia do zarządzania CSP: Te narzędzia mogą pomóc w łatwiejszym tworzeniu i utrzymywaniu CSP.
• Dokumentuj swoje CSP: Dokumentuj swoją politykę CSP i uzasadnienie każdej dyrektywy, aby pomóc przyszłym programistom w jej zrozumieniu i utrzymaniu.

Podsumowanie

Content Security Policy to potężne narzędzie do łagodzenia ataków XSS i zwiększania bezpieczeństwa aplikacji internetowych. Poprzez staranne zdefiniowanie białej listy zaufanych źródeł można znacznie zmniejszyć ryzyko wykonania złośliwego kodu i chronić użytkowników przed szkodą. Wdrożenie CSP może być wyzwaniem, ale postępując zgodnie z najlepszymi praktykami opisanymi w tym artykule i uwzględniając specyficzne potrzeby aplikacji oraz globalną publiczność, można stworzyć solidną i skuteczną politykę bezpieczeństwa, która chroni witrynę i użytkowników na całym świecie.

Pamiętaj, że bezpieczeństwo to proces ciągły, a CSP to tylko jeden element układanki. Połącz CSP z innymi środkami bezpieczeństwa, takimi jak walidacja danych wejściowych, kodowanie danych wyjściowych i regularne audyty bezpieczeństwa, aby stworzyć kompleksową strategię obrony w głąb.

Dodatkowe materiały

• Content Security Policy (CSP) - MDN Web Docs
• Ewaluator CSP
• Content-Security-Policy.com