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.
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.
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.](https://developer.chrome.google.cn/static/blog/private-network-access-preflight/image/requests-are-private-a-m-009fa2902388e.jpg?authuser=0&hl=pt-br)
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.
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 PNAAccess-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 no de problemas.
As solicitações de simulação afetadas também podem ser visualizadas e diagnosticadas no painel Network:
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.
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:
- Processar solicitações de simulação no lado do servidor
- 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.