Ta strona została przetłumaczona przez Cloud Translation API.

(standard) Content Security Policy

Mike West

Joe Medley

Model zabezpieczeń internetu opiera się na zasadą Same-origin. Koduj z aplikacji https://mybank.com powinien mieć dostęp tylko do konta https://mybank.com do danych, więc https://evil.example.com z pewnością nigdy nie powinien mieć dostępu do tych danych. Każde źródło jest odizolowane od reszty sieci, dzięki czemu deweloperzy piaskownicy, w której możesz budować i bawić. Teoretycznie wszystko jest genialne. W osoby przeprowadzające atak odkryły sprytne sposoby na obalenie systemu.

Skrypty między witrynami (XSS) ataków, na przykład ominąć tę samą zasadę dotyczącą źródła, nakłaniając strony do ataku przesyłając złośliwy kod wraz z odpowiednią treścią. To ogromna bo przeglądarki traktują cały kod wyświetlany na stronie jako jako część źródła zabezpieczeń tej strony. Ściągawka dotycząca XSS to stara, ale reprezentatywna przekrój metod, których może używać atakujący nadużywanie zaufania przez wstrzykiwanie złośliwego kodu. Jeśli atakujący udało się wstrzyknięcie dowolnego kodu. Koniec gry: dane sesji użytkownika przejęte, a informacje, które powinny pozostać w tajemnicy, wydostają się do Gniewu. Chłopaki. Oczywiście chcielibyśmy temu zapobiec, jeśli to możliwe.

W tym omówieniu przedstawiamy zabezpieczenia, które mogą znacznie zmniejszyć ryzyko wpływ ataków XSS na nowoczesne przeglądarki: Content Security Policy (CSP).

TL;DR

Użyj list dozwolonych, aby poinformować klienta, co jest dozwolone, a co nie.
Dowiedz się, jakie dyrektywy są dostępne.
Poznaj wybrane słowa kluczowe.
Kod wbudowany i eval() są uznawane za szkodliwe.
Zgłaszaj naruszenia zasad na swoim serwerze, zanim je wyegzekwujesz.

Listy dozwolonych źródeł

Problemem wykorzystywanym w atakach XSS jest niezdolność przeglądarki do rozpoznania między skryptem, który jest częścią aplikacji, a skryptem złośliwie wstrzyknięty przez osobę trzecią. Przykład: przycisk Google +1 na stronie dolna część tej strony wczytuje i wykonuje kod z https://apis.google.com/js/plusone.js w kontekście pochodzenia tej strony. Śr ufam temu kodowi, ale nie możemy oczekiwać, że przeglądarka samodzielnie go rozróżni od firmy apis.google.com jest super, a kod z usługi apis.evil.example.com prawdopodobnie nie jest. Przeglądarka chętnie pobiera i uruchamia kod na stronie niezależnie od źródła.

Zamiast ślepo ufać wszystkim, które dostarcza serwer, CSP definiuje Content-Security-Policy nagłówek HTTP, który umożliwia utworzenie listy dozwolonych źródeł zaufanych treści i instruuje przeglądarkę, by uruchamiała wyłącznie z tych źródeł. Nawet jeśli atakujący znajdzie dziurę, przez którą nie zostanie wstawiony w celu wstrzykiwania skryptu, nie znajdzie się na liście dozwolonych i dlatego nie zostanie .

Ufamy, że apis.google.com dostarcza prawidłowy kod, a my wierzymy w siebie ani zrobić tego samego, zdefiniujmy zasadę, która pozwala na wykonywanie skryptu tylko wtedy, pochodzi z jednego z tych dwóch źródeł:

Content-Security-Policy: script-src 'self' https://apis.google.com

Proste, prawda? Jak pewnie się domyślasz, script-src to dyrektywa, która: kontroluje zestaw uprawnień związanych ze skryptem dla konkretnej strony. Określiliśmy 'self' jako prawidłowe źródło skryptu, a https://apis.google.com jako innego użytkownika. Przeglądarka bezproblemowo pobiera i uruchamia JavaScript z apis.google.com przez HTTPS oraz z początku bieżącej strony.

