Google Chrome vraagt straks toestemming voor toegang tot lokale netwerk
Google Chrome krijgt een nieuwe optie waardoor websites straks toestemming aan gebruikers moeten vragen als ze toegang tot het lokale netwerk en apparaten daarop willen hebben. Via de Local Network Access specificatie moeten cross-site request forgery (CSRF) aanvallen worden voorkomen. In het verleden zijn bijvoorbeeld routers geregeld het doelwit van CRSF-aanvallen geweest. Via CSRF is het mogelijk voor een aanvaller om handelingen vanuit de browser van de gebruiker uit te voeren zodra er webcontent van de aanvaller wordt verwerkt.
Local Network Access beperkt de mogelijkheid van websites om requests naar servers en apparaten op het lokale netwerk van de gebruiker te sturen, waaronder servers die lokaal op de machine van de gebruiker draaien. De toegang wordt pas na toestemming van de gebruiker verleend, die hiervoor via een pop-up het verzoek kan toestaan of weigeren. Als eerste mijlpijl voor de implementatie van Local Network Access zal Google elk verzoek van het publieke netwerk naar een lokaal netwerk of loopback destination als een "lokaal netwerkverzoek" beschouwen.
De feature zal straks in Chrome 138 zijn te testen. Google wil Local Network Access naar eigen zeggen zo snel mogelijk uitrollen. Daarnaast komt er ook een Chrome enterprise policy waarmee beheerders kunnen instellen welke sites wel of geen lokale netwerkverzoeken kunnen doen. Dit moet voorkomen dat gebruikers voor bekende, bedoelde use cases toch een waarschuwing te zien krijgen.
Waarom niet net als audio en video bijna onzichtbaar standaard blokkeren? Alleen als je er naar zoekt toestaan.
Wellicht is het echt voor beveiliging. Ik heb alleen heel sterk het idee dat Google dat niets interesseert. En texten als "zo snel mogelijk uitrollen" komt mij dan weer extra creepy over. Alsof ze dit niet al decennia weten.
Verder zullen de meeste mensen de melding gewoon wegklikken, omdat ze niet weten wat een lokaal netwerk is of omdat de website die ze willen bezoeken anders niet werkt.
Ik las ook dat Chrome AI gaat ondersteunen. Is dat ook lokaal? https://www.theregister.com/2025/06/11/mozilla_worries_googles_browser_ai/ Is dit de werkelijke reden?
Off
Bij mij stond deze ingesteld als:
Warns you for insecure public sites
Als ik http://192.168.178.1 open, maakt Chrome die verbinding zonder eerst te waarschuwen.
Kennelijk is er een instelling toegevoegd, in Settings onder Privacy and security > Always use secure connections zie ik zojuist (voor het eerst), als ik dat aan zet, de volgende opties (met de bovenste mogelijkheid standaard aan):
( ) Warns you for insecure public& private sites
Private sites might include things like your company's intranet
Nadat ik voor de onderste optie heb gekozen, zie ik terug in Settings onder Privacy and security:
Warns you for insecure public & private sites
Als ik nu http://192.168.178.1 probeer te openen, verschijnt er éérst een waarschuwing die begint met:
Echter, zélfs deze instellingen garanderen niet dat Chrome in de achtergrond geen http-verbindingen maakt - indien een getoonde (externe) webpagina daar om vraagt. Immers, regels voor "third party content" zijn altijd veel minder restrictief geweest. Hoe Chrome hier op dit moment mee omgaat heb ik niet getest.
Maar een aanvaller kan niet een Let's encrypt certificaat aanvragen voor jouw localhost. Sterker nog, een aanvaller kan daar niet terecht komen behalve met CSRF.
Ook omzeil je met /etc/hosts je hele DNS oplossing. Een aanvaller van buiten je lokale netwerk, of Let's encrypt, heeft hier niets aan.
Voor zover ik het begrijp..
Anoniem 13:22
Maar een aanvaller kan niet een Let's encrypt certificaat aanvragen voor jouw localhost. Sterker nog, een aanvaller kan daar niet terecht komen behalve met CSRF.
Ook omzeil je met /etc/hosts je hele DNS oplossing. Een aanvaller van buiten je lokale netwerk, of Let's encrypt, heeft hier niets aan.
Voor zover ik het begrijp..
Anoniem 13:22
Je haalt twee zaken door elkaar, een certificaat zegt niets over het achterliggende IP adres.
Ik heb al mijn containers uitgerust met LE certificaten (zoals vele homelabs), DNS zorgt ervoor dat deze 'intern' op het netwerk gerouteerd worden maar het kan natuurlijk ook via je hostfile naar 127.0.0.1 gestuurd worden.
Certificaten zeggen dus niets over waar het verkeer heen gaat, enkel dat het verkeer tussen jou en de web server versleuteld is.
Ik heb al mijn containers uitgerust met LE certificaten (zoals vele homelabs), DNS zorgt ervoor dat deze 'intern' op het netwerk gerouteerd worden maar het kan natuurlijk ook via je hostfile naar 127.0.0.1 gestuurd worden.
Certificaten zeggen dus niets over waar het verkeer heen gaat, enkel dat het verkeer tussen jou en de web server versleuteld is.
Het zal een stuk duidelijker worden als Chrome de veranderingen doorvoert ;-p Zoals in het redactie artikel beschreven staat.
Anoniem 13:22
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Cybersecurity Trainer / Full Stack Developer
Ben je toe aan een nieuwe job waarmee je het verschil maakt? Wil jij je security kennis graag delen en hands-on laten zien hoe cybersecurity in de praktijk echt werkt? Werk je net als wij graag samen met enthousiaste en gedreven collega's? Bij ons geen bureaucratie maar open communicatie en een werkomgeving gericht op samenwerking.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?