From de5c456ebded0e038adbf23db34cc290c8829180 Mon Sep 17 00:00:00 2001 From: Florian Merz Date: Thu, 11 Feb 2021 14:49:24 +0100 Subject: unslug pl: move --- .../certificate_transparency/index.html" | 63 ----- "files/pl/web/bezpiecze\305\204stwo/index.html" | 24 -- .../podstawy_bezpieczenstwa_informacji/index.html" | 36 --- .../same-origin_policy/index.html" | 277 --------------------- .../subresource_integrity/index.html" | 163 ------------ 5 files changed, 563 deletions(-) delete mode 100644 "files/pl/web/bezpiecze\305\204stwo/certificate_transparency/index.html" delete mode 100644 "files/pl/web/bezpiecze\305\204stwo/index.html" delete mode 100644 "files/pl/web/bezpiecze\305\204stwo/podstawy_bezpieczenstwa_informacji/index.html" delete mode 100644 "files/pl/web/bezpiecze\305\204stwo/same-origin_policy/index.html" delete mode 100644 "files/pl/web/bezpiecze\305\204stwo/subresource_integrity/index.html" (limited to 'files/pl/web/bezpieczeństwo') diff --git "a/files/pl/web/bezpiecze\305\204stwo/certificate_transparency/index.html" "b/files/pl/web/bezpiecze\305\204stwo/certificate_transparency/index.html" deleted file mode 100644 index 7a9b814c43..0000000000 --- "a/files/pl/web/bezpiecze\305\204stwo/certificate_transparency/index.html" +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: Certificate Transparency -slug: Web/Bezpieczeństwo/Certificate_Transparency -tags: - - Bezpieczeństwo - - Web - - bezpieczeństwo aplikacji WWW -translation_of: Web/Security/Certificate_Transparency ---- -

Certyfikat Przejrzystości (Certificate Transparency) to otwarta platforma programistyczna (framework) stworzona do ochrony oraz monitorowania braków w certyfikacji. Świeżo wydane certyfikaty dostają się do obiegu publicznego, często niezależne logi CT zostają wpisane do rejestru, przez co zachowany zostaje zabezpieczony kryptograficznie rekord certyfikatów TLS.

- -

W ten sposób organy certyfikujące (CA) mogą podlegać znacznie większemu, publicznemu nadzorowi i kontroli. Potencjalnie szkodliwe certyfikaty, jak te, które naruszają Podstawowe Wymogi CA/B Forum mogą zostać znacznie sprawniej wykryte i cofnięte. Podmioty zajmujące się sprzedażą przeglądarek oraz opiekuni certyfikatów zaufanych są również uprawnieni do podejmowania gruntowniej popartych decyzji dot. problematycznych organów certyfikujących, którym mogą odmowić zaufania.

- -

Kontekst

- -

Logi CT są budowane w ramach struktury danych drzewa Merkla (Merkle tree). Węzły są oznaczane hashami kryptograficznymi ich węzłów potomnych. Liście (leaf nodes) zawierają hashe aktualnych części danych. Oznaczenie węzła głównego (root node) zależy jednakże od wszystkich pozostałych węzłów w drzewie.

- -

W kontekście przejrzystości certyfikacji dane hashowane przez liście są certyfikatami wydawanymi obecnie przez różne CA. Obecność certyfikatu może zostać zweryfikowana przez dowód kontroli skutecznie generowany i weryfikowany w czasie działania logarytmicznego - logarithmic O(log n) time.

- -

Pierwotnie, w 2013 roku przejrzystość certyfikacji służyła przeciwdziałaniu narażania CA (naruszenia DigiNotar w 2011 roku), wątpliwym decyzjom (incydent Trustwave subordinate root w 2012 roku) oraz technicznym problemom wydawniczym (emisja słabego, 512-bitowego certyfikatu przez Digicert Sdn Bhd w Malezji)

- -

Wdrożenie

- -

Gdy certyfikaty zostają dostarczone do rejestru CT, znacznik SCT (signed certificate timestamp) zostaje wygenerowany i zwrócony. Służy to jako dowód, że certyfikat został dostarczony i zostanie dodany do rejestru.

