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

Titouan Rigoudy

Eiji Kitamura

Yifan Luo

Atualizações

• 7 de julho de 2022: atualização do status atual e adição da definição de 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 simulação só exibem 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.
   Aviso:para limitar os efeitos em sites que ainda não oferecem suporte a preflights, o tempo limite é restrito a 200 milissegundos no Chrome 104. A restrição é aplicada apenas no modo de aviso. O tempo limite especial seria removido após ativar o modo de aplicação, mudando "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 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 prorrogação. O teste vai durar pelo menos seis meses.

Observação:uma tentativa anterior foi feita para lançar avisos no Chrome 98 e no Chrome 102, anunciado anteriormente nesta postagem do blog. Isso foi revertido depois que problemas de estabilidade e compatibilidade foram descobertos 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 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: desde o Chrome 96, apenas contextos seguros têm permissão para fazer solicitações de rede privada. 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.

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

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ç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 do RFC1122 ou nos 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 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.

Relação entre redes públicas, particulares e locais no acesso a redes particulares (CORS-RFC1918)

Saiba mais em Feedback: CORS para redes privadas (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 CORS específicos descrevendo a próxima solicitação HTTP. A resposta precisa ter cabeçalhos de resposta do CORS específicos que concordam 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 simulação 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 privada podem ser usadas para ataques CSRF, independentemente do modo de solicitação e se o conteúdo da resposta está ou não disponível para o iniciador.

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

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 simulação para solicitações da 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 particular 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

Aviso: o servidor pode definir Access-Control-Allow-Origin: *, mas isso é perigoso e desencorajado. Os recursos de rede privada raramente devem ser acessíveis a todas as origens. Portanto, pense cuidadosamente sobre os riscos envolvidos na definição desse cabeçalho.

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

HTTP/1.1 GET /cat.gif
...

Ao qual o servidor pode 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.

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 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 simulação afetadas também podem ser visualizadas e diagnosticadas no painel Network:

Se a solicitação tivesse acionado uma simulação normal do CORS sem as regras do Private Network Access, duas simulações podem aparecer no painel de rede, e a primeira sempre parece 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. 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 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 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 precisará examinar o cabeçalho Origin e o caminho da solicitação, além de outras informações relevantes (como Access-Control-Request-Headers) para garantir que a solicitação seja segura para permitir. Normalmente, é necessário permitir o acesso a uma única origem sob seu controle.

Aviso: tenha cuidado com origens não seguras (sem https), porque elas não são autenticadas. Um invasor pode se disfarçar como qualquer origem desse tipo.

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, além de 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 particulares 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 ampliará as verificações de acesso à rede privada para abranger os web workers: 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. Nossa meta é que o Chrome 108 comece a mostrar avisos.

Em ambos os casos, vamos proceder com cautela com um lançamento por fases 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.