Nowości
23 marca 2023 r.: zaktualizowaliśmy harmonogram i wycofanie funkcji nastąpi dopiero w Chrome 117.
19 stycznia 2023 r.: zaktualizowaliśmy harmonogram i wycofanie nie nastąpi przed wersją Chrome 114.
12 sierpnia 2022 r.: zaktualizowaliśmy harmonogram i wycofanie zostanie wprowadzone dopiero w Chrome 109.
10 lutego 2022 r.: opublikowaliśmy zaktualizowany artykuł Dostęp do sieci prywatnej: wprowadzenie wstępnej analizy.
25 sierpnia 2021 r.: zaktualizowaliśmy harmonogram i wprowadziliśmy okres próbny wycofania.
W ramach specyfikacji dostępu do sieci prywatnej Chrome wycofuje dostęp do punktów końcowych sieci prywatnej z niebezpiecznych witryn. Celem jest ochrona użytkowników przed atakami polegającymi na fałszowaniu żądań między witrynami (CSRF) na routerach i innych urządzeniach w sieciach prywatnych. Te ataki dotknęły setki tysięcy użytkowników, którzy zostali przekierowani na złośliwe serwery.
W Chrome wprowadzimy następujące zmiany:
- Blokowanie żądań do sieci prywatnych z niezabezpieczonych witryn publicznych od wersji Chrome 94.
- Przedstawiamy okres próbny przed wycofaniem, który zakończy się w Chrome.
- Umożliwi to deweloperom złożenie prośby o przedłużenie okresu dostępności wybranych źródeł, które nie zostaną objęte wycofaniem.
- Wprowadzamy zasadę Chrome, która pozwoli na trwałe pominięcie wycofania w przypadku zarządzanych wdrożeń Chrome. Dostępne w Chrome 92.
Jeśli potrzebujesz więcej czasu na ograniczenie wpływu wycofania na okres próbny.
Jeśli masz uprawnienia administracyjne nad użytkownikami, możesz ponownie włączyć tę funkcję za pomocą zasad Chrome.
Aby ograniczyć wpływ nowych ograniczeń, zastosuj jedną z tych strategii:
- Przekształc swoją witrynę w witrynę HTTPS, a w razie potrzeby również serwer docelowy.
- Przekształc swoją witrynę w witrynę HTTPS i używaj WebTransport
- Odwołaj relację wstawiania.
Oś czasu
- listopad 2020 r.: zachęcamy do przesyłania opinii na temat nadchodzących zmian.
- Marzec 2021 r.: po zapoznaniu się z opiniami i skontaktowaniu się z użytkownikami ogłosiliśmy nadchodzące zmiany. Specyfikacja CORS-RFC1918 została przemianowana na dostęp do sieci prywatnej.
- Kwiecień 2021 r.: wdrożenie Chrome 90 w wersji stabilnej, w której wyświetlane są ostrzeżenia o wycofaniu.
- Czerwiec 2021 r.: w Chrome 92 udostępniamy wersję beta, która blokuje żądania z sieci prywatnej z niebezpiecznych kontekstów. Po otrzymaniu opinii od deweloperów, którzy poprosili o więcej czasu na dostosowanie się do zmian, wycofanie zostało odroczone do wersji 93 Chrome. Będzie ono poprzedzone okresem testowania wycofania.
- Lipiec 2021 r.: po otrzymaniu dodatkowych opinii od programistów wycofanie i powiązane z nim testy zostały przełożone na wersję Chrome 94. Wycofanie się nie ma już wpływu na prywatne witryny.
- Sierpień 2021 r.: wersja Chrome 94 została udostępniona w wersji beta. Deweloperzy mogą zacząć rejestrować się na okres próbny przed wycofaniem.
- Wrzesień 2021 r.: wersja Chrome 94 została udostępniona w wersji stabilnej. Programiści powinni zarejestrować się w programie testowania wersji wycofywanej i wdrożyć tokeny testowe w wersji produkcyjnej.
- Grudzień 2022 r.: wysłaliśmy ankietę dotyczącą okresu próbnego Origin i otrzymaliśmy opinie. Wycofanie wersji próbnej zostało przedłużone do Chrome 113.
- Marzec 2023 r.: okres próbnego wycofywania został przedłużony do wersji Chrome 116 i ma zakończyć się w wersji 117. Trwają prace nad alternatywnym mechanizmem opartym na uprawnieniach, którego pierwsza wersja ma zostać wydana w Chrome 114.
- Maj 2023 r. (wstępnie): mechanizm oparty na uprawnieniach zostanie wdrożony w Chrome 114. Witryny mogą używać tego okresu próbnego, aby wycofać się z testów.
- Wrzesień 2023 r.: w wersji stabilnej udostępniamy Chrome 117, co oznacza zakończenie testów wycofywania. Chrome blokuje wszystkie żądania dotyczące sieci prywatnej z publicznych, niezabezpieczonych kontekstów.
Co to jest dostęp z sieci prywatnej
Dostęp do sieci prywatnej (wcześniej CORS-RFC1918) ogranicza możliwość wysyłania przez witryny żądań do serwerów w sieciach prywatnych. Zezwala na takie żądania tylko z niebezpiecznych kontekstów. Specyfikacja rozszerza też protokół udostępniania zasobów z innych źródeł (CORS), tak aby witryny musiały wyraźnie poprosić o przyznanie uprawnień przez serwery w sieciach prywatnych, zanim będą mogły wysyłać dowolne żądania.
Żądania sieci prywatnej to żądania, których docelowy adres IP serwera jest bardziej prywatny niż ten, z którego pobierano inicjatora żądania. Może to być na przykład żądanie z witryny publicznej (https://example.com) do witryny prywatnej (http://router.local) lub żądanie z witryny prywatnej do localhost.
Więcej informacji znajdziesz w artykule [Chcemy poznać Twoją opinię: mechanizm CORS dla sieci prywatnych (RFC1918)].
Co to jest przywrócenie wycofanej funkcji
Testy wycofywania (dawniej nazywane testami odwrotnej wersji) to forma testów wersji, która ułatwia wycofywanie funkcji internetowych. Testy wycofywania umożliwiają Chrome wycofanie niektórych funkcji internetowych i zapobieganie tworzeniu przez witryny nowych zależności od nich, a zarazem dają obecnym witrynom zależnym dodatkowy czas na migrację.
Podczas okresu testowego wycofywania funkcje wycofywane są domyślnie niedostępne dla wszystkich witryn. Deweloperzy, którzy nadal potrzebują tych funkcji, muszą zarejestrować się w programie testowania wersji wycofywanej i uzyskać tokeny dla określonych źródeł internetowych, a następnie zmodyfikować swoje witryny, aby wyświetlać te tokeny w nagłówkach HTTP lub metatagach (z wyjątkiem tego przypadku). Jeśli witryna udostępnia prawidłowe tokeny pasujące do ich pochodzenia, Chrome pozwoli na korzystanie z funkcji wycofanej przez ograniczony czas.
Więcej informacji znajdziesz w artykule wprowadzającym do testów pochodzenia w Chrome oraz w przewodniku dla programistów internetowych na temat testów pochodzenia.
Co się zmienia w Chrome
Chrome 94
Począwszy od wersji 94 Chrome publiczne konteksty niezabezpieczone (czyli ogólnie witryny, które nie są dostarczane przez HTTPS lub z prywatnego adresu IP) nie mogą wysyłać żądań do sieci prywatnej. Wcześniej planowaliśmy to zrobić w Chrome 92, dlatego wiadomości o wycofaniu mogą nadal wspominać wcześniejszy etap.
Wraz z wycofaniem tej funkcji rozpoczyna się okres próbny wycofywania, który pozwala deweloperom stron internetowych korzystającym z wycofanej funkcji na dalsze jej używanie do wersji Chrome 116. Aby to zrobić, muszą zarejestrować tokeny. Instrukcje rejestracji i włączenia wersji próbnej w witrynie znajdziesz poniżej.
Aby wyłączyć wycofanie na stałe lub na czas nieokreślony, możesz użyć 2 zasad Chrome. Dzięki temu zarządzane instalacje Chrome, np. te w ustawieniach korporacyjnych, mogą uniknąć uszkodzenia.
Chrome 117
Koniec okresu próbnego przed wycofaniem. Wszystkie witryny muszą zostać przeniesione z wycofanej funkcji lub ich zasady muszą być skonfigurowane w taki sposób, aby funkcja była nadal włączona.
Zalecane działania dewelopera
Pierwszym krokiem w przypadku witryn, których dotyczy problem, jest prawdopodobnie wydłużenie okresu, w którym można wdrożyć odpowiednie rozwiązanie: albo poprzez rejestrację w ramach trybuału, albo za pomocą zasad. Następnie zalecane działania różnią się w zależności od okoliczności związanych z każdą witryną.
Rejestracja w ramach okresu próbnego wycofania
- Aby uzyskać token próbny dla domeny, z której korzystasz, kliknij Zarejestruj w ramach testu dostępu do sieci prywatnej z niebezpiecznych kontekstów.
- Dodaj
Origin-Trial: $tokendla danego źródła w nagłówku odpowiedzi. Ten nagłówek odpowiedzi musi być ustawiony tylko w przypadku odpowiedzi dotyczących zasobu głównego i nawigacji, gdy wynikowy dokument korzysta z funkcji przestarzałej. Dołączanie tego nagłówka do odpowiedzi na subresursy jest bezcelowe (choć nieszkodliwe).
Ponieważ ta wersja próbna musi zostać włączona lub wyłączona, zanim dokument będzie mógł wysyłać żądania, nie można włączyć jej za pomocą tagu <meta>. Takie tagi są analizowane tylko z treści odpowiedzi po wysłaniu żądań dotyczących zasobów podrzędnych. To stanowi problem w przypadku stron, na których nie można kontrolować nagłówków odpowiedzi, np. stron statycznych github.io obsługiwanych przez osoby trzecie.
Więcej informacji znajdziesz w przewodniku dla programistów na temat testów pochodzenia.
Włącz zasady
Jeśli masz uprawnienia administracyjne do zarządzania użytkownikami, możesz ponownie włączyć przestarzałą funkcję za pomocą jednej z tych zasad:
Więcej informacji o zarządzaniu zasadami dotyczącymi użytkowników znajdziesz w tym artykule w Centrum pomocy.
Dostęp do localhost
Jeśli Twoja witryna musi wysyłać żądania do localhost, musisz przekształcić ją w witrynę HTTPS.
Żądania kierowane na http://localhost (lub http://127.*.*.*, http://[::1]) nie są blokowane przez mieszane treści, nawet gdy są wysyłane z bezpiecznych kontekstów.
Pamiętaj, że silnik WebKit i przeglądarki oparte na nim (zwłaszcza Safari) odbiegają od specyfikacji W3C dotyczącej treści mieszanych i zabraniają tych żądań jako treści mieszanych. Nie obsługują też dostępu do sieci prywatnej, więc witryny mogą przekierowywać klientów korzystających z takich przeglądarek do wersji witryny w prostym formacie HTTP, która nadal będzie mogła wysyłać żądania do localhost.
Dostęp do prywatnych adresów IP
Jeśli Twoja witryna musi wysyłać żądania do serwera docelowego za pomocą prywatnego adresu IP, nie wystarczy przekształcić witryny inicjującej w witrynę obsługującą protokół HTTPS. Treści mieszane uniemożliwiają bezpiecznym kontekstom wysyłanie żądań w czystym tekście HTTP, więc nowo zabezpieczona witryna nadal nie będzie mogła wysyłać żądań. Ten problem można rozwiązać na kilka sposobów:
- Przejdź na HTTPS po obu stronach.
- Użyj WebTransport, aby bezpiecznie połączyć się z serwerem docelowym.
- odwrócić relację między zasobami osadzonymi.
Przejdź na HTTPS po obu stronach.
To rozwiązanie wymaga kontroli nad rozwiązywaniem nazw DNS użytkowników, na przykład w kontekście intranetu lub gdy użytkownicy uzyskują adresy swoich serwerów nazw ze znajdującego się pod Twoją kontrolą serwera DHCP. Wymaga też posiadania nazwy domeny publicznej.
Głównym problemem związanym z wyświetlaniem witryn prywatnych przez HTTPS jest to, że urzędy certyfikacji infrastruktury klucza publicznego (PKI CA) udostępniają certyfikaty TLS tylko do witryn z publicznymi nazwami domen. Aby obejść ten problem:
- Zarejestruj publiczną nazwę domeny (na przykład
intranet.example) i opublikuj rekordy DNS, które wskazują na wybrany przez Ciebie publiczny serwer. - Uzyskaj certyfikat TLS dla
intranet.example. - W sieci prywatnej skonfiguruj DNS tak, aby rozwiązywał
intranet.examplena prywatny adres IP docelowego serwera. - Skonfiguruj serwer prywatny, aby używał certyfikatu TLS dla
intranet.example. Dzięki temu użytkownicy będą mogli uzyskać dostęp do serwera prywatnego pod adresemhttps://intranet.example.
Następnie możesz przejść na HTTPS w witrynie, która inicjuje żądania, i kontynuować wysyłanie żądań tak jak do tej pory.
To rozwiązanie jest przyszłościowe i zwiększa bezpieczeństwo sieci, ponieważ umożliwia korzystanie z pełnego szyfrowania w sieci prywatnej.
WebTransport
To rozwiązanie nie wymaga kontroli nad rozwiązywaniem nazw DNS użytkowników. Wymaga to, aby serwer docelowy uruchamiał minimalny serwer WebTransport (serwer HTTP/3 z pewnymi modyfikacjami).
Brak ważnego certyfikatu TLS podpisanego przez zaufany urząd certyfikacji można obejść, używając WebTransport i jego mechanizmu przypinania certyfikatu. Umożliwia to nawiązywanie bezpiecznych połączeń z urządzeniami prywatnymi, które mogą mieć na przykład samopodpisane certyfikaty. Połączenia WebTransport umożliwiają dwukierunkowy transfer danych, ale nie obsługują żądań pobierania. Możesz połączyć to podejście z użyciem usługi roboczej, aby przejrzyście przekazywać żądania HTTP przez połączenie z punktu widzenia aplikacji internetowej. Po stronie serwera odpowiednia warstwa tłumaczenia może przekształcać wiadomości WebTransport w żądania HTTP.
Zdajemy sobie sprawę, że wymaga to sporo pracy, ale powinno być znacznie łatwiejsze niż tworzenie na podstawie WebRTC. Mamy też nadzieję, że część niezbędnych inwestycji zostanie zaimplementowana jako biblioteki wielokrotnego użytku. Uważamy też, że jest to szczególnie ważne, biorąc pod uwagę fakt, że niezabezpieczone konteksty mogą z czasem tracić dostęp do coraz większej liczby funkcji platformy internetowej, ponieważ platforma będzie coraz bardziej zachęcać do korzystania z HTTPS. Niezależnie od dostępu do sieci prywatnej, jest to prawdopodobnie dobra inwestycja.
Oczekujemy, że WebTransport przez HTTP/3 zostanie udostępniony w Chrome 96 (rozpoczęliśmy testy wersji origin) z ochroną przed udostępnianiem kluczy i innymi niewystarczającymi zabezpieczeniami, w tym:
- krótki maksymalny okres ważności przypiętych certyfikatów;
- Mechanizm związany z konkretną przeglądarką umożliwiający odwoływanie niektórych kluczy, które były wykorzystywane do celów niezgodnych z przeznaczeniem.
Ograniczenie dotyczące bezpiecznego kontekstu nie zostanie wdrożone, dopóki nie osiągniemy co najmniej 2 milestones po pełnym wdrożeniu WebTransport. W razie potrzeby okres próbny zostanie przedłużony.
Odwrotne umieszczanie
To rozwiązanie nie wymaga żadnej kontroli administracyjnej nad siecią i może być używane, gdy serwer docelowy nie jest wystarczająco wydajny do obsługi HTTPS.
Zamiast pobierać prywatne zasoby podrzędne z publicznej aplikacji internetowej, szkielet aplikacji może być dostarczany z serwera prywatnego, który następnie pobiera wszystkie zasoby podrzędne (np. skrypty lub obrazy) z serwera publicznego, np. CDN. Utworzona aplikacja internetowa może następnie wysyłać żądania do serwera prywatnego, ponieważ są one uważane za pochodzące z tego samego źródła. Może nawet wysyłać żądania do innych serwerów z prywatnymi adresami IP (ale nie do hosta lokalnego), choć w długim okresie może się to zmienić.
Przechowując na serwerze prywatnym tylko szkielet, możesz aktualizować aplikację internetową, przesyłając nowe zasoby na serwer publiczny, tak jak w przypadku zwykłej aplikacji internetowej. Z drugiej strony, powstała aplikacja internetowa nie jest bezpiecznym kontekstem, więc nie ma dostępu do niektórych zaawansowanych funkcji sieci.
Plany na przyszłość
Ograniczenie żądań sieci prywatnej do bezpiecznych kontekstów to tylko pierwszy krok w drodze do wprowadzenia dostępu do sieci prywatnej. W najbliższych miesiącach będziemy pracować nad wdrożeniem pozostałych części specyfikacji. Bądź na bieżąco.
Ograniczanie dostępu do localhosta z witryn prywatnych
Zmiany w Chrome 94 mają wpływ tylko na publiczne witryny, które uzyskują dostęp do prywatnych adresów IP lub localhost. Specyfikacja dostępu do sieci prywatnej klasyfikuje również jako problematyczne żądania z prywatnych witryn do hosta lokalnego. W przyszłości Chrome również je wycofa. Stwarza to jednak nieco inne wyzwania, ponieważ wiele prywatnych witryn nie ma nazw domen, co komplikuje korzystanie z tokenów trialowych.
Żądania procesu wstępnego CORS
Druga część funkcji dostępu do sieci prywatnej polega na kontrolowaniu żądań w sieci prywatnej, które są inicjowane z bezpiecznych kontekstów za pomocą żądań wstępnych CORS. Nawet jeśli żądanie zostało zainicjowane w bezpiecznym kontekście, serwer docelowy jest proszony o wyraźne przyznanie uprawnień inicjatorowi. Prośba zostanie wysłana tylko wtedy, gdy przyznanie uprawnień zakończy się powodzeniem.
Krótko mówiąc, żądanie wstępne CORS to żądanie HTTP OPTIONS zawierające nagłówki Access-Control-Request-* wskazujące charakter kolejnego żądania. Serwer może następnie zdecydować, czy przyznać dostęp szczegółowy, odpowiadając 200 OK z nagłówkami Access-Control-Allow-*.
Więcej informacji znajdziesz w specyfikacji.
Ograniczanie pobierania danych nawigacji
Chrome wycofuje i ostatecznie zablokuje żądania zasobów podrzędnych w sieciach prywatnych. Nie będzie to miało wpływu na nawigację w sieciach prywatnych, które mogą być wykorzystywane w atakach CSRF.
Specyfikacja dostępu do sieci prywatnej nie rozróżnia tych dwóch rodzajów pobierania, które będą podlegać tym samym ograniczeniom.
Zdjęcie główne: Markus Spiske, Unsplash