- -

Wg specyfikacji podczas komunikacji serwery zgodne muszą dostarczać numery tych SCTów do klientów TLS. Może do tego dojść na kilka różnych sposobów:

- - - -

Przy rozszerzeniu certyfikatu X.509 o włączonych SCTsach decydują organy certyfikujące. Przy stosowaniu tego typu mechanizmu nie powinna istnieć potrzeba modyfikacji serwerów webowych.

- -

W przypadku ostatnich metod serwery powinny być aktualizowane, aby móc wysyłać żądane dane. Korzyść stanowi fakt, że operator serwera może modyfikować źródła rejestru CT dostarczając SCTsy wysyłane przez rozszerzenie TLS/"zszytą" odpowiedź OCSP.

- -

Wymagania przeglądarki

- -

Google Chrome wymaga umieszczania rejestru CT dla wszystkich kwestii związanych z emisjami certyfkatów z datą notBefore po 30 kwietnia 2018 roku. Użytkownicy zostaną uchronieni przed odwiedzaniem stron używających niezgodnych certyfikatów TLS. Wcześniej Chrome wymagało umieszczania Rozszerzonej Walidacji (EV) oraz certyfikatów wydawanych przez Symantec.

- -

Apple wymaga zróżnicowanej liczby SCTsów dla Safari i innych serwerów celem zaufania certyfikatom.

- -

Firefox aktualnie ani nie sprawdza ani nie wymaga stosowania rejestru CT dla stron odwiedzanych przez użytkowników.

- -

Nagłówek Expect-CT może zostać użyty do żądania, by przeglądarka zawsze wymuszała wymóg przejrzystości certyfikacji (np. w Chrome nawet, jeśli certyfikat został wydany z datą notBefore, przed kwietniem)

- -

Specyfikacje

- - - - - - - - - - - - - - -
SpecyfikacjaStatusKomentarz
Certificate TransparencyIETF RFC
diff --git "a/files/pl/web/bezpiecze\305\204stwo/index.html" "b/files/pl/web/bezpiecze\305\204stwo/index.html" deleted file mode 100644 index 0d3cdd2c07..0000000000 --- "a/files/pl/web/bezpiecze\305\204stwo/index.html" +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Bezpieczeństwo aplikacji WWW -slug: Web/Bezpieczeństwo -tags: - - Bezpieczeństwo - - Web - - bezpieczeństwo aplikacji WWW -translation_of: Web/Security ---- -
-

Zapewnienie bezpieczeństwa Twojej strony lub aplikacji WWW jest niezwykle istotne. Nawet proste błędy w kodzie mogą skutkować wyciekiem prywatnych danych i ich kradzieżą przez nieodpowiednie osoby. Wymienione tutaj artykuły dot. bezpieczeństwa aplikacji WWW dostarczą Ci informacji, które mogą okazać się pomocne w zabezpieczeniu Twojej strony i jej kodu przez atakami i kradzieżą danych.

-
- -

{{LandingPageListSubpages}}

- -

Zobacz również

- - - -

{{QuickLinksWithSubpages}}

diff --git "a/files/pl/web/bezpiecze\305\204stwo/podstawy_bezpieczenstwa_informacji/index.html" "b/files/pl/web/bezpiecze\305\204stwo/podstawy_bezpieczenstwa_informacji/index.html" deleted file mode 100644 index 93555b6a71..0000000000 --- "a/files/pl/web/bezpiecze\305\204stwo/podstawy_bezpieczenstwa_informacji/index.html" +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Podstawy bezpieczeństwa informacji -slug: Web/Bezpieczeństwo/Podstawy_bezpieczenstwa_informacji -tags: - - Bezpieczeństwo - - Początkujący - - bezpieczeństwo aplikacji WWW -translation_of: Web/Security/Information_Security_Basics ---- -

Podstawowa znajomość bezpieczeństwa informacji może pomóc Ci uniknąć pozostawiania Twojego oprogramowania i stron WWW niezabezpieczonych oraz zawierających podatności, które później mogą zostać wykorzystane do osiągnięcia korzyści finansowych lub do innych, podejrzanych celów. Te arykuły mogą Ci pomóc zdobyć potrzebną bazę wiedzy.Dzięki zapoznaniu się z nimi będziesz świadomy/a, jak ważne jest bezpieczeństwo podczas tworzenia stron WWW oraz podczas implementacji treści.

