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

Titouan Rigoudy
Titouan Rigoudy
Eiji Kitamura
Yifan Luo
Yifan Luo
GitHub

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: aviso atualizado sobre o cronograma.
  • 7 de março de 2022: anúncio de reversão após a descoberta de problemas em Chrome 98.

Introdução

O Chrome vai descontinuar o acesso direto a endpoints de rede privada de apps públicos sites como parte Acesso à rede privada (PNA, na sigla em inglês) especificação.

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 para permissão explícita do servidor de destino. Essa simulação de solicitação carregar um novo cabeçalho, Access-Control-Request-Private-Network: true, e o 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). segmentando 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 dar tempo aos sites a mudança e fazer os ajustes necessários.

  1. No Chrome 104:

    • Experimentos do Chrome enviando solicitações de simulação antes da rede privada solicitações de sub-recursos.
    • As falhas de simulação só exibem avisos no DevTools. que afetam as solicitações da rede privada.
    • O Chrome coleta dados de compatibilidade e entra em contato com as maiores afetadas e sites.
    • Esperamos que ele seja amplamente compatível com os sites existentes.
    .

  2. No Chrome 113 ou mais antigo:

    • Isso começará somente se e quando os dados de compatibilidade indicarem que o a mudança é segura o suficiente, e entramos em contato diretamente quando necessário.
    • O Chrome determina que as solicitações simuladas precisam ser bem-sucedidas. Caso contrário, falham as solicitações.
    • Um teste de descontinuação começa em ao mesmo tempo para que os sites afetados por essa fase solicitem uma uma extensão de tempo. O período de teste vai ser de, no mínimo, seis meses.
.

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

Acesso à rede privada (antes conhecido como CORS-RFC1918) que restringe a capacidade dos sites de enviar solicitações a servidores em redes VPC.

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

A especificação também estende o serviço de compartilhamento de recursos entre origens (CORS, na sigla em inglês) para que os sites agora solicitem explicitamente uma concessão dos servidores em redes privadas antes de poder 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 IPv4 endereços de loopback (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 na rede atual, incluindo 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16 definido no RFC1918, endereços link-local 169.254.0.0/16 definidos em RFC3927; endereços IPv6 unicast locais exclusivos fc00::/7 definidos no RFC4193, endereços unicast IPv6 link-local fe80::/10 definidos na seção 2.5.6 da RFC4291 e os endereços IPv6 mapeados em IPv4 onde o endereço IPv4 mapeado é privado.

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, é considerado mais privado do que um endereço IP público.

As solicitações são particulares quando uma rede mais disponível envia uma solicitação para um menos disponível.
Relação entre redes públicas, privadas e locais na rede privada Acesso (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 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 podem 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. descrevendo a próxima solicitação HTTP. A resposta precisa ter cabeçalhos de resposta do CORS específicos concordar explicitamente com a próxima solicitação.

Diagrama de sequência que representa a simulação do CORS. Um HTTP OPTIONS solicitação é enviada ao destino, que retorna 200 OK. Depois, o CORS cabeçalho de solicitação é enviado, retornando um cabeçalho de resposta CORS

Novidades no acesso a redes privadas

Um novo par de cabeçalhos de solicitação e resposta foi introduzido para as 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 de solicitação e mode. Eles são enviados antes de solicitações no modo cors, bem como no-cors e todos os outros modos. Isso 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 é disponíveis para o iniciador.

Solicitações de simulação para PNA também são enviadas para solicitações de mesma origem, se o endereço IP de destino é mais privado que o iniciador. Isso é diferente do normal CORS, em que as solicitações de simulação são apenas para solicitações de origem cruzada. Simulação as solicitações para a mesma origem protegem contra Ataques de revinculação de DNS.

Exemplos

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

Modo sem CORS

Digamos que https://foo.example/index.html incorpora <img src="https://bar.example/cat.gif" alt="dancing cat"/> e bar.example se refere a 192.168.1.1, um endereço IP particular de acordo com a RFC 1918 (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

Em seguida, o Chrome envia 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 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 envia a solicitação real:

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

Para o qual o servidor pode responder de acordo com as regras normais 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 simulação solicitação será enviada antes dele. Se essa solicitação de simulação falhar, o arquivo solicitação ainda será enviada, mas um aviso será exibido na de problemas.

Um aviso de falha na solicitação de simulação no painel &quot;Problemas do Devtools&quot;. Isso afirma: garantir que as solicitações de rede privada sejam feitas apenas para recursos com permissão além de detalhes sobre a solicitação específica e os recursos afetados listados.

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

Falha na solicitação de simulação no painel Network do DevTools para localhost fornece um status 501.

Se sua solicitação tivesse acionado uma simulação normal do CORS sem regras de Acesso à rede privada, duas simulações poderão aparecer na de rede, e o primeiro sempre parece ter falhado. Esta é uma bug conhecido e ele pode ser ignorado com segurança.

Uma falsa solicitação de simulação com falha antes de uma simulação bem-sucedida em no painel &quot;Network&quot; do DevTools.

Para analisar o que acontecerá se o sucesso da simulação for aplicado, faça o seguinte: 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 que você para testar se o site funciona depois da segunda fase do nosso plano de lançamento. Os erros podem ser diagnosticados em da mesma forma que os avisos usando os painéis do DevTools mencionados acima.

O que fazer se seu site for afetado

Quando essa mudança for lançada no Chrome 104, não deverá corromper nenhum site. No entanto, recomendamos que você atualize os caminhos de solicitação afetados para para garantir que seu site continue em execução conforme esperado.

Há duas soluções disponíveis:

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

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

Atualizar o servidor de destino de todas as buscas afetadas para lidar com a simulação de PNA solicitações. Primeiro, implemente o suporte para solicitações simuladas de CORS padrão no 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 CORS cabeçalhos), o servidor deve verificar a presença de um Cabeçalho Access-Control-Request-Private-Network: true. Se este cabeçalho for presentes na solicitação, o servidor precisa examinar o cabeçalho Origin e o o caminho da solicitação e outras informações relevantes (como Access-Control-Request-Headers) para garantir que a solicitação seja segura. Normalmente, você precisa permitir o acesso a uma única origem sob seu controle.

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

Consulte os exemplos para cenários concretos.

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

Se você tiver controle administrativo sobre seus usuários, poderá desativar a configuração Verificações de acesso à rede usando uma das seguintes políticas:

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 redes públicas, a equipe do Chrome tem interesse no seu feedback e casos de uso. Informe um problema no Chromium em crbug.com e defina o componente para Blink>SecurityFeature>CORS>PrivateNetworkAccess.

A seguir

Em seguida, o Chrome vai ampliar as verificações de acesso à rede privada para abranger funcionários da Web: workers dedicados, workers compartilhados e service workers. Estamos tentando para o Chrome 107 começar a mostrar avisos.

Em seguida, o Chrome vai ampliar as verificações de acesso à rede privada para abranger as navegações, incluindo iframes e pop-ups. Planejamos iniciar o Chrome 108 mostrando avisos.

Em ambos os casos, prosseguiremos com cautela com um lançamento gradual semelhante, para dar aos desenvolvedores Web tempo para ajustar e estimar o risco de compatibilidade.

Agradecimentos

Foto da capa de Mark Olsen em Abrir a página.