Reduza os riscos associados à exposição não intencional de dispositivos e servidores na rede interna de um cliente para a Web em geral.
Sites maliciosos que fazem solicitações para dispositivos e servidores hospedados em uma rede privada sempre foram uma ameaça. Os invasores podem, por exemplo, 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á procurando feedback de desenvolvedores que criam servidores para redes privadas.
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 de intranet, serviços corporativos e dispositivos de Internet das Coisas (IoT) são apenas parte deles. Eles podem parecer estar em um ambiente mais seguro do que os expostos ao público, mas esses servidores podem ser abusados por invasores que usam uma página da Web como proxy. Por exemplo, sites maliciosos podem incorporar um URL que, quando visualizado pela vítima (em um navegador com JavaScript ativado), tenta mudar as configurações do servidor DNS no roteador de banda larga residencial da vítima. Esse tipo de ataque é chamado de pharming drive-by e aconteceu em 2014. Mais de 300.000 roteadores sem fio vulneráveis foram explorados com a alteração das configurações de DNS,permitindo que invasores redirecionem usuários para servidores maliciosos.
CORS-RFC1918
Para reduzir a ameaça de ataques semelhantes, a comunidade da Web está trazendo o CORS-RFC1918, o compartilhamento de recursos entre origens (CORS, na sigla em inglês) especializado para redes privadas definido no 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 pela rede particular por padrão, exceto aqueles que são explicitamente permitidos pelo servidor usando CORS e HTTPS. O site que faz solicitações para esses recursos precisa enviar cabeçalhos CORS, e o servidor precisa declarar explicitamente que aceita a solicitação de origem cruzada respondendo com os cabeçalhos CORS correspondentes. Os cabeçalhos CORS exatos ainda estão em desenvolvimento.
Os desenvolvedores desses dispositivos ou servidores precisarão 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 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 resolve para o espaço de endereço particular definido na Seção 3 do
RFC1918 no 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 "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 "Endereço local
único" (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 particular só serão permitidas 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
privados estejam no 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 CORS-RFC1918 serão informados como erros de política CORS no console.
No painel Rede do Chrome DevTools, é possível ativar a caixa de seleção Solicitações bloqueadas para se concentrar 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.
Você pode testar usando este site de teste.
Etapa 2: enviar solicitações de pré-voo 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é-voo 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 o controle de acesso
refinado. O servidor pode responder com um cabeçalho Access-Control-Allow-Private-Network:
true para indicar explicitamente que ele concede acesso ao recurso.
Feedback necessário
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. 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 para o recurso de rede privada como esperado. - Se você encontrar algum problema ou tiver feedback, informe um problema em
crbug.com
e defina o componente como
Blink>SecurityFeature>CORS>RFC1918.
Exemplo de feedback
Nosso roteador sem fio atende um site de administrador para a mesma rede privada, mas por HTTP. Se o HTTPS for necessário para sites que incorporam o site do administrador, o conteúdo será misto. Devemos ativar o HTTPS no site do administrador em uma rede fechada?
Esse é exatamente o tipo de feedback que o Chrome está procurando. Registre um problema com seu caso de uso concreto em crbug.com. O Chrome vai adorar receber seu contato.