- -
-
Poufność, Integralność i Dostępność
-
-

Opisuje najważniejsze cele bezpieczeństwa, które są absolutnie niezbędne do zrozumienia istoty bezpieczeństwa

-
-
Podatności
-
Definiuje główne kategorie podatności i omawia obecność podatności w każdym oprogramowaniu
-
Zagrożenia
-
Krótko przedstawia główne zagrożenia
-
Kontrole Bezpieczeństwa
-
Definiuje główne kategorie kontroli bezpieczeństwa i omawia ich potencjalne wady
-
Bezpieczeństwo TCP/IP
-
Zarys modelu TCP/IP z naciskiem na aspekty bezpieczeństwa SSL
-
- -

Zobacz również

- - - -

{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}

diff --git "a/files/pl/web/bezpiecze\305\204stwo/same-origin_policy/index.html" "b/files/pl/web/bezpiecze\305\204stwo/same-origin_policy/index.html" deleted file mode 100644 index 23f296444e..0000000000 --- "a/files/pl/web/bezpiecze\305\204stwo/same-origin_policy/index.html" +++ /dev/null @@ -1,277 +0,0 @@ ---- -title: Reguła tego samego pochodzenia (Same-origin policy) -slug: Web/Bezpieczeństwo/Same-origin_policy -tags: - - Bezpieczeństwo - - CORS - - Host - - JavaScript - - Same-origin policy - - URL - - origin - - pochodzenie - - reguła tego samego pochodzenia - - źródło -translation_of: Web/Security/Same-origin_policy ---- -

Same-origin policy (reguła tego samego pochodzenia) to istotny mechanizm bezpieczeństwa, który określa sposób, w jaki dokument lub skrypt jednego pochodzenia ({{Glossary("origin")}}) może komunikować się z zasobem innego pochodzenia. Pozwala to na odizolowanie potencjalnie szkodliwych dokumentów i tym samym redukowane są czynniki sprzyjające atakom.

- -

Definicja "origin"

- -

Dwa URLe są tego samego pochodzenia, jeśli {{Glossary("protocol")}}, {{Glossary("port")}} (jeśli wyszczególniony) oraz {{Glossary("host")}} są takie same dla obu. Tego typu charakterystykę nazywa się "krotką schematu/hosta/portu" ("scheme/host/port tuple") lub po prostu "krotką" ("Krotka" to kolekcja elementów tworzących zbiór - generyczna forma, która może być podwójna/potrójna/poczwórna itd.).

- -

Poniższa tabela zawiera przykłady zestawień "originów" z URLem http://store.company.com/dir/page.html:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
URLWynikPowód
http://store.company.com/dir2/other.htmlSame originRóżni się tylko ścieżka
http://store.company.com/dir/inner/another.htmlSame originRóżni się tylko ścieżka
https://store.company.com/page.htmlNiepowodzenieInny protokół
http://store.company.com:81/dir/page.htmlNiepowodzenieInny port (http:// domyślnie jest portem 80)
http://news.company.com/dir/page.htmlNiepowodzenieInny host
- -

Zobacz również definicję "origin" dla URLów file:, ich zestawienie jest bardziej złożone.

- -

Odziedziczone "origin"

- -

Skrypty wywoływane przez strony z URLami about:blank lub javascript: dziedziczą "origin" dokumentu zawierającego ten URL, ponieważ tego typu URLe nie zawierają informacji o serwerze źródłowym.

- -
-

Przykładowo, about:blank jest często używany jako URL nowego, pustego, wyskakującego okienka, w którym skrypt-rodzic umieszcza treść (np. przez mechanizm {{domxref("Window.open()")}}). Jeśli dane okienko zawiera również JavaScript, skrypt odziedziczy ten sam "origin" jak skrypt, który je utworzył.

-
- -
-

data: URLe zyskują nowy, pusty kontekst bezpieczeństwa.

