Reduzir os riscos associados à exposição não intencional de dispositivos e servidores na rede interna de um cliente à Web em geral.
Sites maliciosos que fazem solicitações a dispositivos e servidores hospedados em uma rede privada são uma ameaça há muito tempo. Por exemplo, os invasores podem mudar a configuração de um roteador sem fio para ativar ataques Man-in-the-Middle. O CORS-RFC1918 é uma proposta para bloquear essas solicitações por padrão no navegador e exigir que os dispositivos internos ativem as solicitações da Internet pública.
Para entender como essa mudança afeta o ecossistema da Web, a equipe do Chrome está buscando feedback de desenvolvedores que criam servidores para redes particulares.
O que há de errado com as coisas como estão?
Muitos servidores da Web são executados em uma rede particular. Roteadores sem fio, impressoras, sites da intranet, serviços empresariais e dispositivos de Internet das Coisas (IoT) são apenas alguns exemplos. Eles podem parecer estar em um ambiente mais seguro do que os expostos ao público, mas podem ser usados indevidamente por invasores usando uma página da Web como proxy. Por exemplo, sites maliciosos podem incorporar um URL que, quando simplesmente visualizado pela vítima (em um navegador com JavaScript ativado), tenta mudar as configurações do servidor DNS no roteador de banda larga doméstica da vítima. Esse tipo de ataque é chamado de "pharming drive-by" e aconteceu em 2014. Mais de 300 mil roteadores sem fio vulneráveis foram explorados com a mudança das configurações de DNS,permitindo que invasores redirecionassem os usuários para servidores maliciosos.
CORS-RFC1918
Para reduzir a ameaça de ataques semelhantes, a comunidade da Web está trazendo o CORS-RFC1918: compartilhamento de recursos entre origens (CORS) especializado para redes particulares definidas na RFC1918.
Os navegadores que implementam o CORS verificam com os recursos de destino se eles podem ser carregados de uma origem diferente. Isso é feito com cabeçalhos extras inline que descrevem o acesso ou usando um mecanismo chamado solicitações de simulação, dependendo da complexidade. Leia Compartilhamento de recursos entre origens para saber mais.
Com o CORS-RFC1918, o navegador bloqueia o carregamento de recursos na rede privada por padrão, exceto aqueles que são explicitamente permitidos pelo servidor usando CORS e HTTPS. O site que faz solicitações a esses recursos precisa enviar cabeçalhos CORS, e o servidor precisa declarar explicitamente que aceita a solicitação entre origens respondendo com os cabeçalhos CORS correspondentes. Os cabeçalhos CORS exatos ainda estão em desenvolvimento.
Os desenvolvedores desses dispositivos ou servidores precisam fazer duas coisas:
- Verifique se o site que faz solicitações para uma rede particular é veiculado por HTTPS.
- Configure o suporte do servidor para CORS-RFC1918 e responda com os cabeçalhos HTTP esperados.
Quais tipos de solicitações são afetados?
As solicitações afetadas incluem:
- Solicitações da rede pública para uma rede privada
- Solicitações de uma rede privada para uma rede local
- Solicitações da rede pública para uma rede local
Uma rede particular
Um destino que é resolvido para o espaço de endereço particular definido na seção 3 da RFC1918 em IPv4, um endereço IPv6 mapeado para IPv4 em que o endereço IPv4 mapeado é particular ou um endereço IPv6 fora das sub-redes ::1/128, 2000::/3 e ff00::/8.
Uma rede local
Um destino que é resolvido para o espaço de "loopback" (127.0.0.0/8) definido na
seção 3.2.1.3 da RFC1122 do IPv4, o espaço
"link-local" (169.254.0.0/16) definido na
RFC3927 do IPv4, o prefixo "Unique Local
Address" (fc00::/7) definido na seção 3 da
RFC4193 do IPv6 ou o prefixo "link-local"
(fe80::/10) definido na seção 2.5.6 da
RFC4291 do IPv6.
Uma rede pública Todas as outras.
Planos do Chrome para ativar o CORS-RFC1918
O Chrome está trazendo o CORS-RFC1918 em duas etapas:
Etapa 1: as solicitações para recursos de rede privada serão permitidas apenas em páginas da Web HTTPS
O Chrome 87 adiciona uma flag que exige que sites públicos que fazem solicitações a recursos de rede privada usem HTTPS. Acesse about://flags#block-insecure-private-network-requests para ativar. Com essa
flag ativada, todas as solicitações para um recurso de rede privada de um site HTTP
serão bloqueadas.
A partir do Chrome 88, os erros de CORS-RFC1918 serão informados como erros de política de CORS no console.
No painel Rede do Chrome DevTools, marque a caixa de seleção Solicitações bloqueadas para focar nas solicitações bloqueadas:
No Chrome 87, os erros CORS-RFC1918 são informados apenas no console do DevTools como
ERR_INSECURE_PRIVATE_NETWORK_REQUEST.
Teste você mesmo usando este site de teste.
Etapa 2: enviar solicitações de simulação com um cabeçalho especial
No futuro, sempre que um site público tentar buscar recursos de uma rede privada ou local, o Chrome vai enviar uma solicitação de pré-teste antes da solicitação real.
A solicitação vai incluir um cabeçalho Access-Control-Request-Private-Network: true
além de outros cabeçalhos de solicitação do CORS. Entre outras coisas, esses
cabeçalhos identificam a origem que faz a solicitação, permitindo um controle de acesso
refinado. O servidor pode responder com um cabeçalho Access-Control-Allow-Private-Network:
true para indicar explicitamente que concede acesso ao recurso.
Queremos seu feedback
Se você estiver hospedando um site em uma rede privada que espera solicitações de redes públicas, a equipe do Chrome vai querer saber sua opinião e seus casos de uso. Há duas coisas que você pode fazer para ajudar:
- Acesse
about://flags#block-insecure-private-network-requests, ative a flag e verifique se o site envia solicitações ao recurso de rede privada conforme o esperado. - Se você encontrar algum problema ou tiver feedback, registre um problema em
crbug.com
e defina o componente como
Blink>SecurityFeature>CORS>RFC1918.
Exemplo de feedback
Nosso roteador sem fio veicula um site de administrador para a mesma rede particular, mas por HTTP. Se o HTTPS for necessário para sites que incorporam o site do administrador, será conteúdo misto. Devemos ativar o HTTPS no site de administração em uma rede fechada?
É exatamente esse tipo de feedback que o Chrome está procurando. Registre um problema com seu caso de uso concreto em crbug.com. O Chrome quer saber sua opinião.