Błąd konsoli: odmowa załadowania skryptu „http://evil.example.com/evil.js” ponieważ narusza tę dyrektywę Content Security Policy: script-src „self” https://apis.google.com

Po zdefiniowaniu tej zasady przeglądarka po prostu zgłasza błąd zamiast skrypt wczytywania z innego źródła. Gdy sprytny atakujący uda się wstrzyknięcie kodu w witrynie, wyświetli się komunikat o błędzie, niż można było oczekiwać.

Zasada ma zastosowanie do wielu różnych zasobów

Najbardziej oczywiste zagrożenia dla bezpieczeństwa to zasoby skryptów, jednak CSP zapewnia bogaty zestaw dyrektyw zasad, które dają dość szczegółową kontrolę nad zasobami które może zostać załadowane. Znasz już grę script-src, więc otoczenie powinno być jasne.

Omówmy pokrótce pozostałe dyrektywy dotyczące zasobów. Lista poniżej reprezentuje stan dyrektyw z drugiego poziomu. Opublikowano specyfikację poziomu 3, ale większość nie została jeszcze zaimplementowana w głównych przeglądarki.

base-uri ogranicza adresy URL, które mogą występować w elemencie <base> strony.
child-src zawiera adresy URL instancji roboczych oraz zawartości ramek umieszczonych w witrynie. Dla: przykład: child-src https://youtube.com umożliwi umieszczanie filmów z z YouTube, ale nie z innych źródeł.
connect-src ogranicza źródła, z którymi możesz się połączyć (za pomocą XHR, WebSockets i EventSource).
font-src określa źródła, które mogą udostępniać czcionki internetowe. Przeglądarka Google czcionki można włączyć w font-src https://themes.googleusercontent.com.
form-action zawiera listę prawidłowych punktów końcowych, które można przesłać z tagów <form>.
frame-ancestors określa źródła, które mogą zostać umieszczone na bieżącej stronie. Ta dyrektywa odnosi się do tagów <frame>, <iframe>, <embed> i <applet>. Tej dyrektywy nie można użyć w tagach <meta>. Ma ona zastosowanie tylko w przypadku języków innych niż HTML i zasobami Google Cloud.
Licencja frame-src została wycofana na poziomie 2, ale została przywrócona na poziomie 3. Jeśli nie, nadal wraca do wartości child-src, tak jak wcześniej.
img-src określa źródła, z których mogą być wczytywane obrazy.
media-src ogranicza źródła, z których mogą być przesyłane treści wideo i audio.
object-src umożliwia kontrolę nad Flashem i innymi wtyczkami.
plugin-types ogranicza rodzaje wtyczek, które może wywoływać strona.
report-uri określa adres URL, na który przeglądarka będzie wysyłać raporty, gdy naruszono politykę bezpieczeństwa treści. Tej dyrektywy nie można użyć w tym języku: <meta> .
style-src to odpowiednik arkusza stylów script-src.
upgrade-insecure-requests nakazuje klientom użytkownika przepisywanie schematów adresów URL, zmieniając HTTP na HTTPS. Ta dyrektywa dotyczy witryn z dużą liczbą starego adresu URL, który trzeba przepisać.
worker-src to dyrektywa CSP poziomu 3 ograniczająca adresy URL, które mogą być wczytywany jako instancja robocza, współużytkowana lub współdzielona instancja robocza lub mechanizm Service Worker. W lipcu 2017 r. dyrektywa zawiera w ograniczonych implementacjach.

Domyślnie dyrektywy są otwarte. Jeśli nie ustawisz konkretnej zasady dla , powiedzmy font-src, potem ta dyrektywa zachowuje się domyślnie chociaż podano * jako prawidłowe źródło (możesz np. wczytać czcionki z w dowolnym miejscu i bez ograniczeń).

To domyślne działanie można zastąpić, określając parametr default-src . Ta dyrektywa definiuje wartości domyślne dla większości nieokreślonych dyrektyw. Zasadniczo dotyczy to każdej dyrektywy, kończy się na -src. Jeśli default-src ma wartość https://example.com i nie uda się w celu określenia dyrektywy font-src, możesz wczytać czcionki z https://example.com i nigdzie indziej. W naszej deklaracji określiliśmy tylko script-src we wcześniejszych przykładach, co oznacza, że obrazy, czcionki itd. mogą być wczytywane dowolnego punktu początkowego.

