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

Chris Thompson
Chris Thompson

Opublikowano: 9 czerwca 2025 r.

Chrome dodaje nowy komunikat z prośbą o zezwolenie 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 komputerze. 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 „Szukaj urządzeń w sieci lokalnej i łącz 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 jest rozpoznawane jako prywatna przestrzeń adresów zdefiniowana w sekcji 3 RFC1918 w IPv4 (np. 192.168.0.0/16), adres IPv6 z mapowaniem na adres IPv4, w którym mapowany adres IPv4 jest prywatny, lub adres IPv6 spoza podsieci ::1/128, 2000::/3 i ff00::/8.

Pętla zwrotna to dowolny cel, który jest rozpoznawany jako przestrzeń „pętli zwrotnej” (127.0.0.0/8) zdefiniowana w sekcji 3.2.1.3 dokumentu RFC1122 protokołu IPv4, przestrzeń „link-local” (169.254.0.0/16) zdefiniowana w dokumencie RFC3927 protokołu IPv4, prefiks „Unique Local Address” (fcc00::/7) zdefiniowany w sekcji 3 dokumentu RFC4193 protokołu IPv6 lub prefiks „link-local” (fe80::/10) zdefiniowany w sekcji 2.5.6 dokumentu RFC4291 protokołu IPv6.

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ż uprawnienia dostępu do sieci lokalnej są ograniczone do bezpiecznych kontekstów i migracja urządzeń w sieci lokalnej do protokołu HTTPS może być trudna, żądania dostępu 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)”. Umożliwia to wyświetlanie prośby o uprawnienia dostępu do sieci lokalnej w przypadku żądań zainicjowanych za pomocą interfejsu fetch() API JavaScript, ładowania 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 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 przyznanie uprawnień. (Pracujemy nad sposobem, w jaki pracownicy mogą 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 pozwoli witrynom tymczasowo zrezygnować z wymogu bezpiecznego kontekstu, zanim domyślnie udostępnimy dostęp do sieci lokalnej. Powinno to zapewnić deweloperom 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, np. w środowiskach firmowych, nie będą wyświetlać ostrzeżenia w przypadku znanych, zamierzonych zastosowań, a także będą mogły dodatkowo blokować witryny i uniemożliwiać im w ogóle proszenie o zezwolenie.

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

Więcej informacji podamy bliżej daty pełnego wprowadzenia 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. Chętnie poznamy Twoją opinię.