O Chrome 124 inclui o recurso de permissão de acesso à rede privada para relaxar conteúdo misto. Há um teste de descontinuação em andamento para sites que precisam de mais tempo para se preparar para essa mudança. No entanto, esse teste termina com o Chrome 132, que deve ser lançado em 4 de fevereiro de 2025. Esta postagem explica a mudança, mais sobre o design do recurso, como migrar seus sites atuais e como testar a implementação.
O que vai mudar?
Para estabelecer conexões com dispositivos em uma rede privada que não têm
nomes globalmente exclusivos e, portanto, não podem receber certificados TLS, esse
recurso introduz uma nova opção para fetch(), que declara a intenção dos desenvolvedores de
se comunicar com esse dispositivo. Isso inclui um novo recurso controlado por política para restringir
o acesso de cada site a esse recurso e novos cabeçalhos para a resposta de pré-vôo do servidor
para fornecer mais metadados.
O que é o acesso à rede particular?
O Acesso de rede particular (PNA, anteriormente conhecido como CORS-RFC1918 e resumidamente como "Acesso de rede local") é um recurso de segurança que restringe a capacidade de sites de enviar solicitações a servidores em redes particulares. Isso ajuda a proteger os usuários e as redes internas contra possíveis ataques, como falsificação de solicitações entre sites (CSRF). O Chrome vem implementando a PNA gradualmente, e a proteção será ampliada nas próximas versões.
Por que é necessário um aviso de permissão?
O Chrome 94 introduziu um bloqueio ao acesso a redes privadas de sites públicos não seguros. O teste de descontinuação do acesso de rede particular em contextos não seguros revelou desafios na migração de sites afetados para HTTPS. Uma preocupação comum é a dificuldade de migrar dispositivos particulares para HTTPS, o que leva a violações de verificação de conteúdo misto.
Para resolver esse problema, uma nova solicitação de permissão foi adicionada em um teste de origem do Chrome 120 e na versão estável do Chrome 124.
Quando é necessário uma solicitação de permissão?
Planejamos encerrar o teste de descontinuação de contextos não seguros alguns marcos depois que o recurso de solicitação de permissão ficou disponível. Para garantir a compatibilidade, você precisa migrar seus sites públicos para HTTPS. Se não for possível migrar seu servidor privado para HTTPS, o novo recurso de solicitação de permissão vai permitir que você relaxe as verificações de conteúdo misto.
Veja a seguir um fluxo de trabalho típico para uma solicitação de acesso à rede privada com solicitação de permissão.
Acionar o prompt de permissão
Adicione o novo atributo targetAddressSpace como uma opção de busca para que a solicitação
pule a verificação de conteúdo misto.
fetch("http://router.local/ping", {
targetAddressSpace: "private",
});
De acordo com o Acesso à rede privada: introdução
de simulações, qualquer solicitação de rede privada
é precedida por uma solicitação de simulação. Essa solicitação de simulação vai incluir
um novo cabeçalho, Access-Control-Request-Private-Network: true, e a
resposta correspondente precisa incluir o cabeçalho
Access-Control-Allow-Private-Network: true.
Para acomodar a nova solicitação de permissão, os dispositivos precisam incorporar dois novos
cabeçalhos de resposta: Private-Network-Access-Name e Private-Network-Access-ID.
Private-Network-Access-ID: um valor de 48 bits apresentado como 6 bytes hexadecimais separados por dois-pontos.Private-Network-Access-Name: um nome válido como uma string que corresponde à expressão regular ECMAScript/^[a-z0-9_-.]+$/.. O comprimento máximo do nome é de 248 unidades de código UTF-8.
Private-Network-Access-Name: "My Smart Toothbrush"
Private-Network-Access-ID: "01:23:45:67:89:0A"
Demonstração
Confira a demonstração em: https://private-network-access-permission-test.glitch.me/.
É necessário iniciar o servidor particular pessoal para usar o site de demonstração. O
servidor privado precisa responder com o cabeçalho HTTP
Access-Control-Allow-Private-Network: true, junto com os cabeçalhos especificados
Private-Network-Access-ID e Private-Network-Access-Name. Se
tudo estiver configurado corretamente, o seguinte aviso de permissão será mostrado:
Sair do teste de descontinuação do contexto não seguro
Para sites que registraram o teste de descontinuação do acesso de rede particular para contextos não seguros, é hora de migrar seu site com nosso novo aviso de permissão e sair do teste agora.
Depois de atualizar o código, exclua o token de teste nos cabeçalhos HTML, JavaScript ou HTTP. Se você não lembra onde colocou o token de teste, consulte a seção Registrar-se para o teste de descontinuação na postagem anterior do blog.
Também é possível excluir o token na página do teste.
A seguir
A solução para solicitações de fetch() que não são de API ainda está em análise.
Várias soluções foram testadas, por exemplo, usando service workers ou definindo
o espaço de endereço de destino como uma nova Content-Security-Policy. No entanto, a forma final
das solicitações de fetch() que não são de API ainda está em investigação.
As solicitações de subframes podem receber suporte com a política de permissão no futuro.
No futuro, talvez seja necessário oferecer suporte a políticas de permissão para relaxar a capacidade de subframes.
Feedback para casos de uso de rede privada
Se você hospeda um site em uma rede privada que precisa de solicitações de redes públicas, a equipe do Chrome quer seu feedback. Registre um problema no Issue Tracker do Chromium (componente: Blink>SecurityFeature>CORS>PrivateNetworkAccess) ou no repositório do GitHub.
Recursos
- Especificação da solicitação de permissão de acesso à rede particular
- Explicação sobre a solicitação de permissão de acesso à rede particular
- Passo a passo para relaxar o contexto misto para acesso à rede privada
- Teste de origem da solicitação de permissão de acesso à rede privada: um caminho para migrar sites com HTTPS