W podanych niżej dyrektywach nie jest używany element default-src. Pamiętaj, że Jeśli ich nie ustawisz, będzie to równoznaczne z zezwoleniem na cokolwiek.

base-uri
form-action
frame-ancestors
plugin-types
report-uri
sandbox

Możesz użyć ich tyle, ile sensownych w danym przypadku w konkretnej aplikacji, podając je w nagłówku HTTP, rozdzielając ze średnikami. Pamiętaj, aby podać wszystkie wymagane zasoby określonego typu w jednej dyrektywie. Jeśli napisałeś(aś) coś w rodzaju script-src https://host1.com; script-src https://host2.com zostanie po prostu zignorowana. Coś takiego jak poniżej poprawnie określić oba źródła jako prawidłowe:

script-src https://host1.com https://host2.com

Jeśli na przykład masz aplikację, która wczytuje wszystkie swoje zasoby z sieci dostarczania treści (np. https://cdn.example.net) i wiedzieć, nie wymagają żadnych treści w ramkach ani wtyczek, zasady mogą wyglądać np.:

Content-Security-Policy: default-src https://cdn.example.net; child-src 'none'; object-src 'none'

Szczegóły implementacji

Zobaczysz nagłówki X-WebKit-CSP i X-Content-Security-Policy w różnych i samouczki w internecie. Od tej pory powinieneś ignorować te prefiksy nagłówki. Nowoczesne przeglądarki (z wyjątkiem IE) obsługują Nagłówek Content-Security-Policy. Tego nagłówka należy użyć.

Niezależnie od użytego nagłówka zasady są zdefiniowane dla poszczególnych stron: musisz wysyłać nagłówek HTTP z każdą odpowiedzią, są chronione. Zapewnia to dużą elastyczność, ponieważ można dostosować do zasad dla określonych stron w oparciu o ich konkretne potrzeby. Może jeden zestaw gdy inne strony w Twojej witrynie mają przycisk +1, ładowany tylko wtedy, gdy jest to konieczne.

Lista źródeł w każdej dyrektywie jest elastyczna. Źródła możesz określić według schemat (data:, https:) lub zakres szczegółowości od „tylko nazwa hosta” (example.com, który pasuje do dowolnego punktu początkowego na tym hoście: dowolnego schematu, dowolnego portu) do w pełni kwalifikowany identyfikator URI (https://example.com:443, który pasuje tylko do HTTPS, tylko example.com i tylko port 443). Symbole wieloznaczne są akceptowane, ale tylko jako schematy, lub w pierwszej pozycji nazwy hosta: *://*.example.com:* dopasować wszystkie subdomeny example.com (ale nie samej example.com), używając i dowolnych schematów na dowolnym porcie.

Lista źródeł może też zawierać 4 słowa kluczowe:

Nazwa 'none' nie odpowiada nic.
'self' pasuje do bieżącego źródła, ale nie do jego subdomen.
'unsafe-inline' pozwala na wbudowane JavaScript i CSS. (Porozmawiamy o tym w ).
'unsafe-eval' zezwala na mechanizmy zamiany tekstu na JavaScript, takie jak eval. (Dodamy również do tego).

Te słowa kluczowe wymagają cudzysłowu. Na przykład: script-src 'self' (z cudzysłowami). autoryzuje wykonanie kodu JavaScript na bieżącym hoście; script-src self (bez cudzysłowów) zezwala na JavaScript z serwera o nazwie „self” (a nie z sekcji bieżącego hosta), co prawdopodobnie nie o to Ci chodzi.

Piaskownica

Jest jeszcze jedna dyrektywa, o której warto wspomnieć: sandbox. Jest trochę niż pozostałe, ponieważ nakłada ograniczenia na działania które może zająć strona, a nie tylko związane z jej zasobami, które może wczytać. Jeśli jeśli istnieje dyrektywa sandbox, strona jest traktowana tak, jakby została wczytana; wewnątrz elementu <iframe> z atrybutem sandbox. Mogą one obejmować szeroki zakres wpływ na stronę: wymuszanie na stronie unikalnego źródła i zapobieganie pojawianiu się formularza lub wniosek o usunięcie informacji. Ten artykuł wykracza poza zakres tego artykułu, ale szczegółowe informacje o prawidłowych atrybutach piaskownicy w „Piaskownica” specyfikacji HTML5.

Metatag

Preferowanym mechanizmem dostarczania przez CSP jest nagłówek HTTP. Może się jednak okazać, że aby ustawić zasady na stronie bezpośrednio w znacznikach. Zrób to, używając tagu <meta> z: atrybut http-equiv:

<meta
  http-equiv="Content-Security-Policy"
  content="default-src https://cdn.example.net; child-src 'none'; object-src 'none'"
/>

Nie można użyć tej opcji w przypadku usług frame-ancestors, report-uri i sandbox.

Kod wbudowany jest uważany za szkodliwy

Powinno być jasne, że CSP opiera się na źródłach z listy dozwolonych, ponieważ jest to jednoznaczny sposób poinstruowania przeglądarki, aby traktowała określone zestawy zasobów akceptowalna i odrzucona. Listy dozwolonych oparte na źródle nie działają w tym przypadku, ale także rozwiązuj największe zagrożenia związane z atakami XSS: wstrzykiwanie wbudowanego skryptu. Jeśli osoba przeprowadzająca atak może wstrzyknąć tag skryptu zawierający bezpośrednio złośliwe oprogramowanie ładunek (<script>sendMyDataToEvilDotCom();</script>), przeglądarka nie ma mechanizmu odróżniania jej od wiarygodnej w tagu wbudowanego skryptu. CSP rozwiązuje ten problem, całkowicie blokując skrypt wbudowany: tylko w ten sposób.

Blokada obejmuje nie tylko skrypty umieszczone bezpośrednio w tagach script, wbudowane moduły obsługi zdarzeń i adresy URL javascript:. Musisz przenieść zawartość script do pliku zewnętrznego, a adresy URL javascript: i <a ... onclick="[JAVASCRIPT]"> zastąp odpowiednimi wywołaniami addEventListener(). Przykład: możesz przepisać następujący fragment z:

<script>
  function doAmazingThings() {
    alert('YOU AM AMAZING!');
  }
</script>
<button onclick="doAmazingThings();">Am I amazing?</button>

na przykład na:

<!-- amazing.html -->
<script src="amazing.js"></script>
<button id="amazing">Am I amazing?</button>

<div style="clear:both;"></div>

// amazing.js
function doAmazingThings() {
  alert('YOU AM AMAZING!');
}
document.addEventListener('DOMContentLoaded', function () {
  document.getElementById('amazing').addEventListener('click', doAmazingThings);
});

Przeredagowany kod ma wiele zalet, które nie tylko ułatwiają CSP; jest to sprawdzona metoda, niezależnie od używania CSP. W treści JavaScript łączy strukturę i działanie w niewłaściwy sposób. Zasoby zewnętrzne są łatwiejsze do buforowania przez przeglądarki, bardziej zrozumiałe programistów oraz umożliwiają kompilację i minifikację. Lepiej piszesz w przypadku przenoszenia kodu do zasobów zewnętrznych.

Styl wbudowany jest traktowany w ten sam sposób: zarówno atrybut style, jak i element style i skonsolidować je w zewnętrzne arkusze stylów, by zabezpieczyć różnorodność zaskakująco sprytne metod wydobycia danych, które są dostępne w CSS.

Jeśli musisz mieć wbudowany skrypt i styl, możesz je włączyć dodając 'unsafe-inline' jako dozwolone źródło w script-src lub style-src . Możesz też użyć wartości jednorazowej lub haszu (patrz poniżej), ale nie jest to konieczne. Blokada wbudowanego skryptu to największa bezpieczna metoda zapewniania bezpieczeństwa przez CSP. zablokowanie stylu wbudowanego także uszkodzi aplikację. To trochę wysiłek z góry, aby po przeniesieniu całego kodu wszystko działało prawidłowo. ale nie zawsze jest to opłacalne.

Jeśli bezwzględnie musisz go używać

CSP poziomu 2 zapewnia zgodność wsteczną dla wbudowanych skryptów, umożliwiając: dodaj określone wbudowane skrypty do listy dozwolonych przy użyciu kryptograficznej liczby jednorazowej (liczba użyty raz) lub hasz. Chociaż może to być uciążliwe, jednym palcem.

Aby użyć liczby jednorazowej, przypisz tagowi skryptu atrybut jednorazowy. Jego wartość musi pasować do jednej wartości na liście zaufanych źródeł. Na przykład:

<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">
  // Some inline code I can't remove yet, but need to asap.
</script>

Teraz dodaj liczbę jednorazową do dyrektywy script-src dołączonej do słowa kluczowego nonce-.

Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'

Pamiętaj, że żądania jednorazowe muszą być generowane ponownie dla każdego żądania strony i muszą być nie do odgadnięcia.

Hasze działają bardzo podobnie. Zamiast dodawać kod do tagu skryptu, utworzyć hasz SHA samego skryptu i dodać go do dyrektywy script-src. Załóżmy na przykład, że Twoja strona zawiera:

<script>
  alert('Hello, world.');
</script>

Oto treść zasad:

Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='

Pamiętaj o kilku kwestiach. Prefiks sha*- określa algorytm który generuje hasz. W przykładzie powyżej użyto sha256-. CSP również obsługuje sha384- i sha512-. Podczas generowania hasza nie uwzględniaj <script> tagu. Stosuj również wielkie litery i spacje, w tym na początku i na końcu na końcu ciągu znaków odstępu.

Wyszukanie w Google metody generowania haszy SHA pozwoli znaleźć rozwiązania w każdym różnych języków. W Chrome 40 lub nowszej możesz otworzyć Narzędzia deweloperskie, odśwież stronę. Na karcie Console (Konsola) znajdziesz komunikaty o błędach z prawidłowymi SHA256 dla każdego wbudowanego skryptu.

Oceń też

Nawet jeśli atakujący nie będzie w stanie bezpośrednio wstrzyknąć skryptu, może być w stanie oszukać do konwertowania w innym przypadku tekstu obojętnego na wykonywalny JavaScript. i wykonywania go w jego imieniu. eval(), nowe Function() , setTimeout([string], ...) i setInterval([string], ...) to wszystkie wektory, przez które wstrzykiano może spowodować uruchomienie czegoś nieoczekiwanie szkodliwego. Domyślna wartość CSP reakcją na to ryzyko jest całkowite zablokowanie tych wektorów.

Ma to kilka wpływu na sposób tworzenia aplikacji:

Musisz przeanalizować plik JSON za pomocą wbudowanego JSON.parse, zamiast polegać eval Natywne operacje JSON są dostępne w tych krajach: każdej przeglądarki od IE8; i całkowicie bezpieczne.
Przeredaguj wszystkie obecnie wykonywane połączenia setTimeout lub setInterval z funkcjami w tekście, a nie ciągami tekstowymi. Na przykład:

setTimeout("document.querySelector('a').style.display = 'none';", 10);

lepiej napisać tak:

setTimeout(function () {
  document.querySelector('a').style.display = 'none';
}, 10);

Unikaj tworzenia wbudowanych szablonów w czasie działania: wiele bibliotek szablonów swobodnie korzysta z interfejsu new Function(), aby przyspieszyć generowanie szablonów w czasie działania. To z użyciem dynamicznego programowania, ale wiąże się to z ryzykiem ocenianie złośliwego tekstu. Niektóre platformy od razu obsługują CSP, wraca do wydajnego parsera w przypadku braku eval. Dyrektywa ng-csp w AngularJS .

Lepszym wyborem byłby jednak język szablonu, który zawierałby wstępna kompilacja (Handlebars are, ). Wstępne kompilowanie szablonów może sprawić, że wrażenia użytkowników będą jest szybsze niż najszybsze środowisko wykonawcze i jest też bezpieczniejsze. Jeśli eval i części tekstu na JavaScript są kluczowe w Twojej aplikacji. włącz je, dodając 'unsafe-eval' jako dozwolone źródło w script-src ale zdecydowanie odradzamy takie postępowanie. Zablokowanie możliwości wykonywania znacznie utrudnia atakującym wykonanie nieautoryzowanych w witrynie.

Raportowanie

Możliwość blokowania niezaufanych zasobów po stronie klienta przez CSP na użytkowników, ale dobrze byłoby ustawić powiadomienie przesyłana z powrotem na serwer, aby można było zidentyfikować i usunąć wszelkie błędy, które umożliwiają przed wstrzykiwaniem złośliwego oprogramowania. Aby to zrobić, przekaż im instrukcje do POST zgłoszeń o naruszeniach w formacie JSON do lokalizacji w dyrektywie report-uri.

Content-Security-Policy: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

Raporty będą wyglądały mniej więcej tak:

{
  "csp-report": {
    "document-uri": "http://example.org/page.html",
    "referrer": "http://evil.example.com/",
    "blocked-uri": "http://evil.example.com/evil.js",
    "violated-directive": "script-src 'self' https://apis.google.com",
    "original-policy": "script-src 'self' https://apis.google.com; report-uri http://example.org/my_amazing_csp_report_parser"
  }
}

Zawiera on sporo informacji, które pomogą Ci określić, konkretną przyczynę naruszenia, w tym stronę, na której doszło do naruszenia (document-uri), strona odsyłająca tej strony (zauważ, że w przeciwieństwie do pola nagłówka, klucz nie zawiera literówek), zasób, który naruszył zasady strony (blocked-uri) naruszoną przez nią dyrektywę (violated-directive), a także pełną treść zasad dotyczących strony (original-policy).

Tylko raport

Jeśli dopiero zaczynasz korzystać z CSP, warto zapoznać się z obecnymi stanu aplikacji przed wdrożeniem dla użytkowników drastycznych zasad. Krokiem do pełnego wdrożenia jest poproszenie przeglądarki o monitorowanie zasad, zgłaszają naruszenia, ale nie egzekwują ograniczeń. Zamiast wysyłając nagłówek Content-Security-Policy, wyślij Content-Security-Policy-Report-Only.

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

Zasada określona w trybie „tylko raport” nie blokuje zasobów z ograniczeniami, ale zgłoszenie naruszenia zasad zostanie przesłane do wskazanej przez Ciebie lokalizacji. Możesz nawet wysłać oba nagłówki, egzekwując jedną zasadę i monitorując inną. To świetnie sposób oceny wpływu zmian na CSP aplikacji: włącz zgłoszenia nowych zasad, monitorowanie raportów o naruszeniach i naprawianie Głośniej; Jeśli wyniki będą zadowalające, zacznij egzekwować nowe zasady.

Rzeczywiste wykorzystanie w świecie

Standard CSP 1 jest dość przydatny w przeglądarkach Chrome, Safari i Firefox, ale ma bardzo ograniczoną nie obsługuje IE w wersji 10. Dostępne opcje znajdziesz na stronie caniuse.com. CSP Level 2 jest dostępny w Chrome od wersji 40. W dużych witrynach, takich jak Twitter i Facebook, jest wdrożony nagłówek (Warto przeczytać studium przypadku na Twitterze), a standard jest już gotowy który umożliwia rozpoczęcie wdrażania we własnych witrynach.

Pierwszym krokiem na drodze do stworzenia zasad dla aplikacji jest sprawdzenie, które rzeczywiście wczytujesz. Gdy już uznasz, że już wiesz, na elementy aplikacji, na ich podstawie skonfiguruj zasady . Omówmy kilka typowych zastosowań i określimy, i pomóc im w ramach zabezpieczeń CSP.

Przypadek użycia nr 1: widżety mediów społecznościowych

Przycisk Google +1 zawiera skrypt z źródeł danych https://apis.google.com i umieszcza <iframe> z https://plusone.google.com. Potrzebujesz zasady, która uwzględnia aby umieścić przycisk. Minimalną zasadą jest script-src https://apis.google.com; child-src https://plusone.google.com. Potrzebujesz też że fragment kodu JavaScript dostarczony przez Google jest wciągany lub zewnętrznego pliku JavaScript. Jeśli zastosowano zasadę frame-src obowiązującą na poziomie 1 Na poziomie 2 musisz zmienić go na: child-src. To już nie jest potrzebne w CSP na poziomie 3.
Przycisk Podoba mi się na Facebooku dostępnych jest kilka opcji implementacji. Zalecamy trzymanie się <iframe>, ponieważ jest ona bezpiecznie oddzielona od reszty witryny. it do prawidłowego działania wymaga dyrektywy child-src https://facebook.com. Notatka że domyślnie kod <iframe> udostępniany przez Facebooka wczytuje wartości względne Adres URL: //facebook.com. Zmień to, by wyraźnie określić protokół HTTPS: https://facebook.com Nie ma powodu, aby używać protokołu HTTP, jeśli nie trzeba.
Przycisk Tweetuj na Twitterze korzysta z dostępu do skryptu i ramki, które są hostowane na https://platform.twitter.com (Twitter również udostępnia względny adres URL przez default; podczas kopiowania/wklejania lokalnie wybierz w kodzie protokół HTTPS). Jeśli przeniesiesz fragment kodu JavaScript, usługa script-src https://platform.twitter.com; child-src https://platform.twitter.com będzie gotowa które Twitter udostępnia w zewnętrznym pliku JavaScript.
Inne platformy mają podobne wymagania i można je traktować w podobny sposób. Zalecamy ustawienie default-src o wartości 'none' i obserwowanie, aby w konsoli określić zasoby, które należy włączyć, aby widżety działały.

Dodawanie wielu widżetów jest proste – wystarczy połączyć zasady. z dyrektywami, pamiętając, aby scalić wszystkie zasoby danego typu w jeden . Jeśli chcesz, by wszystkie 3 widżety mediów społecznościowych były takie, podobny do tego:

script-src https://apis.google.com https://platform.twitter.com; child-src https://plusone.google.com https://facebook.com https://platform.twitter.com

Przypadek użycia nr 2: blokada

Załóżmy, że prowadzisz witrynę bankową i chcesz się upewnić, można wczytać tylko zasoby utworzone przez Ciebie. W takim przypadku może zacząć od zasady domyślnej, która blokuje absolutnie wszystko (default-src 'none'), i kontynuuje ten proces.

Załóżmy, że bank wczytuje wszystkie obrazy, style i skrypt z sieci CDN na https://cdn.mybank.net i łączy się przez XHR z https://api.mybank.com/ pobierać różne dane. Ramki są używane, ale tylko w przypadku stron lokalnych w (bez źródeł zewnętrznych). Na stronie nie ma Flasha, czcionek ani czcionek. Dodatki. Najbardziej restrykcyjny nagłówek CSP, jaki możemy wysłać, to:

Content-Security-Policy: default-src 'none'; script-src https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net; connect-src https://api.mybank.com; child-src 'self'

Przypadek użycia nr 3: tylko SSL

Administrator forum poświęconego kwestiom ślubnym chce mieć pewność, że wszystkie zasoby są ładowane tylko przez bezpieczne kanały, ale nie piszą dużo kodu; przepisywanie duże porcje oprogramowania forów innych firm wypełnionego po brzegi skrypt i styl są poza jego możliwościami. Następująca zasada miałaby być skuteczne:

Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'

Mimo że https: jest określony w polu default-src, skrypt i styl nie dziedziczą automatycznie tego źródła. Każda dyrektywa w całości zastępuje wartość domyślną dla tego konkretnego typu zasobu.

Przyszłość

Content Security Policy poziom 2 to Rekomendacja kandydatów. Grupa robocza ds. bezpieczeństwa aplikacji internetowych W3C rozpoczęliśmy już prace nad kolejną iteracją specyfikacji, Content Security Policy (poziom 3).

Jeśli interesuje Cię dyskusja na temat nowych funkcji, przejrzyj archiwa listy adresowej public-webappsec@, lub dołącz do nas.