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 nie nastąpi przed wersją 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 wycofywania, który zakończy się w Chrome
- Umożliwi to deweloperom złożenie prośby o przedłużenie okresu korzystania z wybranych źródeł, które nie zostaną objęte wycofaniem.
- Przedstawiamy zasadę Chrome, która umożliwi zarządzanym wdrażaniom Chrome trwałe obejście procesu wycofywania. 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 zmniejszyć wpływ nowych ograniczeń, skorzystaj z jednej 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. Nazwa specyfikacji została zmieniona z CORS-RFC1918 na prywatny dostęp do sieci.
- Kwiecień 2021 r.: wdrożenie Chrome 90 w wersji stabilnej, wyświetlanie ostrzeżeń 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 prosili o więcej czasu na dostosowanie się do zmian, wycofanie zostało odroczone do wersji 93 Chrome. Będzie ono poprzedzone okresem próbnym wycofywania.
- 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 roku: wdrażanie Chrome 94 w wersji beta. Programiści stron internetowych mogą zacząć korzystać z okresu próbnego wycofywania.
- Wrzesień 2021 roku: wprowadzamy Chrome 94 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łano ankietę dotyczącą wersji próbnej origin i otrzymano opinię. Wycofanie wersji próbnej zostało przedłużone do Chrome 113.
- Marzec 2023 r.: wersja próbna wycofania została rozszerzona do Chrome 116 i ma się zakończyć w Chrome 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ć jej do zakończenia okresu próbnego wycofywania.
- Wrzesień 2023 r.: w stabilnej wersji Chrome udostępniono Chrome 117, co oznacza zakończenie testów wycofywania. Chrome blokuje wszystkie żądania sieciowe z publicznych, niezabezpieczonych kontekstów.
Co to jest dostęp przez sieć prywatną
Prywatny dostęp do sieci (dawniej CORS-RFC1918) ogranicza możliwość wysyłania żądań przez witryny do serwerów w sieciach prywatnych. Zezwala na tego typu żądania wyłącznie z bezpiecznych 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 prywatne to żądania, których adres IP serwera docelowego jest bardziej prywatny niż adres, z którego został pobrany inicjator żą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ę.
W okresie próbnym wycofywania wycofane funkcje są domyślnie niedostępne dla wszystkich witryn. Deweloperzy, którzy nadal potrzebują tych funkcji, muszą zarejestrować się w programie testowym wycofania i uzyskać tokeny dla określonych zasobów 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 zgodne z ich źródłem, Chrome zezwoli na korzystanie z wycofanej funkcji 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. Ta zmiana była wcześniej planowana na wersję 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. Poniżej znajdziesz instrukcje dotyczące rejestracji i włączania okresu próbnego w witrynie.
Aby wyłączyć wycofanie na stałe lub na czas nieokreślony, możesz użyć 2 zasad Chrome. Pozwala to uniknąć awarii zarządzanych instalacji Chrome, na przykład w ustawieniach firmowych.
Chrome 117
Koniec okresu próbnego wycofywania. Wycofaną funkcję należy przenieść we wszystkich witrynach lub skonfigurować zasady ich użytkowników, aby ta 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 programie wycofania, albo za pomocą zasad. Następnie zalecane działania różnią się w zależności od okoliczności związanych z każdą dotkniętą 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 trzeba ustawić tylko w odpowiedziach na żądania głównego zasobu i nawigacji, tylko wtedy, gdy dokument wynikowy korzysta z wycofanej funkcji. 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. Jest to problem w przypadku stron, które nie mają kontroli nad nagłówkami odpowiedzi, np. stron statycznych github.io obsługiwanych przez zewnętrzną firmę.
Więcej informacji znajdziesz w przewodniku dla programistów dotyczącym 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 lokalnego hosta, wystarczy uaktualnić ją do HTTPS.
Żądania kierowane na http://localhost (lub http://127.*.*.*, http://[::1])
nie są blokowane przez mieszane treści, nawet jeśli 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 implementują 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ócenie relacji osadzenia.
Przejdź na HTTPS po obu stronach.
To rozwiązanie wymaga kontroli nad rozwiązywaniem nazw DNS użytkowników, co może być konieczne w kontekście intranetu lub gdy użytkownicy uzyskują adresy swoich serwerów nazw z kontrolowanego przez Ciebie 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. - Skonfiguruj DNS w sieci prywatnej, tak aby przekierowywała
intranet.exampledo prywatnego adresu IP serwera docelowego. - Skonfiguruj serwer prywatny, aby używał certyfikatu TLS dla
intranet.example. Umożliwi to użytkownikom dostęp do serwera prywatnego w domeniehttps://intranet.example.
Następnie możesz uaktualnić witrynę, która inicjuje żądania, do protokołu HTTPS i kontynuować wysyłanie żądań tak jak poprzednio.
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 przez użytkowników. Wymaga to, aby serwer docelowy uruchamiał minimalny serwer WebTransport (serwer HTTP/3 z pewnymi modyfikacjami).
Możesz obejść brak ważnego certyfikatu TLS podpisanego przez zaufany urząd certyfikacji, 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ą dwukierunkowe przesyłanie danych, ale nie żądania pobierania. Możesz połączyć to podejście z mechanizmem Service Worker, aby w sposób przejrzysty pośredniczyć w żądaniach HTTP podczas połączenia z punktu widzenia Twojej aplikacji internetowej. Po stronie serwera odpowiednia warstwa tłumaczenia może przekształcać wiadomości WebTransport w żądania HTTP.
Zdajemy sobie sprawę, że jest to spora praca, ale powinno to być znacznie łatwiejsze niż tworzenie baz danych WebRTC. Mamy też nadzieję, że pewna część niezbędnych inwestycji zostanie wdrożona jako biblioteki wielokrotnego użytku. Uważamy też, że jest to szczególnie ważne, ponieważ niezabezpieczone konteksty mogą z czasem tracić dostęp do coraz większej liczby funkcji platformy internetowej, która będzie coraz mocniej zachęcać do korzystania z HTTPS. Niezależnie od dostępu do sieci prywatnej jest to prawdopodobnie rozsądna 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 przed wycofaniem zostanie przedłużony.
Odwrotne umieszczanie
To rozwiązanie nie wymaga żadnej kontroli administracyjnej nad siecią i można z niego korzystać, gdy serwer docelowy nie jest wystarczająco wydajny, aby obsługiwać protokół 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. z 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ć.
Hostując tylko szkielet na serwerze prywatnym, można aktualizować aplikację internetową, wypychając nowe zasoby na serwer publiczny – tak jak w przypadku publicznej aplikacji internetowej. Z drugiej strony powstała aplikacja internetowa nie stanowi bezpiecznego kontekstu, więc nie ma dostępu do niektórych bardziej zaawansowanych funkcji internetowych.
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ędziemy na bieżąco informować o zmianach.
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ęść dostępu do sieci prywatnej polega na kontrolowaniu żądań 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. Żądanie jest wysyłane tylko wtedy, gdy uwierzytelnienie zostanie przyznane.
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 na ten temat 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 2 rodzajów pobierania, które z czasem będą podlegać tym samym ograniczeniom.
Zdjęcie główne: Markus Spiske, Unsplash