O teste de descontinuação do acesso à rede privada (PNA, na sigla em inglês) para contextos não seguros está terminando. Implemente o prompt de permissão do PNA

Yifan Luo
Yifan Luo
GitHub

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 126, com lançamento previsto para 4 de setembro de 2024. 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 está mudando?

Para estabelecer conexões com dispositivos em uma rede privada que não tem nomes globalmente exclusivos e, portanto, não pode receber certificados TLS, esse recurso introduz uma nova opção a fetch() para declarar a intent de um desenvolvedor de falar com esse dispositivo. Isso inclui um novo recurso controlado por política para limitar o acesso de cada site a esse recurso e novos cabeçalhos para que a resposta de simulação do servidor forneça mais metadados.

O que é o Acesso à rede privada?

O acesso à rede privada (PNA, anteriormente conhecido como CORS-RFC1918 e brevemente como acesso à rede local) é um recurso de segurança que restringe a capacidade dos sites de enviar solicitações para servidores em redes privadas. Isso ajuda a proteger os usuários e as redes internas contra possíveis ataques como falsificação de solicitações entre sites (CSRF, na sigla em inglês). O Chrome vem implementando a PNA gradualmente, e a proteção será ampliada nas próximas versões.

Por que uma solicitação de permissão é necessária?

O Chrome 94 introduziu um bloqueio no acesso a redes privadas por sites públicos não seguros. O teste de descontinuação do Acesso à rede privada de 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, levando a violações de verificação de conteúdo misto.

Para enfrentar esse desafio, uma nova solicitação de permissão foi adicionada em um teste de origem do Chrome 120 e estável desde o Chrome 124.

Quando uma solicitação de permissão é necessária?

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 o servidor particular para HTTPS, o novo recurso de solicitação de permissão permitirá que você relaxe as verificações de conteúdo misto.

Um fluxo de trabalho típico para uma solicitação de acesso à rede privada com solicitação de permissão é o seguinte.

Acionar a solicitação de permissão

Adicione o novo atributo targetAddressSpace como uma opção de busca, e a solicitação poderá ignorar 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 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 seu servidor particular pessoal para usar o site de demonstração. O servidor particular precisa responder com o cabeçalho HTTP Access-Control-Allow-Private-Network: true, bem como os cabeçalhos Private-Network-Access-ID e Private-Network-Access-Name especificados pelo servidor. Se tudo estiver definido corretamente, a solicitação de permissão abaixo será exibida:

Sair do teste de descontinuação do contexto não seguro

Para os sites que registraram o teste de descontinuação do Acesso à rede privada para contextos não seguros, esse é o momento de migrar seu site com o novo prompt de permissão e sair do teste agora mesmo.

Depois de atualizar o código, exclua o token de teste nos cabeçalhos HTML, JavaScript ou HTTP. Se você não se lembra onde colocou o token de teste, consulte a seção Registrar para descontinuação do teste na postagem anterior do blog.

Você também pode excluir o token na página do teste.

Qual é a próxima etapa?

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, usar service workers ou tornar o espaço de endereço de destino uma nova Política de Segurança de Conteúdo. No entanto, o formato final para solicitações de fetch() que não são de API ainda está sendo investigado.

Solicitações de sub-frames podem ser compatíveis com a política de permissão no futuro.

No futuro, talvez seja necessário oferecer suporte a políticas de permissão para diminuir a capacidade de sub-frames.

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