-
- -

Wyjątki w Internet Explorer

- -

W Internecie Explorerze istnieją dwa wyjątki od reguły same-origin:

- -
-
Strefy Zaufania
-
Jeśli obie domeny znajdują się w strefie wysokiego zaufania (np. firmowe domeny intranetu), wówczas ograniczenia same-origin nie są stosowane.
-
Port
-
IE nie bierze pod uwagę portów w trakcie sprawdzania obecności tego samego pochodzenia. Przykładowo, https://company.com:81/index.html i https://company.com/index.html są uznawane za posiadające ten sam "origin", więc nie są implementowane żadne ograniczenia .
-
- -

Wspomniane wyjątki są niestandardowe i nie są wspierane przez inne przeglądarki.

- -

Zmiana origin

- -

Strona może zmieniać swoje pochodzenie przy zachowaniu pewnych ograniczeń. Skrypt może nadać wartość {{domxref("document.domain")}} równą swojej obecnej domenie lub superdomenie swojej obecnej domeny. Jeśli odwołuje się do superdomeny obecnej domeny, wówczas krótsza superdomena jest brana pod uwagę przy kontroli same-origin.

- -

Załóżmy, że skrypt z dokumentu pod adresem http://store.company.com/dir/other.html wywołuje poniższą linijkę:

- -
document.domain = "company.com";
-
- -

Następnie strona może przejść pomyślnie kontrolę same-origin mając adres http://company.com/dir/page.html (przyjmując, że http://company.com/dir/page.html ma document.domain równe "company.com" by wskazać, że chce na to zezwalać - sprawdź: {{domxref("document.domain")}}). Jednakże, company.com nie może ustawić document.domain na othercompany.com, ponieważ nie jest to superdomena company.com.

- -

Numer portu jest sprawdzany oddzielnie przez przeglądarkę. Każde odwołanie do document.domain, w tym document.domain = document.domain, spowoduje przypisanie numerowi portu wartości null. Jednakże, nie uda się nawiązać komunikacji company.com:8080 z company.com tylko poprzez umieszczenie document.domain = "company.com" w pierwszym z nich. Taki zapis musi znajdować się w obu dokumentach, aby ich porty były równocześnie równe null.

- -
-

Zauważ: Używając document.domain , żeby pozwolić subdomenie na bezpieczny dostęp do rodzica potrzebujesz ustawić document.domain na tę samą wartość jednocześnie w domenie rodzica i w subdomenie. Jest to wymagane nawet podczas zwykłego przywracania domeny rodzica do pierwotnej wartości. Niepowodzenie może skutkować błędami dostępu.

-
- -

Dostęp sieciowy cross-origin (międzyźródłowy)

- -

Reguła tego samego pochodzenia kontroluje interakcje pomiędzy dwoma różnymi "originami", np. kiedy używasz elementu {{domxref("XMLHttpRequest")}} czy {{htmlelement("img")}}. Tego typu interakcje przeważnie dzielą się na trzy kategorie:

- - - -

Poniżej znajdują się przykłady zasobów, które można osadzać międzyźródłowo:

- - - -

Jak umożliwić dostęp cross-origin

- -

Poprzez CORS można zezwolić na dostęp cross-origin. CORS jest częścią {{Glossary("HTTP")}}, co pozwala serwerom na określanie, które hosty są upoważnione do ładowania treści z tego serweru.

- -

Jak zablokować dostęp cross-origin

- - - -

Dostęp cross-origin API skryptu

- -

API JavaScriptu, jak {{domxref("HTMLIFrameElement.contentWindow", "iframe.contentWindow")}}, {{domxref("window.parent")}}, {{domxref("window.open")}} i {{domxref("window.opener")}} pozwalają dokumentom na bezpośrednią, wzajemną referencję. Jeśli dwa dokumenty nie są tego samego pochodzenia, referencje te umożliwiają bardzo ograniczony dostęp do obiektów {{domxref("Window")}} i {{domxref("Location")}}, jako opisano w następnych dwóch sekcjach.

- -

Do komunikacji pomiędzy dokumentami o różnym pochodzeniu stosuje się {{domxref("window.postMessage")}}.

