Nowy komunikat z prośbą o dostęp przez sieć lokalną

Chris Thompson
Chris Thompson

Opublikowano: 9 czerwca 2025 r.

Chrome dodaje nowy monit o uprawnienia dla witryn, które nawiązują połączenia z siecią lokalną użytkownika w ramach specyfikacji dostępu do sieci lokalnej. Ma to na celu ochronę użytkowników przed atakami typu cross-site request forgery (CSRF) wymierzonymi w routery i inne urządzenia w sieciach prywatnych oraz ograniczenie możliwości wykorzystywania tych żądań przez witryny do tworzenia odcisków cyfrowych sieci lokalnej użytkownika.

Aby zrozumieć, jak ta zmiana wpłynie na ekosystem internetowy, zespół Chrome prosi o opinie deweloperów, którzy tworzą aplikacje internetowe korzystające z połączeń z siecią lokalną użytkownika lub z oprogramowaniem działającym lokalnie na jego urządzeniu. Od Chrome 138 możesz włączyć te nowe ograniczenia, otwierając chrome://flags/#local-network-access-check i ustawiając flagę na „Włączone (blokowanie)”.

Co to jest dostęp przez sieć lokalną?

Dostęp do sieci lokalnej ogranicza możliwość wysyłania przez witryny żądań do serwerów w sieci lokalnej użytkownika (w tym serwerów działających lokalnie na urządzeniu użytkownika), wymagając od użytkownika przyznania witrynie uprawnień przed wysłaniem takich żądań. Możliwość żądania tego uprawnienia jest ograniczona do bezpiecznych kontekstów.

Pojawi się prośba z tekstem „Szukanie urządzeń w sieci lokalnej i łączenie się z nimi”.
Przykład prośby o uprawnienia dostępu do sieci lokalnej w Chrome.

Wiele innych platform, takich jak Android, iOS i MacOS, ma uprawnienia dostępu do sieci lokalnej. Możesz na przykład przyznać to uprawnienie aplikacji Google Home podczas konfigurowania nowych urządzeń Google TV i Chromecast.

Jakich rodzajów żądań dotyczy problem?

W pierwszym etapie wdrażania dostępu do sieci lokalnej za „żądanie sieci lokalnej” uznajemy każde żądanie z sieci publicznej do sieci lokalnej lub miejsca docelowego pętli zwrotnej.

Sieć lokalna to dowolne miejsce docelowe, które prowadzi do adresów zarezerwowanych do użytku lokalnego. Na przykład prywatne adresy IPv4 określone w sekcji 3 dokumentu RFC1918 (np. 192.168.0.0/16), prefiks IPv4 „link-local” (169.254.0.0/16) zdefiniowany w dokumencie RFC3927, prefiks IPv6 „Unique Local Address” (fc00::/7) zdefiniowany w sekcji 3 dokumentu RFC4193, prefiks IPv6 „link-local” (fe80::/10) zdefiniowany w sekcji 2.5.6 dokumentu RFC4291 lub adres IPv6 mapowany na IPv4 (::ffff:0:0/96), w którym mapowany adres IPv4 jest adresem lokalnym.

