Acesso à rede particular: introdução às simulações

Titouan Rigoudy

Eiji Kitamura

Yifan Luo

Atualizações

• 7 de julho de 2022: atualizamos o status atual e adicionamos a definição do espaço de endereço IP.
• 27 de abril de 2022: aviso atualizado sobre a linha do tempo.
• 7 de março de 2022: anúncio de reversão após a descoberta de problemas no Chrome 98.

Introdução

O Chrome está descontinuando o acesso direto a endpoints de rede privada de sites públicos como parte da especificação de acesso à rede privada (PNA, na sigla em inglês).

O Chrome começará a enviar uma solicitação de simulação do CORS antes de qualquer solicitação de rede privada para um sub-recurso, que solicita permissão explícita do servidor de destino. Essa solicitação de simulação vai carregar um novo cabeçalho, Access-Control-Request-Private-Network: true, e a resposta a ela precisa ter um cabeçalho correspondente, Access-Control-Allow-Private-Network: true.

O objetivo é proteger os usuários contra ataques de falsificação de solicitações entre sites (CSRF, na sigla em inglês) que visam roteadores e outros dispositivos em redes privadas. Esses ataques afetaram centenas de milhares de usuários, permitindo que invasores os redirecionem para servidores maliciosos.

Plano de lançamento

O Chrome vai lançar essa mudança em duas fases para que os sites tenham tempo de notar e fazer os ajustes necessários.

1. No Chrome 104:

   • os experimentos do Chrome enviando solicitações de simulação antes de solicitações de sub-recursos da rede privada.
   • As falhas de simulação exibem apenas avisos no DevTools sem afetar as solicitações da rede particular.
   • O Chrome coleta dados de compatibilidade e entra em contato com os maiores sites afetados.
   • Esperamos que isso seja amplamente compatível com os sites existentes.
   Aviso:para limitar os efeitos em sites que ainda não oferecem suporte a simulações, o tempo limite fica restrito a 200 milissegundos no Chrome 104. A restrição é aplicada apenas no modo de alerta. O tempo limite especial seria removido após a ativação do modo de aplicação ao mudar a opção "Respeitar o resultado das simulações de acesso à rede privada" para "Ativado" em chrome://flags. O limite padrão é de cinco segundos.

2. No Chrome 113 ou mais recente:

   • Isso vai começar somente se e quando os dados de compatibilidade indicarem que a mudança é segura o suficiente e entramos em contato diretamente quando necessário.
   • O Chrome impõe que as solicitações de simulação sejam bem-sucedidas. Caso contrário, elas vão falhar.
   • Um teste de descontinuação começa ao mesmo tempo para permitir que os sites afetados por essa fase solicitem uma extensão de tempo. O teste terá duração mínima de seis meses.

Observação:houve uma tentativa anterior de lançar os avisos no Chrome 98 e no Chrome 102, anunciados nesta postagem do blog. Isso foi revertido após a descoberta de problemas de estabilidade e compatibilidade durante o lançamento. Os problemas identificados foram corrigidos no Chrome 104.

O que é o acesso à rede privada (PNA, na sigla em inglês)

O acesso à rede privada (anteriormente conhecido como CORS-RFC1918) restringe a capacidade dos sites de enviar solicitações para servidores em redes privadas.

O Chrome já implementou parte da especificação: a partir do Chrome 96, apenas contextos seguros estão autorizados a fazer solicitações de rede privada. Confira nossa postagem anterior do blog para mais detalhes.

A especificação também estende o protocolo de compartilhamento de recursos entre origens (CORS) para que os sites agora precisem solicitar explicitamente uma concessão de servidores em redes privadas antes de poder enviar solicitações arbitrárias.