- -

Specyfikacja: Standard HTML § Obiekty cross-origin.

- -

Window

- -

Poniższy dostęp cross-origin jest dopuszczany w przypadku wymienionych właściwości Window:

- - - - - - - - - - - - - - - - - - - - - -
Metody
{{domxref("window.blur")}}
{{domxref("window.close")}}
{{domxref("window.focus")}}
{{domxref("window.postMessage")}}
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Własności
{{domxref("window.closed")}}Tylko do odczytu.
{{domxref("window.frames")}}Tylko do odczytu.
{{domxref("window.length")}}Tylko do odczytu.
{{domxref("window.location")}}Odczyt/Zapis.
{{domxref("window.opener")}}Tylko do odczytu.
{{domxref("window.parent")}}Tylko do odczytu.
{{domxref("window.self")}}Tylko do odczytu.
{{domxref("window.top")}}Tylko do odczytu.
{{domxref("window.window")}}Tylko do odczytu.
- -

Niektóre przeglądarki zezwalają na dostęp większej ilości właściwości, niż wypisane powyżej.

- -

Location

- -

Poniższy dostęp cross-origin jest dopuszczany w przypadku właściwości Location:

- - - - - - - - - - - - -
Metody
{{domxref("location.replace")}}
- - - - - - - - - - - - - - -
Atrybuty
{{domxref("URLUtils.href")}}Tylko do zapisu.
- -

Niektóre przeglądarki umożliwiają dostęp do większej liczby właściwości, niż wymienione powyżej.

- -

Dostęp cross-origin do danych pamięci

- -

Dostęp do danych przechowywanych w przeglądarce, jak localStorage czy IndexedDB są odseparowane pochodzeniem. Każdy origin otrzymuje własną, odseparowaną pamięć i JavaScript jednego pochodzenia nie może odczytywać lub wpisywać niczego do pamięci należącej do innego originu.

- -

Ciasteczka (cookies) używają oddzielnej definicji originów. Strona może ustalić ciasteczko dla własnej domeny lub domeny-rodzica dopóki, gdy domena-rodzic nie jest sufiksem publicznym. Firefox i Chrome używają listy sufiksów publicznych (Public Suffix List), by zweryfikować czy domena jest sufiksem publicznym. Internet Explorer używa własnej, wewnątrznej metody weryfikacji czy domena jest sufiksem publicznym. Przeglądarka udostępni ciasteczko podanej domenie zawierającej jakiekolwiek subdomeny, niezależnie jaki protokół (HTTP/HTTPS) czy port jest używany. Przy ustalaniu ciasteczka możliwe jest określenie limitu dostępności używając flag domeny (Domain), ścieżki (Path), bezpiecznej (Secure) i Http-Only. Gdy odczytywane jest ciasteczko nie można zobaczyć, gdzie zostało ustalone. Nawet jeśli używane są wyłącznie bezpieczne połączenia https dane ciasteczko mogło zostać ustalone poprzez połączenie niebezpieczne.

- -

Zobacz również

- - - -
-

Informacje dot. dokumentu źródłowego

- - -
- -

{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}

diff --git "a/files/pl/web/bezpiecze\305\204stwo/subresource_integrity/index.html" "b/files/pl/web/bezpiecze\305\204stwo/subresource_integrity/index.html" deleted file mode 100644 index 69f20709ec..0000000000 --- "a/files/pl/web/bezpiecze\305\204stwo/subresource_integrity/index.html" +++ /dev/null @@ -1,163 +0,0 @@ ---- -title: Integralność podzasobów (Subresource Integrity) -slug: Web/Bezpieczeństwo/Subresource_Integrity -tags: - - Bezpieczeństwo - - HTML - - HTTP - - Wstęp - - bezpieczeństwo aplikacji WWW -translation_of: Web/Security/Subresource_Integrity ---- -

Subresource Integrity (SRI), w wolnym tłumaczeniu "integralność podzasobów", to funkcja bezpieczeństwa umożliwiająca przeglądarkom weryfikowanie, czy zasoby, które przechwytują (np. z CDN) docierają do nich bez nieporządanych zmian. Działanie takie jest możliwe dzięki używaniu hasha kryptograficznego, z którym przechwycony zasób musi być zgodny.

