Aktualizacje
- 7 lipca 2022 roku: zaktualizowaliśmy bieżący stan i dodaliśmy definicję przestrzeni adresów IP.
- 27 kwietnia 2022 roku: zaktualizowaliśmy ogłoszenie związane z harmonogramem.
- 7 marca 2022 r.: ogłoszono przywrócenie poprzedniej wersji aplikacji po wykryciu problemów w Chrome 98.
Wstęp
Chrome wycofuje bezpośredni dostęp z witryn publicznych do punktów końcowych sieci prywatnej w ramach specyfikacji Private Network Access (PNA).
Chrome zacznie wysyłać żądanie procesu wstępnego CORS przed każdym żądaniem sieci prywatnej dla zasobu podrzędnego, które będzie prosić o jawne uprawnienia od serwera docelowego. To żądanie procesu wstępnego będzie zawierać nowy nagłówek (Access-Control-Request-Private-Network: true), a odpowiedź na niego musi zawierać odpowiedni nagłówek: Access-Control-Allow-Private-Network: true.
Ma to na celu ochronę użytkowników przed atakami polegającymi na sfałszowaniu żądania z innych witryn (CSRF), które są kierowane na routery i inne urządzenia w sieciach prywatnych. Takie ataki obejmowały setki tysięcy użytkowników, umożliwiając hakerom przekierowanie ich na złośliwe serwery.
Plan wdrożenia
Chrome będzie wprowadzać tę zmianę w 2 fazach, aby dać witrynom czas na jej zauważenie i odpowiednie dostosowanie.
W Chrome 104:
- Wysyłając żądania wstępne dotyczące eksperymentów w Chrome przed żądaniami podzasobów w sieci prywatnej.
- Błędy procesów wstępnych wyświetlają tylko ostrzeżenia w Narzędziach deweloperskich i nie mają żadnego innego wpływu na żądania w sieci prywatnej.
- Chrome gromadzi dane dotyczące zgodności i kontaktuje się z największymi witrynami, których dotyczy problem.
- Oczekujemy, że taka zmiana będzie w dużym stopniu zgodna z dotychczasowymi witrynami.
W Chrome 113 (najwcześniej):
- Ten proces rozpocznie się tylko wtedy, gdy dane dotyczące zgodności wskazują, że zmiana jest wystarczająco bezpieczna, a w razie potrzeby skontaktowaliśmy się z Tobą bezpośrednio.
- Chrome egzekwuje, aby żądania wstępne muszą się udać. W przeciwnym razie nie zostaną zrealizowane.
- Jednocześnie rozpoczyna się okres próbny wycofywania, aby właściciele witryn, których dotyczy ten etap, mogli poprosić o wydłużenie terminu. Okres próbny będzie trwał co najmniej 6 miesięcy.
Co to jest dostęp do sieci prywatnej (PNA)
Dostęp do sieci prywatnej (dawniej CORS-RFC1918) ogranicza możliwość wysyłania przez witryny żądań do serwerów w sieciach prywatnych.
W Chrome jest już wdrożona część specyfikacji: od Chrome 96 żądania z sieci prywatnej mogą wysyłać tylko zabezpieczone konteksty. Więcej informacji znajdziesz w poprzednim poście na blogu.
Specyfikacja rozszerza też protokół CORS, dzięki czemu witryny muszą teraz wyraźnie żądać przyznania od serwerów w sieciach prywatnych, zanim będą mogły wysyłać dowolne żądania.
Jak PNA klasyfikuje adresy IP i identyfikuje sieć prywatną
Adresy IP są klasyfikowane na 3 przestrzenie adresów IP:
– public
– private
– local
Lokalna przestrzeń adresów IP zawiera adresy IP, które są adresami IP w pętli IPv4 (127.0.0.0/8) zdefiniowane w sekcji 3.2.1.3 w RFC1122 lub adresach IPv6 typu loopback (::1/128) zdefiniowanych w sekcji 2.5.3 w RFC4291.
Prywatna przestrzeń adresów IP zawiera adresy IP, które mają znaczenie tylko w bieżącej sieci, w tym adresy 10.0.0.0/8, 172.16.0.0/12 i 192.168.0.0/16 zdefiniowane w RFC1918, adresy lokalne 169.254.0.0/16 zdefiniowane w RFC3927, unikalne lokalne adresy unicastu IPv6 fc00::/7 zdefiniowane w RFC4193,
w sekcji RFC4193
zdefiniowane w polu RFC4193 prywatne adresy IPv6 IPv6 zmapowane jako prywatne adresy IPv6 zmapowane .fe80::/10RFC4291
Publiczna przestrzeń adresów IP zawiera wszystkie inne adresy, które nie zostały wcześniej wymienione.
Lokalny adres IP jest uważany za bardziej prywatny niż prywatny adres IP, który jest uważany za bardziej prywatny niż publiczny adres IP.
Więcej informacji znajdziesz w artykule na temat wymagania opinii: CORS dla sieci prywatnych (RFC1918).
Żądania procesów wstępnych
Wprowadzenie
Żądania wstępne to mechanizm wprowadzony przez standard CORS, który służy do wysyłania próśb o uprawnienia do witryny docelowej przed wysłaniem do niej żądania HTTP, które może mieć skutki uboczne. Dzięki temu serwer docelowy rozumie protokół CORS, co znacznie zmniejsza ryzyko ataków CSRF.
Żądanie uprawnień jest wysyłane jako żądanie HTTP OPTIONS z określonymi nagłówkami żądania CORS opisującymi nadchodzące żądanie HTTP. Odpowiedź musi zawierać konkretne nagłówki odpowiedzi CORS z wyraźną zgodą na nadchodzące żądanie.
Co nowego w sekcji Dostęp do sieci prywatnej
W żądaniach wstępnych wprowadzono nową para nagłówków żądań i odpowiedzi:
Access-Control-Request-Private-Network: truejest ustawiony we wszystkich żądaniach wstępnych PNA- We wszystkich odpowiedziach wstępnych PNA należy ustawić
Access-Control-Allow-Private-Network: true
Żądania wstępne dotyczące PNA są wysyłane w przypadku wszystkich żądań sieci prywatnej, niezależnie od metody i trybu żądania. Są one wysyłane z wyprzedzeniem żądań w trybie cors, a także w trybach no-cors i wszystkich innych trybach. Dzieje się tak, ponieważ do ataków CSRF można używać wszystkich żądań w sieci prywatnej niezależnie od trybu żądania i tego, czy treść odpowiedzi jest udostępniana inicjatorowi.
Żądania wstępne dotyczące PNA są też wysyłane w przypadku żądań z tego samego pochodzenia, jeśli docelowy adres IP jest bardziej prywatny niż inicjator. Różni się to od zwykłych CORS, gdzie żądania wstępne dotyczą tylko żądań z innych domen. Żądania wstępne dotyczące żądań z tej samej domeny chronią przed atakami rebindingu DNS.
Przykłady
Dostrzegalne zachowanie zależy od trybu żądania.
Tryb bez CORS
Powiedzmy, że https://foo.example/index.html zawiera adres <img src="https://bar.example/cat.gif" alt="dancing cat"/>, a bar.example prowadzi do 192.168.1.1 – prywatnego adresu IP zgodnego z RFC 1918.
Chrome najpierw wysyła żądanie procesu wstępnego:
HTTP/1.1 OPTIONS /cat.gif
Origin: https://foo.example
Access-Control-Request-Private-Network: true
Aby to żądanie zostało zrealizowane, serwer musi udzielić odpowiedzi:
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Private-Network: true
Następnie Chrome wyśle właściwe żądanie:
HTTP/1.1 GET /cat.gif
...
Na który serwer może odpowiadać normalnie.
Tryb CORS
Powiedzmy, że https://foo.example/index.html uruchamia ten kod:
await fetch('https://bar.example/delete-everything', {
method: 'PUT',
credentials: 'include',
})
Powtórz polecenie: bar.example zmienia się na 192.168.1.1.
Chrome najpierw wysyła żądanie procesu wstępnego:
HTTP/1.1 OPTIONS /delete-everything
Origin: https://foo.example
Access-Control-Request-Method: PUT
Access-Control-Request-Credentials: true
Access-Control-Request-Private-Network: true
Aby to żądanie zostało zrealizowane, serwer musi udzielić odpowiedzi:
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Credentials: true
Access-Control-Allow-Private-Network: true
Następnie Chrome wyśle właściwe żądanie:
HTTP/1.1 PUT /delete-everything
Origin: https://foo.example
Na który serwer może odpowiadać zgodnie ze zwykłymi regułami CORS:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://foo.example
Jak sprawdzić, czy ma to wpływ na Twoją witrynę
Od wersji Chrome 104 w przypadku wykrycia żądania sieci prywatnej będzie przed nim wysyłane żądanie wstępne. Jeśli to żądanie procesu wstępnego nie powiedzie się, ostatnie żądanie zostanie wysłane, ale w panelu problemów z Narzędziami deweloperskimi pojawi się ostrzeżenie.
Żądania procesów wstępnych, których to dotyczy, można też wyświetlić i zdiagnozować w panelu sieci:
Jeśli Twoje żądanie wywołałoby standardowy proces wstępny CORS bez reguł dostępu do sieci prywatnej, w panelu sieci mogą pojawić się 2 procesy wstępne, z których pierwszy z nich zawsze tak się stanie. To znany błąd, który możesz bezpiecznie zignorować.
Aby sprawdzić, co się stanie, jeśli proces wstępny zostanie wymuszony, możesz przekazać ten argument wiersza poleceń (od Chrome 98):
--enable-features=PrivateNetworkAccessRespectPreflightResults
Każde nieudane żądanie procesu wstępnego kończy się niepowodzeniem pobierania. W ten sposób możesz sprawdzić, czy witryna będzie działać po drugiej fazie planu wdrożenia. Błędy mogą być diagnozowane tak samo jak ostrzeżenia za pomocą wspomnianych wyżej paneli Narzędzi dla programistów.
Co zrobić, jeśli wpłynie to na Twoją witrynę
Po wprowadzeniu tej zmiany w Chrome 104 nie powinna ona powodować problemów w żadnej witrynie. Zdecydowanie zalecamy jednak zaktualizowanie ścieżek żądań, których dotyczy ten problem, aby mieć pewność, że Twoja witryna będzie nadal działać zgodnie z oczekiwaniami.
Dostępne są 2 rozwiązania:
- Obsługuj żądania procesów wstępnych po stronie serwera
- Wyłącz sprawdzanie PNA za pomocą zasad przedsiębiorstwa
Obsługuj żądania procesów wstępnych po stronie serwera
Zaktualizuj serwer docelowy wszystkich pobrań, których dotyczy problem, aby obsługiwać żądania wstępne PNA. Najpierw zaimplementuj obsługę standardowych żądań procesu wstępnego CORS w przypadku tras, których dotyczy problem. Następnie dodaj obsługę 2 nowych nagłówków odpowiedzi.
Gdy serwer otrzyma żądanie procesu wstępnego (żądanie OPTIONS z nagłówkami CORS), powinien sprawdzić, czy nie ma nagłówka Access-Control-Request-Private-Network: true. Jeśli żądanie zawiera ten nagłówek, serwer powinien sprawdzić nagłówek Origin i ścieżkę żądania oraz inne istotne informacje (np. Access-Control-Request-Headers), aby upewnić się, że żądanie jest bezpieczne.
Zwykle wystarczy zezwolić na dostęp do jednego źródła, które masz pod Twoją kontrolą.
Gdy serwer zezwoli na żądanie, powinien odpowiedzieć 204 No Content (lub 200 OK), podając niezbędne nagłówki CORS i nowy nagłówek PNA. W razie potrzeby możesz dodać nagłówki Access-Control-Allow-Origin, Access-Control-Allow-Private-Network: true i inne.
Konkretne scenariusze znajdziesz w przykładach.
Wyłącz sprawdzanie dostępu do sieci prywatnej przy użyciu zasad przedsiębiorstwa
Jeśli masz kontrolę administracyjną nad użytkownikami, możesz wyłączyć kontrole dostępu do sieci prywatnej za pomocą jednej z tych zasad:
Więcej informacji znajdziesz w artykule Omówienie zarządzania zasadami Chrome.
Podziel się opinią
Jeśli hostujesz witrynę w sieci prywatnej, która oczekuje żądań z sieci publicznych, zespół Chrome zapozna się z Twoimi opiniami i przypadkami użycia.
Daj nam znać, zgłaszając problem w Chromium na stronie crbug.com, i ustaw komponent Blink>SecurityFeature>CORS>PrivateNetworkAccess.
Co dalej
Następnie rozszerzymy zakres sprawdzania dostępu do sieci prywatnej na instancje robocze: dedykowane instancje robocze, instancje robocze udostępnione i mechanizmy Service Worker. Wstępnie planujemy zacząć wyświetlać ostrzeżenia w Chrome 107.
Następnie rozszerzymy zakres sprawdzania dostępu do sieci prywatnej na elementy nawigacyjne, w tym elementy iframe i wyskakujące okienka. Wstępnie planujemy zacząć wyświetlać ostrzeżenia w Chrome 108.
W obu przypadkach będziemy ostrożnie wdrażać podobne etapy wdrażania, aby dać deweloperom stron internetowych czas na dostosowanie się i oszacowanie ryzyka związanego ze zgodnością.
Podziękowania
Autor zdjęcia: Mark Olsen, strona Unsplash.