Termo-chave:solicitações de rede privada são solicitações cujo endereço IP do servidor de destino é mais particular do que aquele de onde o iniciador da solicitação foi buscado. Por exemplo, uma solicitação de um site público (https://example.com) para um site particular (http://router.local) ou uma solicitação de um site particular para o localhost.

Como o PNA classifica endereços IP e identifica uma rede privada

Os endereços IP são classificados em três espaços: - public - private - local

O espaço de endereço IP local contém endereços IP que são endereços de loopback IPv4 (127.0.0.0/8) definidos na seção 3.2.1.3 da RFC1122 ou endereços de loopback IPv6 (::1/128) definidos na seção 2.5.3 da RFC4291.

O espaço de endereço IP particular contém endereços IP que têm significado apenas na rede atual, incluindo 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16 definidos no RFC1918, endereços link-local 169.254.0.0/16 definidos no RFC3927, endereços IPv6 unicast IPv6 únicos fc00::/7 definidos em RFC4193, endereços unicast privados de link-local na seção IPv4{/13/IPD{13/mapa} e os endereços link-local unicast {13/mapa} IPv4. {RFC1} são definidos como os endereços unicast IPv4 {13/13/IP dos RFC3927. RFC3927fe80::/10RFC4291

O espaço de endereço IP público contém todos os outros endereços não mencionados anteriormente.

Um endereço IP local é considerado mais particular do que um endereço IP particular, que é considerado mais particular do que um endereço IP público.

Relação entre redes públicas, privadas e locais no acesso à rede privada (CORS-RFC1918)

Saiba mais em Feedback: CORS para redes privadas (RFC1918).

Solicitações de simulação

Contexto

As solicitações de simulação são um mecanismo introduzido pelo padrão de Compartilhamento de recursos entre origens (CORS, na sigla em inglês). Ele é usado para solicitar a permissão de um site de destino antes de enviar uma solicitação HTTP que pode ter efeitos colaterais. Isso garante que o servidor de destino entenda o protocolo CORS e reduz significativamente o risco de ataques CSRF.

A solicitação de permissão é enviada como uma solicitação HTTP OPTIONS com cabeçalhos de solicitação CORS específicos descrevendo a próxima solicitação HTTP. A resposta precisa conter cabeçalhos de resposta do CORS específicos, que concordam explicitamente com a solicitação futura.

Novidades do Acesso à rede privada

Um novo par de cabeçalhos de solicitação e resposta é introduzido às solicitações simuladas:

• Access-Control-Request-Private-Network: true está definido em todas as solicitações de simulação da PNA.
• Access-Control-Allow-Private-Network: true precisa ser definido em todas as respostas de simulação da PNA

As solicitações de simulação para PNA são enviadas para todas as solicitações de rede privada, independentemente do método e do modo de solicitação. Eles são enviados antes das solicitações no modo cors, bem como no no-cors e em todos os outros modos. Isso ocorre porque todas as solicitações de rede privada podem ser usadas para ataques CSRF, independentemente do modo de solicitação e se o conteúdo da resposta é disponibilizado ou não para o iniciador.

Observação:se a solicitação de rede privada for feita no modo cors, os cabeçalhos CORS precisam ser definidos na resposta final, além da resposta de simulação.

As solicitações de simulação para PNA também serão enviadas para solicitações de mesma origem, se o endereço IP de destino for mais particular que o iniciador. Ele é diferente do CORS normal, em que as solicitações de simulação são apenas para solicitações de origem cruzada. As solicitações simuladas para solicitações de mesma origem protegem contra ataques de revinculação do DNS.

Exemplos

O comportamento observável depende do modo da solicitação.

Modo sem CORS

Digamos que https://foo.example/index.html incorpore <img src="https://bar.example/cat.gif" alt="dancing cat"/>, e bar.example seja resolvido como 192.168.1.1, um endereço IP particular de acordo com a RFC 1918 (link em inglês).

Primeiro, o Chrome envia uma solicitação de simulação:

HTTP/1.1 OPTIONS /cat.gif
Origin: https://foo.example
Access-Control-Request-Private-Network: true

Para que a solicitação seja bem-sucedida, o servidor precisa responder com:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Private-Network: true

Aviso:o servidor pode definir Access-Control-Allow-Origin: *, mas isso é perigoso e não recomendado. Os recursos de rede privada raramente estarão acessíveis a todas as origens. Portanto, pense com cuidado sobre os riscos envolvidos ao definir esse cabeçalho.

Em seguida, o Chrome enviará a solicitação:

HTTP/1.1 GET /cat.gif
...

O servidor pode responder normalmente.

Modo CORS

Digamos que https://foo.example/index.html execute este código:

await fetch('https://bar.example/delete-everything', {
  method: 'PUT',
  credentials: 'include',
})

Novamente, digamos que bar.example seja resolvido como 192.168.1.1.

Primeiro, o Chrome envia uma solicitação de simulação:

HTTP/1.1 OPTIONS /delete-everything
Origin: https://foo.example
Access-Control-Request-Method: PUT
Access-Control-Request-Credentials: true
Access-Control-Request-Private-Network: true

Para que a solicitação seja bem-sucedida, o servidor precisa responder com:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Credentials: true
Access-Control-Allow-Private-Network: true

Em seguida, o Chrome enviará a solicitação:

HTTP/1.1 PUT /delete-everything
Origin: https://foo.example

Para as quais o servidor pode responder conforme as regras normais de CORS:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://foo.example

Como saber se o site será afetado

A partir do Chrome 104, se uma solicitação de rede particular for detectada, uma simulação de solicitação será enviada antes dela. Se essa solicitação de simulação falhar, a solicitação final ainda será enviada, mas um aviso será exibido no painel de problemas do DevTools.

As solicitações de simulação afetadas também podem ser visualizadas e diagnosticadas no painel de rede:

Se a solicitação tivesse acionado uma simulação do CORS sem regras de acesso à rede privada, duas simulações podem aparecer no painel de rede, e a primeira sempre parecesse ter falhado. Esse é um bug conhecido e pode ser ignorado com segurança.

Para analisar o que acontece se o sucesso da simulação for aplicado, transmita o seguinte argumento de linha de comando a partir do Chrome 98:

--enable-features=PrivateNetworkAccessRespectPreflightResults

Qualquer solicitação de simulação com falha resultará em uma busca com falha. Assim, é possível testar se o site funcionaria após a segunda fase do plano de lançamento. Os erros podem ser diagnosticados da mesma forma que os avisos usando os painéis do DevTools mencionados acima.

O que fazer se o site for afetado

Quando essa mudança for lançada no Chrome 104, não se espera que nenhum site seja corrompido. No entanto, recomendamos que você atualize os caminhos de solicitação afetados para garantir que seu site continue funcionando conforme o esperado.

Há duas soluções disponíveis:

1. Processar solicitações de simulação no lado do servidor
2. Desativar as verificações de PNA com políticas empresariais

Processar solicitações de simulação do lado do servidor

Atualize o servidor de destino de todas as buscas afetadas para processar solicitações de simulação do PNA. Primeiro, implemente o suporte às solicitações de simulação do CORS padrão nas rotas afetadas. Em seguida, adicione suporte para os dois novos cabeçalhos de resposta.

Quando o servidor recebe uma solicitação de simulação (uma solicitação OPTIONS com cabeçalhos CORS), ele deve verificar a presença de um cabeçalho Access-Control-Request-Private-Network: true. Se esse cabeçalho estiver presente na solicitação, o servidor precisará examinar o cabeçalho Origin e o caminho da solicitação junto com outras informações relevantes (como Access-Control-Request-Headers) para garantir que a solicitação seja segura. Normalmente, você deve permitir o acesso a uma única origem sob seu controle.

Aviso:tenha cuidado com origens não seguras (não https), porque elas não são autenticadas. Um invasor pode se passar por qualquer origem desse tipo.

Depois que o servidor permitir a solicitação, ele responderá 204 No Content (ou 200 OK) com os cabeçalhos CORS necessários e o novo cabeçalho PNA. Esses cabeçalhos incluem Access-Control-Allow-Origin e Access-Control-Allow-Private-Network: true, entre outros, conforme necessário.

Consulte os exemplos para cenários concretos.

Desativar verificações de acesso à rede privada usando políticas corporativas

Se você tiver controle administrativo sobre seus usuários, poderá desativar as verificações do Acesso à rede privada usando uma das seguintes políticas:

• InsecurePrivateNetworkRequestsAllowed
• InsecurePrivateNetworkRequestsAllowedForUrls

Veja mais informações em Entender o gerenciamento de políticas do Chrome.

Enviar feedback

Se você está hospedando um site em uma rede privada que espera solicitações de redes públicas, a equipe do Chrome tem interesse no seu feedback e nos casos de uso. Informe-nos registrando um problema no Chromium em crbug.com e defina o componente como Blink>SecurityFeature>CORS>PrivateNetworkAccess.

A seguir

A seguir, o Chrome estenderá as verificações de acesso à rede privada para abranger os workers da Web: workers dedicados, compartilhados e service workers. Esperamos que o Chrome 107 comece a mostrar avisos.

Depois, o Chrome vai ampliar as verificações do Acesso à rede privada para cobrir navegações, incluindo iframes e pop-ups. Esperamos que o Chrome 108 comece a mostrar avisos.

Em ambos os casos, continuaremos com cuidado com um lançamento gradual semelhante para que os desenvolvedores da Web tenham tempo de ajustar e estimar o risco de compatibilidade.

Agradecimentos

Foto da capa de Mark Olsen no Unsplash (links em inglês).