Reduza os riscos associados à exposição não intencional de dispositivos e servidores da rede interna de um cliente para a 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. 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 aceitem as solicitações da Internet pública.
Para entender como essa mudança afeta o ecossistema da Web, a equipe do Chrome quer receber 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 privada. Roteadores sem fio, impressoras, sites de intranet, serviços empresariais e dispositivos de Internet das Coisas (IoT, na sigla em inglês) 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 usados indevidamente por invasores que usam uma página da Web como proxy. Por exemplo, sites maliciosos podem incorporar um URL que, ao ser simplesmente 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 "Drive-By Pharming" e aconteceu em 2014. Mais de 300.000 roteadores sem fio vulneráveis foram explorados com a mudança das configurações de DNS e a permissão de invasores para redirecionar os usuários a 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, na sigla em inglês), especializado em redes privadas, definido em RFC1918 (link em inglês).
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 simuladas, 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 para esses recursos precisará enviar cabeçalhos CORS, e o servidor precisará 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 serão solicitados a fazer duas coisas:
- Confira se o site que faz solicitações a uma rede privada é veiculado por HTTPS.
- Configure o suporte do servidor para CORS-RFC1918 e responda com os cabeçalhos HTTP esperados.
Que 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 privada
Um destino que é resolvido para o espaço de endereço particular definido na Seção 3 do
RFC1918 em IPv4, um endereço IPv6 mapeado
com 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 do RFC1122 do IPv4, o espaço "link-local" (169.254.0.0/16) definido no RFC3927 do IPv4, o prefixo "Endereço local exclusivo" (fc00::/7) definido na Seção 3 de
RFC1/2} o prefixo do
RFC1/local{/10 (RFC1} ou
RFC4193fe80::/10RFC4291
Uma rede pública Todas as outras.
Os planos do Chrome para ativar o CORS-RFC1918
O Chrome está implementando o CORS-RFC1918 em duas etapas:
Etapa 1: as solicitações para recursos de rede privada serão permitidas apenas de páginas da Web HTTPS
O Chrome 87 adiciona uma sinalização que obriga os sites públicos a fazer solicitações a recursos de rede
particulares para estarem em HTTPS. Acesse
about://flags#block-insecure-private-network-requests para ativar esse recurso. Com essa sinalização ativada, todas as solicitações de um site HTTP para um recurso de rede privada serão bloqueadas.
A partir do Chrome 88, os erros CORS-RFC1918 serão informados como erros de política de CORS no console.
No painel Rede do Chrome DevTools, ative 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 no Console do DevTools apenas como
ERR_INSECURE_PRIVATE_NETWORK_REQUEST.
Faça um teste 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 particular ou local, o Chrome enviará uma solicitação de simulação 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.
Feedback solicitado
Se você está hospedando um site em uma rede privada que espera solicitações de redes públicas, a equipe do Chrome tem interesse no seu feedback e nos casos de uso. Há duas coisas que você pode fazer para ajudar:
- Acesse
about://flags#block-insecure-private-network-requests, ative a flag e confira se o site envia solicitações ao recurso de rede particular como esperado. - Se você encontrar problemas 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 atende a um site de administração da mesma rede privada, mas por HTTP. Se o HTTPS for necessário para os 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á buscando. Registre um problema com seu caso de uso concreto em crbug.com. O Chrome adoraria saber sua opinião.
Imagem principal por Stephen Philips no Unsplash.