- -
-

Notka: W celu weryfikacji integralności podzasobów danych przekazywanych ze źródła innego, niż dokument w którym są osadzane przeglądarki dodatkowo sprawdzają źródło poprzez międzyźródłowe udostępnianie zasobów, tzw. Cross-Origin Resource Sharing (CORS). Dzięki temu upewniają się, że pochodzenie (origin) oferujące dane zasoby pozwala na udostępnianie ich z innym, sprecyfizowanym originem.

-
- -

Korzyści wynikające z "Subresource Integrity"

- -

Używając {{Glossary("CDN", "Content Delivery Networks (CDNs)")}} do hostowania plików, jak np. skrypty czy arkusze stylów, które są udostępnianie pośród licznych stron WWW można polepszyć wydajność strony i zachować przepustowość łącza. Jednakże, używając CDNów ryzykujemy, że jeśli atakujący przejmie kontrolę nad CDNem to może wprowadzić szkodliwą zawartość do plików na CDNie (lub zupełnie je zastąpić) i przez to potencjalnie może zaatakować wszystkie strony, które przechwytują pliki z tego CDNu.

- -

"Subresource Integrity" pozwala na ograniczenie ryzyka ataków tego typu poprzez zapewnienie, że pliki które dana aplikacja, bądź dokument WWW przechwytują (m. in. z CDNu) zostały dostarczone bez udziału trzeciej strony, która "wzbogaciła" nasze dane o dodatkową treść oraz bez żadnych, jakichkolwiek innych zmian w przesyłanych plikach.

- -

Używanie "Subresource Integrity"

- -

Korzystanie z funkcji "Subresource Integrity" jest możliwe przez określenie hasha zakodowanego kryptograficznie w base64 zasobu (pliku), który przeglądarka ma przechwycić, z wartością atrybutu integrity danego elementu {{HTMLElement("script")}} or {{HTMLElement("link")}}.

- -

Wartość integrity zaczyna się od co najmniej jednego stringu, przy czym każdy string zawiera prefiks wskazujący na konkretny algorytm hashowy (obecnie dozwolonymi prefiksami są sha256, sha384, i sha512), następnie opatrzony myślnikiem i zakończony aktualnym hashem zakodowanym w base64.

- -
-

Notka: Wartość integrity może zawierać liczne hashe oddzielone białymi znakami. Zasób zostanie załadowany, jeśli dopasuje się z jednym z tych hashów.

-
- -

Przykładowy string integrity z hashem sha384 zakodowanym w base64:

- -
sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC
-
- -

Więc oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC to część "hashowa", a prefiks sha384 wskazuje, że jest to hash sha384.

- -
-

Notka: Część "hashowa" wartości integrity jest, mówić ściśle, skrótem kryptograficznym formowanym przez zastosowanie określonych funkcji hashowych do danego outputu (np. skryptu lub arkuszu stylów). Zwykle używa się skrótu "hash" do określania skrótu kryptograficznego, więc w taki sposób to określenie jest używane w niniejszym artykule.

-
- -

Narzędzia do generowania hashów SRI

- -

Możesz generować hashe SRI z konsoli z openssl używając wywołania polecenia, jak:

- -
cat FILENAME.js | openssl dgst -sha384 -binary | openssl base64 -A
- -

lub z shasum używając wywołania polecenia, jak:

- -
shasum -b -a 384 FILENAME.js | awk '{ print $1 }' | xxd -r -p | base64
-
- -
-

Notka:

- - -
- -

Warto wiedzieć, że dostępny na https://www.srihash.org/ SRI Hash Generator to narzędzie online umożliwiające generowanie hashy SRI.

- -

Zasady bezpieczeństwa zawartości i Integralności podzasobów(Content Security Policy & Subresource Integrity)

- -

Możesz skorzystać z Zasad bezpieczeństwa zawartości (Content Security Policy), by skonfigurować swój serwer, żeby wymuszał by określone typy plików wymagały stosowania Subresource Integrity. Aby to zrobić użyj dyrektywy {{CSP("require-sri-for")}} w swoim nagłówku CSP, np.:

