Proposta para limitar os sites que acessam a rede local do usuário

 (github.com/explainers-by-googlers)
1 pontos por GN⁺ 2025-06-05 | 1 comentários | Compartilhar no WhatsApp
  • A equipe de segurança do Chrome propôs um novo sistema de "permissão de acesso à rede local" para resolver o problema de acesso de websites à rede local
  • Atualmente, sites públicos podem tentar acessar ou atacar dispositivos da rede local do usuário, como impressoras, sem autorização; a proposta busca bloquear requisições à rede local sem a permissão do usuário
  • Diferente do Private Network Access (PNA) existente, o mecanismo funciona com base em consentimento de permissão do usuário em vez de preflight, reforçando o controle do usuário e permitindo adaptação apenas com atualização dos sites, sem mudanças nos dispositivos
  • Mais especificamente, quando um site público fizer uma requisição fetch para IP local, domínio .local etc., se não houver permissão o navegador exibirá um pedido explícito de consentimento ao usuário
  • Com essa política, além de reforçar segurança e privacidade, casos de uso legítimos como configuração de dispositivos IoT continuam funcionando normalmente com a autorização do usuário

Visão geral e objetivo da proposta

  • A equipe Chrome Secure Web and Network divulgou um rascunho inicial de um modelo de concessão da permissão de "acesso à rede local" para resolver o problema de acesso não autorizado de sites públicos à rede local
  • Até agora, sites visitados podiam tentar CSRF e outros ataques contra dispositivos da rede local do usuário, como impressoras e roteadores
  • A proposta é que, no futuro, o navegador bloqueie requisições que cruzem limites entre espaços de endereço, como IP público → IP local, e só as permita com autorização explícita do usuário por site

Contexto e diferenças

  • O Private Network Access (PNA) existente é baseado em preflight (requisição/resposta prévia), e sua adoção era difícil porque também exigia mudanças nos dispositivos
  • Esta proposta pode ser tratada apenas com consentimento de permissão do usuário e requer apenas pequenas alterações nos sites, o que facilita sua aplicação e disseminação na prática

Objetivos e não objetivos

  • Objetivos
    • Bloquear a exploração de dispositivos e servidores vulneráveis por ataques web do tipo drive-by
    • Permitir comunicação entre websites públicos e dispositivos locais apenas quando o usuário quiser e autorizar
  • Não objetivos
    • Evitar bloquear por completo fluxos legítimos de uso, como configuração e controle de dispositivos locais
    • Problemas de HTTPS na rede local e emissão complexa de certificados ficam fora do escopo desta proposta

Casos de uso

  • Caso 1: se um usuário comum não quiser, quando example.com fizer uma requisição para 192.168.0.1 etc., o navegador perguntará se permite; se recusar, a requisição será bloqueada
  • Caso 2: páginas oficiais de configuração web de fabricantes de dispositivos, como IoT e roteadores, poderão se comunicar após obter permissão do usuário no primeiro acesso

Projeto detalhado

  • Separação de espaços de endereço:
    • A camada de rede IP é classificada em três níveis: loopback (somente o próprio host), local (dentro da rede local) e public (acessível por todos)
    • Inclui vários critérios de identificação de rede local, como domínios .local, IPs privados de RFC1918/4193 e nomes link-local de RFC6762
  • Requisições à rede local: acessos como public→local, public→loopback e local→loopback exigem permissão
    • Desde requisições da rede pública para rede local/loopback até requisições da rede local para loopback passam a ser consideradas requisições à rede local
    • Exceções: local→local, loopback→qualquer endereço etc. não entram nas restrições
  • Prompt de permissão:
    • Quando um site fizer uma requisição para a rede local e não tiver permissão, o navegador exibirá um prompt perguntando ao usuário se deseja permitir
    • Se o usuário negar, a requisição será bloqueada; se aceitar, a requisição prossegue
  • Integração com a API fetch: ao chamar fetch, é possível indicar opções como targetAddressSpace: "local", permitindo distinção explícita
    • Como a especificação Fetch define apenas a conexão, sem resolução de DNS, a verificação de requisição à rede local ocorre no momento da nova conexão
    • Requisições à rede local só serão permitidas em contexto seguro; sem permissão obtida, haverá prompt; com permissão concedida, a requisição será permitida
    • Com a adição do parâmetro targetAddressSpace nas opções de fetch(), o desenvolvedor pode indicar explicitamente o espaço de endereço de destino
    • Se o endereço realmente conectado não corresponder ao espaço indicado na opção, a requisição falhará para evitar contorno de conteúdo misto
  • HTML, WebRTC, ServiceWorker etc. também seguem a mesma política
    • Valores de espaço de endereço são adicionados a documentos HTML/workers para rastrear o espaço com base na origem
    • Ao adicionar candidatos no ICE Agent do WebRTC, endereços locais/loopback usam prompt de permissão
    • A permissão se integra à Permissions API, permitindo que o site consulte o estado atual da permissão
    • Por padrão, apenas o documento de nível superior pode acessar a rede local; se necessário, é possível delegar a subframes por meio da política de delegação da Permissions Policy
  • Questões de conteúdo misto (HTTP/HTTPS):
    • Inclui cenários como tentativa de acesso à rede local em contexto não seguro, carregamento de sub-recursos via HTTP e aplicação de bloqueio de conteúdo misto
    • Requisições para IP privado literal, domínio .local e requisições com targetAddressSpace especificado pulam as etapas de upgrade e bloqueio de conteúdo misto; se a origem não tiver permissão na conexão subsequente, o acesso será bloqueado
  • Exemplos de funcionamento
    • Em caso de acesso inesperado à rede local, o usuário pode negar a permissão e bloquear a requisição não autorizada
    • No caso de páginas de controle de dispositivos operadas pelo fabricante, chamadas com propriedades adequadas, como targetAddressSpace="local", podem continuar funcionando como antes se houver consentimento do usuário

