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ços IP.
• 27 de abril de 2022: anúncio da atualização do cronograma.
• 7 de março de 2022: foi anunciado o retorno à versão anterior depois que problemas foram descobertos 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 Acesso à rede privada (PNA, na sigla em inglês).

O Chrome vai começar a enviar uma solicitação de pré-vôo do CORS antes de qualquer solicitação de rede privada para um subrecurso, que pede permissão explícita do servidor de destino. Essa solicitação de simulação vai transmitir um novo cabeçalho, Access-Control-Request-Private-Network: true, e a resposta 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) para roteadores e outros dispositivos em redes privadas. Esses ataques afetaram centenas de milhares de usuários, permitindo que os invasores os redirecionassem 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 a mudança e se ajustar.

1. No Chrome 104:

   • O Chrome faz experimentos enviando solicitações de pré-voo antes das solicitações de subrecursos de rede privada.
   • As falhas de pré-voo só mostram avisos no DevTools, sem afetar as solicitações de rede particular.
   • O Chrome coleta dados de compatibilidade e entra em contato com os sites mais afetados.
   • Esperamos que isso seja amplamente compatível com os sites atuais.

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 quando entrarmos em contato diretamente quando necessário.
   • O Chrome exige que as solicitações de pré-voo 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. O teste vai durar pelo menos seis meses.

O que é o acesso à rede privada (PNA)

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

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

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

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

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

O espaço de endereços IP local contém endereços IP que são endereços loopback IPv4 (127.0.0.0/8) definidos na seção 3.2.1.3 da RFC1122 ou endereços 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 unicast IPv6 locais exclusivos fc00::/7 definidos no RFC4193, e endereços IPv6 mapeados para IPv4 em que o endereço IPv4 mapeado é particular.fe80::/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.

Saiba mais em Feedback necessário: CORS para redes particulares (RFC1918).

Solicitações de simulação

Contexto

As solicitações de pré-lançamento são um mecanismo introduzido pelo padrão Compartilhamento de recursos entre origens (CORS, na sigla em inglês) usado para solicitar permissão de um site de destino antes de enviar uma solicitação HTTP que possa 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 do CORS específicos que descrevem a próxima solicitação HTTP. A resposta precisa ter cabeçalhos de resposta do CORS específicos que concordem explicitamente com a próxima solicitação.

Novidades no acesso à rede particular

Um novo par de cabeçalhos de solicitação e resposta foi introduzido nas solicitações de simulação:

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

As solicitações de pré-voo para PNA são enviadas para todas as solicitações de rede privada, independente do método e do modo. Elas são enviadas antes das solicitações no modo cors, no-cors e todos os outros modos. Isso acontece porque todas as solicitações de rede particulares podem ser usadas para ataques CSRF, independente do modo de solicitação e se o conteúdo da resposta é disponibilizado ou não para o iniciador.

As solicitações de pré-voo para PNA também são enviadas para solicitações de mesma origem, se o endereço IP de destino for mais particular do que o iniciador. Isso é diferente do CORS normal, em que as solicitações de simulação são apenas para solicitações entre origens. As solicitações de pré-vôo para solicitações de mesma origem protegem contra ataques de revinculação de 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 privado de acordo com o RFC 1918.

O Chrome primeiro 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 essa 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

Em seguida, o Chrome vai enviar a solicitação real:

HTTP/1.1 GET /cat.gif
...

Para que o servidor possa responder normalmente.

Modo CORS

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

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

Novamente, digamos que bar.example se refere a 192.168.1.1.

O Chrome primeiro 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 essa 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 vai enviar a solicitação real:

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

A que o servidor pode responder de acordo com as regras usuais de CORS:

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

Como saber se seu site foi afetado

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

As solicitações de pré-voo afetadas também podem ser visualizadas e diagnosticadas no painel de rede:

Se a solicitação acionaria uma simulação de CORS normal sem regras de acesso à rede privada, duas simulações poderão aparecer no painel de rede, com a primeira sempre aparecendo como falha. Esse é um bug conhecido e pode ser ignorado com segurança.

Para conferir 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. Isso permite testar se o site vai funcionar após a segunda fase do nosso 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 será necessário interromper nenhum site. 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 do lado do servidor
2. Desativar as verificações de PNA com políticas empresariais

Processar solicitações de pré-lançamento do lado do servidor

Atualize o servidor de destino de todas as transferências afetadas para processar solicitações de simulação de PNA. Primeiro, implemente o suporte a solicitações de simulação padrão do CORS nas rotas afetadas. Em seguida, adicione suporte aos dois novos cabeçalhos de resposta.

Quando o servidor recebe uma solicitação de pré-lançamento (uma solicitação OPTIONS com cabeçalhos CORS), ele precisa 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 vai examinar o cabeçalho Origin e o caminho da solicitação com qualquer outra informação relevante (como Access-Control-Request-Headers) para garantir que a solicitação seja segura. Normalmente, é necessário permitir o acesso a uma única origem sob seu controle.

Depois que o servidor decidir permitir a solicitação, ele vai 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, bem como outros, conforme necessário.

Consulte os exemplos para conferir cenários concretos.

Desativar as verificações de acesso a redes privadas usando políticas corporativas

Se você tiver controle administrativo sobre os usuários, poderá desativar as verificações de acesso a redes privadas usando uma das seguintes políticas:

• InsecurePrivateNetworkRequestsAllowed
• InsecurePrivateNetworkRequestsAllowedForUrls

Para mais informações, consulte Entender o gerenciamento de políticas do Chrome.

Envie feedback para nós

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

A seguir

Em seguida, o Chrome vai estender as verificações de acesso à rede particular para cobrir workers da Web: workers dedicados, compartilhados e service workers. Nossa meta é que o Chrome 107 comece a mostrar avisos.

Em seguida, o Chrome vai estender as verificações de acesso à rede particular para cobrir navegações, incluindo iframes e pop-ups. A ideia é que o Chrome 108 comece a mostrar avisos.

Em ambos os casos, vamos proceder com cautela com uma implementação faseada semelhante, para dar tempo aos desenvolvedores da Web de ajustar e estimar o risco de compatibilidade.

Agradecimentos

Foto da capa de Mark Olsen no Unsplash.