- -
Content-Security-Policy: require-sri-for script;
- -

Dzięki temu zapisowi każda próba załadowania JavaScript powiedzie się jedynie, jeśli informacja o Subresource Integrity znajduje się na miejscu, a testy integralności zakończą się sukcesem.

- -

Możesz również określić, że SRI powinno być stosowane podczas ładowania arkuszy stylów:

- -
Content-Security-Policy: require-sri-for style;
- -

Możesz również określić zarówno script, jak i style aby wymagać SRI przy obu typach plików.

- -

Udostępnianie zasobów między źródłami i Integralności podzasobów (Cross-Origin Resource Sharing & Subresource Integrity)

- -

Celem weryfikacji integralności podzasobów danych pochodzących z originu innego, niż dokument, w którym są osadzone, przeglądarki dodatkowo sprawdzają dane za pomocą CORS (Cross-Origin Resource Sharing). Upewniają się, że origin dostarczający dane pozwala na udostępnianie wnioskującemu originowi. Wtedy dane muszą zostać dostarczone z nagłówkiem Access-Control-Allow-Origin, co pozwala na udostępnienie danych wnioskującemu originowi, np.:

- -
Access-Control-Allow-Origin: *
- -

Przykłady

- -

W poniższych przykładach przyjmimy, że oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC to oczekiwany hash SHA-384 (skrót) określonego skryptu example-framework.js i że istnieje kopia skryptu hostowana na https://example.com/example-framework.js.

- -

Subresource Integrity with the <script> element

- -

Możesz użyć niniejszego elementu {{HTMLElement("script")}}, by nakazać przeglądarce, aby przed wywołaniem skryptu https://example.com/example-framework.js najpierw porównała skrypt z oczekiwanym hashem i zweryfikowała, że są dopasowane.

- -
<script src="https://example.com/example-framework.js"
-        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
-        crossorigin="anonymous"></script>
- -
-

Notka: By dowiedzieć się więcej nt. zastosowania atrybutu crossorigin sprawdź atrybuty ustawień CORS.

-
- -

Jak przeglądarki radzą sobie z "Subresource Integrity"

- -

Przeglądarki radzą sobie z SRI poprzez podjęcie poniższych działań:

- -
    -
  1. -

    Kiedy przeglądarka napotka element {{HTMLElement("script")}} lub {{HTMLElement("link")}} z atrybutem integrity, przed wywołaniem skryptu lub przed zastosowaniem jakiegokolwiek arkusza stylów określonego przez element {{HTMLElement("link")}}, przeglądarka musi najpierw porównać skrypt lub arkusz stylów do oczekiwanego hasha podanego w wartości integrity.

    - -

    Notka: Celem weryfikacji integralności podzasobów danych dostarczanych z originu innego, niż dokument, w którym zostały osadzone, przeglądarki dodatkowo sprawdzają dane poprzez stosowanie CORS, aby upewnić się, że origin dostarczający dane pozwala na udostępnianie ich z wnioskującym originem.

    -
    2. -
  2. Jeśli skrypt lub arkusz stylów nie pasuje do odpowiadającej mu wartości integrity, przeglądarka musi odmówić wywołania skryptu lub uwzględnienia arkusza stylów i zamiast tego musi zwrócić błąd sieciowy wskazujący, że nie powiodło się przechwycenie tego skryptu lub arkusza stylów.
    3. -
- -

Specyfikacje

- - - - - - - - - - - - - - - - - - - - - -
SpecyfikacjaStatusKomentarz
{{SpecName('Subresource Integrity')}}{{Spec2('Subresource Integrity')}}
{{SpecName('Fetch')}}{{Spec2('Fetch')}}
- -

Kompatybilność z przeglądarkami

- -

<script integrity>

- - - -

{{Compat("html.elements.script.integrity")}}

- -

CSP: require-sri-for

- - - -

{{Compat("http.headers.csp.require-sri-for")}}

- -

Zobacz również

- - - -

{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}

-- cgit v1.2.3-54-g00ecf