Alternativas e discussões

  • Abordagem PNA:
    • O PNA existente exigia preflight CORS, mas havia grande dificuldade de aplicação e implantação no mundo real
    • Em alguns trechos, foi proposta uma combinação de prompt de permissão com exceções para conteúdo misto
    • Há limitações práticas, como problemas de DNS e falta de suporte em especificações de dispositivos
  • Bloquear todas as requisições à rede local: é simples, mas não é realista por quebrar casos de uso e aumentar o custo de contornos
  • Manter o estado atual: como os sistemas operacionais começaram a gerenciar permissões de rede local por aplicativo, reforça-se a necessidade de controle também no nível do navegador
  • Alternativas para conteúdo misto:
    • Foram discutidos a avaliação de segurança da forma de conexão e o custo de implementação de opções como "permitir apenas sub-recursos seguros da rede local"
    • Também foram discutidas alternativas como declarar o espaço de endereço via cabeçalho de resposta/meta tag ou adicionar atributos a elementos HTML

Pontos adicionais

  • Também se discute a possibilidade de adicionar propriedades de espaço de endereço a sub-recursos HTML, como iframe e img
  • Resultados de pesquisa sobre problemas como transição excessiva de permissões (transitivity) ao conceder acesso foram incorporados
  • Restringir o acesso à rede local durante navegação do frame principal ou exibir um aviso intersticial
  • Também se considera tratar de forma ampla todas as requisições cross-origin para endereços locais/loopback como requisições à rede local
  • Estuda-se um modelo de permissões mais granular por rede, bem como a necessidade de novo consentimento ao mudar para outra rede ou local

Considerações de segurança e privacidade

  • Há preocupação de que sites com permissão possam ampliar a capacidade de explorar e acessar todos os dispositivos da rede do usuário
  • Ao aceitar o prompt, o usuário deve compreender claramente sua intenção, mas isso oferece controle mais direto do que um modelo baseado em preflight
  • Sem permissão prévia, nenhuma requisição à rede local será permitida, reforçando a proteção da privacidade

Leituras relacionadas