Pętla zwrotna to dowolne miejsce docelowe, które prowadzi do komputera lokalnego (np. interfejs „loopback”, np. prefiks pętli zwrotnej IPv4 (127.0.0.0/8) zdefiniowany w sekcji 3.2.1.3 dokumentu RFC1122 lub pętla zwrotna IPv6 (::1/128) zdefiniowana w sekcji 2.5.3 dokumentu RFC4291.

Pełne mapowanie adresów IP na przestrzenie adresowe znajdziesz w tabeli w specyfikacji dostępu do sieci lokalnej.

Sieć publiczna to każde inne miejsce docelowe.

Ponieważ uprawnienie dostępu do sieci lokalnej jest ograniczone do bezpiecznych kontekstów i może być trudno przenieść urządzenia w sieci lokalnej na HTTPS, żądania do sieci lokalnej, które wymagają uprawnień, będą teraz zwolnione ze sprawdzania zawartości mieszanej jeśli Chrome wie, że żądania będą kierowane do sieci lokalnej przed rozpoznaniem miejsca docelowego. Chrome wie, że żądanie jest wysyłane do sieci lokalnej, jeśli:

  • Nazwa hosta żądania to literał prywatnego adresu IP (np. 192.168.0.1).
  • Nazwa hosta w żądaniu to domena .local.
  • Połączenie fetch() jest oznaczone adnotacją z opcją targetAddressSpace: "local"..
// Example 1: Private IP literal is exempt from mixed content.
fetch("http://192.168.0.1/ping");

// Example 2: `.local` domain is exempt from mixed content.
fetch("http://router.local/ping");

// Example 3: Public domain is not exempt from mixed content,
// even if it resolves to a local network address.
fetch("http://example.com/ping");

// Example 4: Adding the `targetAddressSpace` option flags that
// the request will go to the local network, and is thus exempt
// from mixed content.
fetch("http://example.com/ping", {
  targetAddressSpace: "local",
});

Zmiany w Chrome

Chrome 138

Nasza wstępna wersja dostępu do sieci lokalnej jest gotowa do testowania w Chrome 138. Użytkownicy mogą włączyć nowy prompt z prośbą o uprawnienia, ustawiając wartość parametru chrome://flags#local-network-access-check na „Włączony (blokujący)”. Ta funkcja obsługuje wyświetlanie prośby o uprawnienia dostępu do sieci lokalnej w przypadku żądań zainicjowanych za pomocą interfejsu fetch() API w JavaScript, wczytywania zasobów podrzędnych i nawigacji w ramkach podrzędnych.

Witryna demonstracyjna jest dostępna pod adresem https://lna-testing.notyetsecure.com/. Możesz w niej wywoływać różne formy żądań sieci lokalnej.

Znane problemy i ograniczenia

  • Połączenia WebSockets (crbug.com/421156866), WebTransport (crbug.com/421216834) i WebRTC (crbug.com/421223919) z siecią lokalną nie są jeszcze ograniczone przez uprawnienia LNA.
  • Żądania dostępu do sieci lokalnej z poziomu Service Workerów i Shared Workerów wymagają, aby źródło pracownika miało wcześniej przyznane uprawnienia dostępu do sieci lokalnej.
    • Jeśli Twoja aplikacja wysyła żądania do sieci lokalnej z poziomu komponentu service worker, musisz osobno wywołać żądanie do sieci lokalnej z poziomu aplikacji, aby wyświetlić prośbę o uprawnienia. (Pracujemy nad sposobem, aby pracownicy mogli wywoływać prośbę o uprawnienia, jeśli dostępny jest aktywny dokument – zobacz crbug.com/404887282).

Chrome 139 i nowsze wersje

Chcemy udostępnić Dostęp przez sieć lokalną jak najszybciej. Zdajemy sobie sprawę, że niektóre witryny mogą potrzebować więcej czasu na zaktualizowanie adnotacji dotyczących dostępu do sieci lokalnej, dlatego dodamy wersję próbną, która umożliwi witrynom tymczasowe wyłączenie wymagania dotyczącego bezpiecznych kontekstów, zanim domyślnie udostępnimy dostęp do sieci lokalnej. Powinno to zapewnić programistom jaśniejszą ścieżkę migracji, zwłaszcza jeśli korzystasz z dostępu do zasobów sieci lokalnej przez HTTP (ponieważ te żądania byłyby blokowane jako treści mieszane, gdyby były wysyłane ze strony HTTPS w przeglądarkach, które nie obsługują jeszcze wyłączenia treści mieszanych w przypadku dostępu do sieci lokalnej).

Dodamy też zasadę Chrome dla przedsiębiorstw, która będzie określać, które witryny mogą wysyłać żądania do sieci lokalnej (wstępne przyznawanie lub odmawianie uprawnień tym witrynom). Dzięki temu zarządzane instalacje Chrome, takie jak te w środowiskach firmowych, nie będą wyświetlać ostrzeżenia w przypadku znanych, zamierzonych zastosowań. Można też dodatkowo zablokować możliwość wysyłania przez witryny próśb o zezwolenie.

Planujemy dalsze integrowanie uprawnień dostępu do sieci lokalnej z różnymi funkcjami, które mogą wysyłać żądania do sieci lokalnej. Na przykład planujemy wkrótce udostępnić dostęp do sieci lokalnej w przypadku połączeń WebSockets, WebTransport i WebRTC.

Więcej informacji podamy bliżej daty wprowadzenia pełnej wersji dostępu do sieci lokalnej w Chrome.

Czekamy na Twoją opinię

Wcześniejsze opinie na temat rozwoju dostępu do sieci prywatnej były dla nas niezwykle cenne i pomogły nam opracować nowe podejście do uprawnień dostępu do sieci lokalnej. Chcielibyśmy jeszcze raz podziękować wszystkim, którzy przez lata byli zaangażowani w ten program.

Jeśli jesteś deweloperem lub użytkownikiem witryny, która polega na nawiązywaniu połączeń z lokalną siecią użytkownika lub oprogramowaniem działającym lokalnie na jego urządzeniu, zespół Chrome jest zainteresowany Twoimi opiniami i przypadkami użycia. Możesz zrobić 2 rzeczy:

  • Otwórz chrome://flags#local-network-access-check, ustaw flagę na „Włączone (blokowanie)” i sprawdź, czy Twoja witryna prawidłowo wyświetla nowy komunikat z prośbą o zezwolenie (i czy działa zgodnie z oczekiwaniami po udzieleniu zezwolenia).
  • Jeśli napotkasz problemy lub chcesz podzielić się opinią, zgłoś problem w narzędziu Chromium Issue Tracker lub w naszym repozytorium GitHub ze specyfikacją LNA. Chrome czeka na Twoją opinię.