Dzięki standardowi Content Security Policy (CSP) właściciel witryny ma pewność, że zawartość wczytana na stronie jest godna zaufania. Dostawcy CSP ograniczają ataki typu cross-site scripting (XSS), ponieważ mogą blokować niebezpieczne skrypty wstrzykiwane przez osoby przeprowadzające atak. CSP można jednak łatwo pominąć, jeśli nie jest wystarczająco rygorystyczny. Więcej informacji znajdziesz w artykule o ograniczaniu ataków typu cross-site scripting (XSS) na rygorystyczne zasady Content Security Policy (CSP). Lighthouse zbiera informacje na temat CSP egzekwowane w dokumencie głównym i zgłasza problemy z oceny CSP, jeśli można je pominąć.
Wymagane metody w przypadku CSP, którego nie można pominąć
Zastosuj poniższe metody, aby mieć pewność, że nie można pominąć CSP. Jeśli CSP można pominąć, Lighthouse wyświetli ostrzeżenie o wysokim poziomie ważności.
Cele CSP: XSS
Aby kierować reklamy na XSS, dostawca CSP powinien zawierać dyrektywę script-src, object-src i base-uri. CSP nie powinien zawierać błędów składni.
Zabezpieczenia script-src i object-src zabezpieczają stronę przed niebezpiecznymi skryptami i wtyczkami. Za pomocą default-src można też skonfigurować ogólne zasady zamiast wielu dyrektyw, w tym script-src i object-src.
base-uri zapobiega wstrzykiwaniu nieautoryzowanych tagów <base>, które mogą służyć do przekierowywania wszystkich względnych adresów URL (np. skryptów) do domeny, którą kontrolują.
CSP używa liczb jednorazowych lub haszy, aby unikać pomijania listy dozwolonych
Dostawca CSP, który konfiguruje listę dozwolonych dla script-src, opiera się na założeniu, że wszystkie odpowiedzi pochodzące z zaufanej domeny są bezpieczne i mogą być wykonywane jako skrypty. Założenie to nie obowiązuje jednak we współczesnych zastosowaniach. niektóre typowe, łagodne wzorce, takie jak ujawnianie interfejsów JSONP i hostowanie kopii biblioteki AngularJS, pozwalają hakerom uciec od ograniczeń CSP.
W praktyce może to nie być oczywiste dla autorów aplikacji, ale większość list dozwolonych (script-src) może zostać obchodząca przez osobę przeprowadzającą atak z błędem XSS i zapewniając niewielką ochronę przed wstrzykiwaniem skryptów. W przeciwieństwie do tego metody oparte na liczbie jednorazowej i opartej na haszowaniu nie mają tych problemów i ułatwiają stosowanie i utrzymywanie bezpieczniejszych zasad.
Na przykład ten kod wykorzystuje punkt końcowy JSONP hostowany w zaufanej domenie do wstrzykiwania skryptu kontrolowanego przez osobę przeprowadzającą atak:
CSP:
script-src https://trusted.example.com
HTML:
<script src="https://trusted.example.com/path/jsonp?callback=alert(document.domain)//"></script>
Aby uniknąć omijania zabezpieczeń, CSP powinien zezwalać na poszczególne skrypty z użyciem liczb jednorazowych lub haszy oraz używać atrybutu „strict-dynamic” zamiast listy dozwolonych.
Dodatkowe zalecenia dotyczące bezpiecznego CSP
Aby zwiększyć bezpieczeństwo i zgodność, zaimplementuj poniższe metody. Jeśli dostawca CSP nie zastosuje się do któregokolwiek z zaleceń, Lighthouse wyświetli ostrzeżenie o średnim poziomie ważności.
Skonfiguruj raportowanie CSP
Skonfigurowanie miejsca docelowego raportowania pomoże Ci monitorować, czy nie występują awarie. Miejsce docelowe raportowania możesz określić za pomocą dyrektyw report-uri lub report-to. report-to nie jest obecnie obsługiwany przez wszystkie nowoczesne przeglądarki, więc zalecamy używanie obu lub tylko języka report-uri.
Jeśli jakakolwiek treść narusza zasady CSP, przeglądarka wyśle zgłoszenie do skonfigurowanego miejsca docelowego. Upewnij się, że w tym miejscu docelowym masz skonfigurowaną aplikację, która obsługuje te raporty.
Definiowanie CSP w nagłówku HTTP
CSP można zdefiniować w metatagu w taki sposób:
<meta http-equiv="Content-Security-Policy" content="script-src 'none'">
Jeśli to możliwe, zdefiniuj CSP w nagłówku odpowiedzi HTTP. Wstrzyknięcie przed metatagiem powoduje pominięcie CSP. Oprócz tego dostawcy CSP z metatagami nie obsługują tych atrybutów: frame-ancestors, sandbox ani raportowania.
Sprawdź, czy CSP jest zgodny wstecznie
Nie wszystkie przeglądarki obsługują liczby jednorazowe/hasze CSP, dlatego zalecamy dodanie parametru unsafe-inline jako kreacji zastępczej dla niezgodnych przeglądarek. Jeśli przeglądarka obsługuje liczby jednorazowe i hasze, parametr unsafe-inline zostanie zignorowany.
Nie wszystkie przeglądarki obsługują też strict-dynamic. Zalecamy ustawienie listy dozwolonych jako zastępczej dla wszystkich niezgodnych przeglądarek. W przypadku przeglądarek, które obsługują strict-dynamic, lista dozwolonych będzie ignorowana.
Jak utworzyć rygorystyczny CSP
Poniżej znajdziesz przykład użycia rygorystycznego CSP z zasadą opartą na liczbie jednorazowej.
CSP:
script-src 'nonce-random123' 'strict-dynamic' 'unsafe-inline' https:;
object-src 'none';
base-uri 'none';
report-uri https://reporting.example.com;
HTML:
<script nonce="random123" src="https://trusted.example.com/trusted_script.js"></script>
Parametr random123 to dowolny ciąg znaków w formacie base64 wygenerowany po stronie serwera przy każdym wczytaniu strony. Elementy unsafe-inline i https: są ignorowane w nowoczesnych przeglądarkach ze względu na wartość jednorazową i strict-dynamic. Więcej informacji o stosowaniu rygorystycznego CSP znajdziesz w tym przewodniku.
Możesz sprawdzić CSP pod kątem potencjalnych omijania zabezpieczeń za pomocą narzędzia Lighthouse i narzędzia CSP Evaluator. Jeśli chcesz przetestować nowy CSP bez ryzyka uszkodzenia istniejących stron, zdefiniuj go w trybie tylko do raportu, używając nazwy Content-Security-Policy-Report-Only jako nagłówka. Spowoduje to wysłanie naruszeń zasad CSP do wszystkich miejsc docelowych raportowania skonfigurowanych za pomocą report-to i report-uri, ale w rzeczywistości nie wymusza CSP.