1 comentários

 
GN⁺ 2025-06-05
Comentários do Hacker News

  • Quando vi isso pela primeira vez, gostei da ideia; o simples fato de um site poder disparar requisições HTTP para IPs locais (ou qualquer IP) de forma arbitrária me parece um risco absurdo. Mesmo que isso quebre alguns apps corporativos ou integrações, pessoalmente não me importo. Empresas podem reativar esse recurso com ferramentas de administração, e usuários comuns podem ajustar isso manualmente. Na minha opinião, bastaria mostrar um pop-up do tipo: "Este site está tentando controlar dispositivos locais — permitir/negar".

    • Há uma visão equivocada aí: dispositivos na rede local já são protegidos contra sites arbitrários graças ao CORS. Não é perfeito, mas é bastante eficaz. O problema é que o CORS depende apenas do consentimento do servidor de destino: o servidor precisa autorizar o acesso daquele site por meio de cabeçalhos específicos. Esta proposta fortalece isso ao exigir aprovação explícita do usuário, mesmo quando o servidor e o site querem se comunicar. Antes, presumíamos que o acordo entre servidor e site bastava, mas casos recentes como o do Facebook, em que sites acessam sorrateiramente apps no celular, quebraram esse princípio. Ou seja, agora sites e servidores na rede local podem agir contra o interesse do usuário.

    • Sobre a ideia de que "usuários comuns podem simplesmente permitir ou negar no pop-up", o macOS já faz esse tipo de pedido de permissão por app, e a maioria dos usuários clica em "Permitir" sem pensar muito. Fazer isso por site provavelmente não aumentaria tanto assim o nível de cautela.

    • Não entendo por que um site deveria precisar acessar a rede local. Isso só cria um modelo de ameaça de segurança totalmente novo. Também fico em dúvida se já existe algum caso em que realmente não haja solução melhor.

  • Eu queria que Apple, Microsoft, Google etc. adotassem algo parecido também para USB e Bluetooth. Quase todo app que instalo ultimamente pede acesso ao Bluetooth, e isso é muito incômodo. Eu gostaria que o app tivesse que declarar no manifest os IDs dos dispositivos Bluetooth que pode acessar, e que o sistema operacional limitasse o acesso apenas a esses dispositivos. Por exemplo, o app da Bose deveria enxergar apenas dispositivos Bose. Já tive a experiência de negar permissões por não entender por que o app estava pedindo aquilo. Seria bom ter algo como registro de IDs de dispositivos e prompt ao usuário, parecido com permissões de câmera ou GPS. No caso da Bose, poderia registrar um prefixo como bose.xxx e, no manifest, pedir acesso apenas a bose.*, e o sistema operacional permitir somente essa regra. Proponho um sistema de IDs semelhante também para USB e dispositivos de rede local. Gostaria que o sistema impedisse apps de vasculhar rede, USB e Bluetooth livremente.

    • Espero que algum dia a Apple, pelo menos, ofereça aos apps uma opção de "permissão falsa". Por exemplo, se um app disser que precisa da minha lista de contatos, ele receberia uma lista aleatória indistinguível da real. Algo parecido também para GPS. Ouvi dizer que o WhatsApp nem permite definir nomes para contatos se você não compartilhar a agenda.

    • Prefiro um modelo de escolha detalhada, como nas integrações de terceiros do GitHub: "ABC quer ver seus repositórios. Quais repositórios você quer compartilhar?"

  • O Internet Explorer antigamente resolvia esse tipo de problema com um sistema de zonas. Para mais detalhes, veja a documentação da MS.

    • Ironicamente, o Chrome também usava parcialmente o esquema de segurança por zonas do IE no Windows, mas quase não havia documentação oficial sobre isso.

    • É absurdo não existir uma alternativa moderna para isso. Acesso à rede local também deveria ser permitido apenas como uma permissão especial, como câmera ou microfone.

  • É difícil acreditar que navegadores tenham permitido esse tipo de comportamento por padrão. Se um site público pudesse acessar sorrateiramente todo o meu sistema de arquivos, isso seria visto como uma falha de segurança terrível. Mas serviços na rede local podem simplesmente ser usados via XHR, e a segurança fica toda nas costas da configuração do servidor. Se você é desenvolvedor e roda um webapp interno na sua máquina de desenvolvimento para testes, com segurança frouxa ou inexistente, facebook.com, google.com etc. conseguem acessar diretamente. Em casa, muita gente também roda serviços sem autenticação confiando apenas no firewall do roteador; será que dá mesmo para acreditar que todos configuraram CORS corretamente?

    • Sou bastante cético de que todo mundo tenha configurado CORS direito; na prática, eu diria que a porcentagem sem configuração adequada deve estar perto de 0%.

  • Há expectativa de que esta proposta ajude a impedir a Meta de compartilhar códigos de identificação entre apps nativos e sites usando um truque baseado em localhost com seu próprio SDK, especialmente no Android. Mais detalhes aqui.

  • Dar a um site a permissão de acessar a rede local como um todo é algo muito grosseiro e desnecessariamente amplo. A maioria dos sites que realmente precisa dessa permissão só precisa acessar um único servidor local. Liberar tudo viola o princípio do menor privilégio. E a maioria dos usuários nem sabe o que está rodando em localhost ou na rede, então nem consegue avaliar o risco direito.

    • Como a maioria das pessoas não sabe se há algo rodando em localhost ou na rede, mesmo que o navegador mostre uma mensagem como permitir acesso a http://localhost:3146 ou http://localhost:8089, elas nem vão conseguir imaginar o que isso significa. Em vez de jargão técnico, algo como "Este site está tentando acessar recursos da rede local" seria uma mensagem mais intuitiva para o usuário.

    • Para implementar isso direito, na prática seria preciso algo no nível de um firewall dentro do navegador. Seria bom haver uma API com controle detalhado por CIDR, porta etc. Eu também gostaria que extensões de navegador pudessem usar essa API de firewall, ou que a interface padrão permitisse distinguir claramente escopos como uma máquina específica (por exemplo, o roteador), a LAN, a VPN ou a private network do Windows, para pedir permissões separadas para cada caso.

  • Desde o desaparecimento dos plugins NPAPI, muitos sites públicos passaram a depender de subir um servidor HTTP em localhost para se integrar com software local. Se até essa usabilidade ficar complicada, isso vai ser extremamente inconveniente. Os desenvolvedores de navegadores deveriam ter preparado uma tecnologia substituta depois do NPAPI, mas agora já pode ser tarde demais.

    • A maior parte dos softwares prefere registrar um protocol handler no sistema operacional, de modo que, por exemplo, o site passe um link como zoommtg:// e o navegador faça a integração com o Zoom e afins. Casos como o Jupyter Notebook, usado localmente sem requisições cross-origin, não seriam afetados. Enviar o usuário para uma URL localhost após login via OAuth2 também é apenas um redirecionamento simples, então provavelmente não seria um problema.

    • Se essa forma de integração, via servidor HTTP com app local, desaparecesse de vez, eu acharia até melhor. Ela tem servido como fonte de vulnerabilidades de segurança.

    • Tecnologias como Mozilla Native messaging já existem. Exigem a instalação de uma extensão, mas, comparado ao NPAPI, isso parece uma abordagem justa.

    • Se o software local funcionasse em modo de "pull" (o app consultando periodicamente um serviço externo), nem precisaria subir um servidor, e de quebra também evitaria que sites saíssem escaneando a rede local dos outros sem controle.

  • Em JavaScript, quando você faz uma requisição fetch ou POST sem opções de CORS, o CORS apenas impede a leitura da resposta; o envio da requisição em si continua sendo feito pelo navegador. Se um app local puder adicionar cabeçalhos CORS por meio de um proxy no servidor, qualquer site consegue acessá-lo com fetch/XMLHttpRequest. Extensões também podem modificar cabeçalhos e contornar o CORS. É fácil demais burlar isso mexendo em cabeçalhos, enquanto CSP (Content Security Policy) é de fato muito difícil, ou quase impossível, de contornar. O app do Facebook já opera assim hoje, rodando seu próprio servidor proxy CORS. E ainda existe WebSocket, então até uma flag do Chrome para bloquear acesso a localhost seria inútil. Bloquear totalmente localhost faria mais mal do que bem, porque muita gente usa servidores locais para apps self-hosted de favoritos, notas, gerenciadores de senha etc., então impedir esses casos seria irracional.

  • Há preocupação com problemas em ambientes IPv6. Fico curioso se existe, de fato, uma forma de distinguir se um endereço IPv6 é parcialmente local; se não houver, esta proposta pode ser problemática em redes IPv6-only. Já passei por isso em apps de IoT: como era difícil identificar se o endereço IPv6 era local, acabei redirecionando todo IPv6 para o local do IPv4. Até endereços IPv6 link-local não tinham muita utilidade prática em apps comuns. Tratar domínios .local como servidores locais também depende da implementação, e cada sistema operacional interpreta isso de um jeito, o que dificulta a consistência. Ex.: no Raspberry Pi OS, some_address resolve via mDNS, mas someaddress.local não; no Ubuntu 24.04, só someaddress.local funciona, e someaddress não. someaddress.local. também não funciona. Por fim, também é frustrante não poder usar certificados privados para endereços da rede local. O problema de "exigir HTTPS para endereços locais" também precisa ser resolvido.

    • No IPv6, ainda existe o conceito de algo ser "roteável", então logicamente daria para definir o que é site-local no nível da tabela de rotas. No antigo IPv4, havia estruturas como site no segundo octeto e VLAN no terceiro; no IPv6, há ainda mais opções. Todo dispositivo IPv6 tem um endereço link-local (para a VLAN local), e .local é um termo ligado a mapeamento nome-endereço em Apple, DNS etc., não diretamente ao IP. Em rede local, dá para ter certificados HTTPS usando DNS-01 do Let’s Encrypt, CNAME etc. É bem trabalhoso, mas há formas gratuitas, e ferramentas como acme.sh também ajudam. Precisamos organizar melhor os conceitos de IPv4, IPv6, DNS, mDNS, Bonjour etc. Lembro de quando até captura de pacotes era paga; hoje a situação é muito melhor.

    • Deixo mais claro o argumento de que não há como o endpoint distinguir se um endereço IPv6 é "local", porque o princípio do IPv6 é o roteamento global. Até o Google, no artigo, começou discutindo o significado de "local" e no meio mudou para uma definição de "private", o que mostra a confusão. Criar uma fronteira de segurança não padronizada baseada em CIDR como extensão de HTTP é uma abordagem bizarra. O correto seria projetar o modelo de segurança assumindo que o app é um serviço exposto publicamente. .local faz parte da especificação mDNS, mas na prática quase sempre é ignorado.

  • Espero sinceramente que isso seja implementado logo, especialmente se houver um recurso para permitir que domínios HTTPS acessem sites locais em HTTP. Há muitos casos de uso interessantes em smart home, mídia/entretenimento e afins.