Defesas contra spoofing de IDN no Chromium deixam passar domínios semelhantes convincentes
As defesas contra spoofing de IDN do Chromium deixaram passar 20 domínios semelhantes registrados, apesar de anos de proteções concebidas para expor endereços Unicode enganosos. Um domínio de prova de conceito se assemelhava muito a apple.com, mas aparecia como Unicode legível, e não no chamativo formato Punycode iniciado por xn--.
A descoberta não significa que invasores registraram o domínio da Apple ou comprometeram sua infraestrutura. Pesquisadores do Have I Been Squatted, ou HIBS, registraram um domínio diferente cujos caracteres cirílicos se parecem com as letras latinas de “apple”. Seus testes mostram como caracteres cuidadosamente selecionados podem passar pelas regras de exibição do Chromium e por suas defesas separadas durante a navegação.
O resultado reacende um conflito que os navegadores administram desde que os nomes de domínio internacionalizados passaram a ser amplamente usados. A web precisa de endereços escritos nos idiomas que as pessoas realmente usam. No entanto, a mesma diversidade de caracteres oferece aos invasores mais formas de imitar marcas confiáveis, provedores de identidade e serviços de pagamento.
O Chromium já aplica um dos sistemas de defesa mais detalhados do setor. Ele verifica scripts, combinações suspeitas de caracteres, domínios conhecidos e histórico de navegação. Os novos exemplos não anulam essas proteções. Eles revelam como alguns caracteres podem cair entre camadas que tomam decisões ligeiramente diferentes.
Pesquisadores encontraram um novo caso extremo de spoofing de IDN no Chromium
A mudança importante não é o retorno de um ataque esquecido, mas a evidência de que as verificações atuais do Chromium ainda permitem novas variações convincentes.
Os pesquisadores do HIBS Ian Muscat e Leanne Briffa publicaram sua análise em 3 de outubro de 2026. Eles examinaram se um domínio internacionalizado poderia se parecer com um endereço famoso em escrita latina e ainda assim aparecer como Unicode em navegadores baseados no Chromium.
Um nome de domínio internacionalizado, ou IDN, contém caracteres além do alfabeto inglês básico. Os aplicativos convertem esses caracteres em uma representação compatível com ASCII chamada Punycode antes de fazer uma solicitação DNS. Portanto, um domínio iniciado por xn-- não é automaticamente perigoso. Trata-se de uma forma codificada necessária para o atual Sistema de Nomes de Domínio.
Os navegadores frequentemente convertem essa forma codificada de volta para Unicode legível para exibição. Isso dá suporte a endereços legítimos em árabe, cirílico, chinês e muitos outros sistemas de escrita. O problema de segurança surge quando caracteres diferentes compartilham formas quase idênticas.
Os pesquisadores se concentraram em аррӏө.com, um domínio que pode se parecer com apple.com em fontes comuns. Suas letras são cirílicas, incluindo caracteres com a forma de um “a” latino, dois caracteres “p” e um “l”. O caractere cirílico final, ө, lembra um “e” arredondado quando exibido no tamanho da barra de endereços.
O endereço não é apple.com. Sua forma codificada é xn--80a6aa68c8d.com, e o DNS o trata como um nome separado. Ainda assim, a versão legível pode criar a impressão visual de que um visitante chegou ao domínio da Apple.
O HIBS registrou esse domínio e outros 19 semelhantes como prova de conceito. A lista imitava nomes associados a OpenAI, Skype, SharePoint, SpaceX, Shell, Xerox, Kaspersky, Okta, Nike e outras organizações reconhecidas.
A pesquisa original sobre IDN afirma que o Chrome 154 exibiu o semelhante da Apple em Unicode com um certificado válido. Ele também passou nas verificações de navegação avaliadas pelos pesquisadores sem produzir um aviso de domínio semelhante.
Um certificado válido não prova que um domínio pertence à marca que ele imita. Ele confirma que o navegador estabeleceu uma conexão criptografada com o domínio nomeado nesse certificado. Invasores podem obter certificados para domínios que controlam legitimamente, inclusive os enganosos.
Os exemplos foram registros controlados, não evidências de uma campanha voltada aos clientes de todas as empresas mencionadas. Essa distinção é importante porque um spoof tecnicamente viável não constitui automaticamente uma operação de phishing ativa.
Ainda assim, a viabilidade técnica é a descoberta. Um domínio enganoso pode sustentar um site real, HTTPS, e-mail, redirecionamentos e outros serviços comuns da internet. Invasores poderiam então combinar a semelhança visual com um anúncio em mecanismos de busca, e-mail fraudulento, código QR, link encurtado ou página de login copiada.
A pesquisa ganhou cobertura mais ampla em 18 de outubro, quando uma investigação sobre typosquatting detalhou como as substituições cirílicas sobreviveram às regras do Chromium. O momento volta a chamar atenção para defesas que muitos usuários nunca veem, a menos que o navegador detecte algo suspeito.
Isso cria a tensão central do artigo. O Chromium precisa distinguir substituições visuais enganosas de palavras legítimas usadas por milhões de pessoas. Uma regra ampla o suficiente para captar toda semelhança também tornaria endereços internacionais comuns mais difíceis de ler e confiar.
Como semelhantes Unicode no Chromium passam por múltiplas verificações
O semelhante da Apple sobrevive porque nenhuma regra individual do Chromium avalia a impressão visual completa que chega ao usuário.
O Chromium não pergunta apenas se um domínio contém Unicode. Ele processa IDNs por meio de vários testes antes de decidir se mostrará caracteres legíveis ou o rótulo Punycode subjacente.
A primeira camada principal usa o verificador de spoof do International Components for Unicode. O Chromium o configura no nível “Highly Restrictive”, que limita combinações suspeitas de sistemas de escrita.
Um rótulo misto contendo um caractere cirílico entre letras latinas normalmente falhará nesse teste. Substituir apenas o primeiro “a” de apple.com, por exemplo, faz o Chromium exibir xn--pple-43d.com. É muito menos provável que o endereço codificado seja confundido com o original.
O novo semelhante da Apple evita esse resultado porque todas as letras antes de .com são cirílicas. Trata-se de um rótulo de um único script, não de uma mistura evidente de caracteres latinos e cirílicos.
O Chromium também mantém um conjunto permitido de caracteres. Ele remove vários blocos Unicode e pontos de código individuais associados a exibições arriscadas ou confusas. Os caracteres em аррӏө.com continuam elegíveis, em parte porque são letras legítimas usadas em idiomas reais.
Seguem-se várias verificações direcionadas. O Chromium restringe thorn e eth islandeses fora dos domínios nacionais relevantes. Ele limita o schwa azeri e aplica uma regra específica ao ponto médio catalão. Nenhuma dessas restrições aborda a sequência cirílica na prova de conceito.
A defesa mais relevante é a verificação de caracteres confundíveis de script completo do Chromium. Ela procura rótulos escritos inteiramente com caracteres cirílicos que se parecem todos com letras latinas.
O Chromium introduziu essa proteção após uma demonstração amplamente discutida em 2017. O pesquisador de segurança Xudong Zheng registrou uma versão inteiramente cirílica de apple.com que os navegadores exibiam como uma cópia visual próxima do endereço real.
O Chromium respondeu no Chrome 58. Sua verificação de script completo identifica um conjunto de 29 caracteres cirílicos que se parecem com caracteres latinos. Quando cada letra em um rótulo de script único pertence a esse conjunto, o Chromium pode exibir o domínio como Punycode.
Essa defesa captura a versão de 2017. Ela não captura a nova variação porque ө não está entre os 29 caracteres listados. Um caractere fora do conjunto faz a condição de script completo deixar de se aplicar, embora o rótulo completo ainda se pareça com “apple”.
O navegador precisa permitir esse caractere em algum contexto porque ele não é um símbolo inventado. O ө cirílico é usado em cazaque, mongol, tártaro e outros idiomas. Bloqueá-lo em todos os lugares imporia um custo de usabilidade a falantes legítimos.
O Chromium então usa uma comparação de esqueleto para domínios protegidos. Um esqueleto reduz caracteres visualmente relacionados a uma representação normalizada que o software pode comparar com nomes conhecidos.
O processo é útil, mas não consegue reproduzir perfeitamente a visão humana. Neste caso, a barra em ө sobrevive à normalização. O esqueleto resultante termina com uma forma baseada em “o” mais uma marca combinante, em vez do esperado “e” latino.
Essa diferença impede uma correspondência exata com o esqueleto de apple.com. Uma pequena marca basta para alterar o resultado computacional, mesmo quando essa marca se torna difícil de perceber em uma interface compacta de navegador.
Exemplos em escrita latina expõem uma fraqueza relacionada. Os pesquisadores usaram caracteres como ƙ, uma letra latina com gancho, para imitar o “k” em nomes como Okta e Nike. O Chromium não pode aplicar um aviso amplo de script completo a caracteres latinos porque domínios latinos acentuados são comuns e legítimos.
Em vez disso, o Chromium oferece proteção de esqueleto mais forte a uma lista incluída de domínios proeminentes. O HIBS encontrou 8.462 nomes nessa lista, incluindo 836 em um grupo de maior prioridade. No entanto, um caractere que preserva uma marca extra pode impedir uma correspondência exata de esqueleto.
As diretrizes de exibição do Chromium reconhecem esse equilíbrio subjacente. O Chrome mostra Punycode quando suas regras de exibição de IDN identificam um risco de homógrafo, mas evita tratar todo endereço não ASCII como hostil.
Esse equilíbrio torna o spoofing de IDN no Chromium um problema de classificação, e não um simples problema de lista de bloqueio. Cada nova regra deve detectar semelhanças maliciosas sem transformar nomes internacionais legítimos em sequências codificadas ilegíveis.
Avisos do navegador fornecem uma segunda defesa, com limites
Um domínio que aparece em Unicode ainda enfrenta verificações de navegação, mas essas verificações dependem de comparações exatas, comprimento do nome e histórico do visitante.
O Chromium separa a exibição do endereço da proteção durante a navegação. O primeiro sistema determina como um nome de host aparece na barra de endereços. O segundo pode interromper ou anotar uma visita depois que o usuário navega.
O componente de navegação contra semelhantes do Chromium compara um endereço visitado com domínios populares e sites que o usuário visita regularmente. Dependendo da correspondência, o Chrome pode mostrar uma página de aviso em tela inteira ou uma Safety Tip menos intrusiva.
O projeto de aviso contra semelhantes descreve essas verificações como uma camada adicional ao Google Safe Browsing. A popularidade e o engajamento anterior de um usuário fornecem ao navegador pontos de referência para identificar alternativas suspeitas.
O HIBS informa que uma correspondência exata de esqueleto com um dos 836 domínios de maior prioridade produz uma página de aviso. Uma correspondência exata com outro domínio incluído pode gerar uma Safety Tip.
O navegador também considera sites que o usuário visita com frequência suficiente. Se um novo endereço se assemelha exatamente a um desses sites acessados, o Chromium pode bloquear a navegação e perguntar se o visitante pretendia abrir o domínio conhecido.
Correspondências próximas recebem tratamento mais restrito. O Chromium pode detectar um esqueleto que difere por um caractere inserido, removido ou substituído. Ele também pode reconhecer uma troca entre caracteres vizinhos.
Essas comparações não se aplicam de maneira uniforme. Segundo a pesquisa, o teste de correspondência próxima ignora rótulos de destino com menos de cinco caracteres antes do domínio de nível superior. Isso importa para marcas com nomes curtos.
O semelhante de Okta que usa ƙ está a uma edição do nome real, mas “okta” tem quatro caracteres. Os pesquisadores afirmam que isso o torna curto demais para a verificação de correspondência próxima relevante.
O exemplo da Apple falha por um motivo diferente. Seu esqueleto está a duas edições de apple.com porque ө é normalizado para um “o” com uma barra preservada. A comparação de quase correspondência permite apenas uma edição.
Como resultado, o domínio testado foi exibido em Unicode e carregado sem um aviso de imitação. A HIBS afirma que isso continuou verdadeiro mesmo para alguém que visitava regularmente o site autêntico da Apple.
Essas descobertas não devem ser interpretadas como uma auditoria completa de todas as proteções que cercam uma visita. Safe Browsing, feeds de inteligência de ameaças, software de endpoint, filtragem de DNS, gateways de e-mail e serviços de reputação ainda podem sinalizar um domínio malicioso.
A HIBS também excluiu algumas variáveis de sua avaliação, incluindo listas de permissões remotas, verificações de reputação e determinados comportamentos de redirecionamento. Portanto, um site transformado em arma poderia encontrar outras defesas que a prova de conceito não testou.
O inverso também é verdadeiro. Um domínio de phishing recém-criado pode inicialmente ter poucos dados de reputação. Atacantes costumam explorar esse intervalo antes que sistemas automatizados classifiquem a infraestrutura ou que defensores concluam uma remoção.
Isso explica por que o caso extremo importa mesmo quando existem várias salvaguardas. A segurança em camadas funciona melhor quando as falhas são independentes. Aqui, várias verificações dependem de representações de esqueleto e listas de domínios estreitamente relacionadas, de modo que um caractere cuidadosamente escolhido pode influenciar mais de uma decisão.
A proteção baseada no histórico também significa que dois usuários podem receber tratamentos diferentes. Um visitante regular de um serviço protegido fornece ao navegador um domínio conhecido para comparação. Um visitante de primeira vez pode ter apenas a lista de popularidade integrada.
Essa distinção é especialmente relevante para sites de recrutamento, bancos regionais, software empresarial e portais de fornecedores. Funcionários podem receber um link para um serviço que nunca visitaram, deixando o navegador com menos histórico pessoal para comparação.
A conclusão mais segura não é que o Chromium não oferece proteção. Suas regras interrompem muitas substituições comuns antes que cheguem aos usuários. A lição é que a aparência da barra de endereços e a ausência de um aviso não podem, por si só, estabelecer autenticidade.
Ataques Homógrafos de IDN Vão Além da Barra de Endereços
O navegador é apenas uma superfície de exibição, enquanto domínios enganosos podem alcançar usuários por e-mail, aplicativos de mensagens, documentos e resultados de busca.
Um ataque homógrafo de IDN usa caracteres diferentes que parecem semelhantes para personificar outro identificador. Typosquatting é a prática mais ampla de registrar alternativas que causam confusão com relação a um domínio legítimo, incluindo erros simples de digitação e caracteres visualmente enganosos.
A nova pesquisa situa-se onde essas categorias se sobrepõem. Os domínios não são erros convencionais de teclado, mas sua semelhança visual pode explorar leitura rápida, telas pequenas e formas de marcas conhecidas.
O e-mail cria uma transferência particularmente difícil. As regras de endereço do Chromium protegem nomes de host exibidos pela interface do navegador. Elas não controlam automaticamente o texto Unicode que um aplicativo de webmail coloca no cabeçalho de uma mensagem.
A HIBS testou 20 domínios de remetentes internacionalizados no Gmail e no Outlook na web. Os pesquisadores relatam que o Gmail exibiu todos os 20 em Unicode, incluindo domínios que a barra de endereços do Chromium teria exibido como Punycode.
Segundo o teste, o Gmail manteve a forma codificada em um campo separado de mailed-by. A maioria dos destinatários tem mais probabilidade de inspecionar a linha de remetente em destaque do que expandir informações técnicas de entrega.
O Outlook na web adotou a abordagem oposta no teste dos pesquisadores. Ele exibiu os 20 domínios de remetentes como seus rótulos compatíveis com ASCII, incluindo nomes internacionais comuns como café.com e zürich.com.
Nenhuma das abordagens resolve completamente a troca subjacente. Decodificar tudo oferece aos usuários endereços internacionais legíveis, mas preserva a ambiguidade visual. Codificar tudo expõe diferenças, ao mesmo tempo que torna endereços multilíngues legítimos incomuns e difíceis de interpretar.
Aplicativos de mensagens e documentos podem introduzir a mesma lacuna. Uma plataforma pode renderizar um link Unicode como texto comum antes que o navegador receba o destino selecionado. O usuário avalia uma exibição e depois navega por outro sistema de segurança.
Resultados de busca e anúncios acrescentam outra rota. Um domínio enganoso pode aparecer ao lado de marcas conhecidas e títulos de páginas copiados. Mesmo que o endereço seja ligeiramente diferente, o contexto ao redor pode incentivar um usuário a completar o padrão visual.
Códigos QR removem quase totalmente o destino visível até que a leitura ocorra. Navegadores móveis também têm menos espaço para nomes de host, e as interfaces podem enfatizar o título de uma página em vez do endereço completo.
O Unicode Consortium recomenda várias defesas para IDNs confundíveis. Elas incluem limitar os repertórios de caracteres permitidos, impedir misturas arriscadas de scripts, aplicar restrições contextuais de idioma e bloquear registros que se assemelhem a rótulos existentes.
Sua orientação de segurança para IDN também enfatiza uma qualificação importante. Caracteres Unicode confundíveis representam apenas uma pequena parcela do phishing. Domínios simples como secure-brand-login.com continuam mais comuns e não exigem caracteres incomuns.
Esse contexto impede que as novas descobertas se transformem na alegação de que Unicode criou a maior parte das fraudes online. Atacantes geralmente escolhem o método mais barato que funciona. Uma palavra conhecida, um subdomínio enganoso, uma conta roubada ou um site legítimo comprometido pode ser mais fácil do que construir um IDN sofisticado.
No entanto, uma prevalência menor não elimina o risco para alvos de alto valor. Plataformas de identidade, serviços financeiros, consoles de nuvem e portais de funcionários oferecem aos atacantes credenciais valiosas. Uma personificação visualmente convincente pode valer o esforço extra.
A internacionalização em si não é a falha. A internet precisa suportar nomes escritos fora do alfabeto latino básico. Tratar todos esses endereços como hostis transferiria o ônus para usuários e empresas legítimos.
A questão não resolvida é onde cada defesa deve operar. Navegadores controlam avisos de exibição e navegação. Registros controlam quais rótulos podem ser registrados. Serviços de e-mail controlam a apresentação do remetente. Proprietários de marcas monitoram registros suspeitos, enquanto equipes de segurança os filtram e investigam.
Nenhum participante enxerga o caminho completo do ataque. Essa fragmentação permite que um domínio rejeitado por uma interface pareça convincente em outra.
Registros Não Podem Deixar a Falsificação de IDN no Chromium para os Navegadores
A defesa mais duradoura começa antes da navegação, mas as políticas de registro continuam fragmentadas entre idiomas e domínios de topo.
Um domínio não pode oferecer suporte a um site ou caixa de correio independentes a menos que um registro permita seu registro. Portanto, controles de registro podem bloquear nomes enganosos antes que os navegadores precisem decidir como exibi-los.
Políticas de domínios internacionalizados normalmente usam tabelas de IDN. Essas tabelas definem quais caracteres Unicode um domínio de topo aceita e quais combinações ou variantes exigem tratamento especial.
O Unicode Consortium recomenda agrupar ou bloquear rótulos confundíveis. O agrupamento atribui variantes relacionadas ao mesmo registrante. O bloqueio permite que um rótulo exista enquanto impede o registro de alternativas que causam confusão.
As diretrizes de implementação de IDN da ICANN estabelecem expectativas gerais destinadas a reduzir cybersquatting e confusão do consumidor. As políticas reais ainda variam porque registros diferentes oferecem suporte a idiomas, scripts e requisitos locais distintos.
O registro .com permitiu os registros de prova de conceito da HIBS. Isso não significa que .com aceite todas as sequências Unicode. Significa que os caracteres e combinações testados se encaixavam nas regras de registro aplicáveis.
A HIBS também analisou o arquivo de zona .com obtido por meio do Centralized Zone Data Service da ICANN em outubro de 2026. Os pesquisadores contabilizaram 167.226.216 nomes .com delegados, incluindo 733.509 representados em formato IDN.
Sua metodologia associou IDNs a domínios ASCII delegados aos quais eles se assemelhavam visualmente. Ela produziu 161.894 pares de imitação, cobrindo 133.953 nomes ASCII distintos.
Esses números não são uma contagem de domínios maliciosos. Os pesquisadores alertam explicitamente que um par visual pode representar um registro defensivo, um site multilíngue ou uma organização não relacionada.
A distinção é essencial. Um domínio que contém um caractere acentuado pode se assemelhar a um nome ASCII por coincidência. Propriedade, conteúdo, comportamento de DNS, certificados, configuração de e-mail e redirecionamentos fornecem evidências mais fortes de intenção maliciosa.
Ainda assim, a escala mostra por que listas de navegadores não podem enumerar todos os alvos relevantes. As proteções integradas do Chromium cobrem milhares de nomes proeminentes, enquanto a zona .com contém milhões de empresas e organizações que podem enfrentar personificação.
Pequenas empresas podem estar especialmente expostas. É menos provável que seus domínios apareçam em listas globais de popularidade, mas seus clientes podem confiar em faturas, portais de fornecedores e mensagens de redefinição de senha que trazem o nome da empresa.
Um registro poderia responder proibindo um caractere recém-identificado em determinados contextos. Essa abordagem pode fechar um caso extremo, mas também pode excluir palavras e comunidades válidas que dependem do caractere.
Uma política mais precisa pode definir variantes com base em relações específicas de cada idioma. No entanto, a semelhança visual depende de fontes, tamanho, letras vizinhas e familiaridade do leitor. Uma sequência óbvia para um falante de inglês pode ser uma palavra legítima em outro idioma.
O registro defensivo oferece outra opção. Uma marca pode registrar variantes prováveis e redirecioná-las para o domínio autêntico. O código de navegação do Chromium reconhece alguns redirecionamentos seguros, o que ajuda a evitar avisos para variantes controladas pela organização real.
Essa estratégia não escala perfeitamente. Unicode contém muitas substituições possíveis, e as políticas de registro variam entre domínios de topo. Comprar cada possível imitação imporia um custo contínuo e ainda deixaria lacunas.
O monitoramento oferece cobertura mais ampla. Equipes de segurança podem observar novos registros, emissão de certificados, mudanças de DNS e comportamento de hospedagem de nomes semelhantes a domínios importantes. A detecção precoce apoia solicitações de remoção e bloqueios antes que um ataque alcance muitos usuários.
As organizações também devem proteger fluxos de trabalho de alto risco fora do navegador. Gerenciadores de senhas associam credenciais a origens exatas, tornando menos provável o preenchimento automático em um domínio imitador. Passkeys vinculam a autenticação ao domínio do site legítimo e resistem ao phishing convencional de credenciais.
Funcionários que lidam com pagamentos ou recuperação de contas precisam de caminhos de verificação que não dependam da aparência de um link. Favoritos conhecidos, portais de aplicativos gerenciados e canais de contato confirmados de forma independente reduzem a dependência do reconhecimento visual de domínios.
Essas medidas tratam de mais do que imitações Unicode no Chromium. Elas também ajudam contra erros ortográficos comuns, subdomínios enganosos, caixas de correio comprometidas e páginas de login clonadas.
A pressão, portanto, recai sobre várias partes ao mesmo tempo. O Chromium precisa refinar suas heurísticas. Registros precisam de políticas de variantes mais fortes. Provedores de e-mail precisam de exibições de remetente mais claras. Organizações precisam de controles que pressupõem que usuários às vezes interpretarão mal um endereço.
O Que Acontece em Seguida Mostrará se a Lacuna Realmente se Fecha
Três sinais determinarão se esta pesquisa produz uma defesa duradoura ou apenas mais uma entrada na história das imitações corrigidas.
O primeiro sinal é uma mudança nas regras do Chromium. A resposta mais clara trataria do cirílico ө, do latino ƙ ou da lógica de ramificação que permite que um caractere fora da lista contorne uma avaliação de script completo.
Simplesmente adicionar dois caracteres impediria os exemplos publicados. Isso não resolveria necessariamente o problema estrutural. Outro caractere com uma marca visível ou mapeamento de esqueleto incomum poderia recriar o mesmo resultado.
Uma correção mais ampla poderia comparar a impressão renderizada por meio de transformações adicionais de esqueletos. No entanto, comparações menos restritas aumentam os falsos positivos, especialmente para nomes internacionais legítimos.
O código público e os testes do Chromium tornam esse processo observável. Pesquisadores de segurança podem verificar se um patch bloqueia as provas registradas ao mesmo tempo que preserva domínios comuns nos idiomas afetados.
O segundo sinal é a ação dos registros. Tabelas IDN atualizadas poderiam classificar esses caracteres como variantes em contextos específicos ou impedir registros que imitem rótulos ASCII estabelecidos.
A ação dos registros reforçaria a principal avaliação do artigo, pois interrompe nomes enganosos antes que surjam diferenças de exibição. Um patch apenas no navegador deixaria os domínios disponíveis para clientes de e-mail e outros aplicativos com regras de renderização diferentes.
O terceiro sinal é uma mudança na apresentação de e-mails. A HIBS constatou que o Gmail decodificou todos os domínios de remetentes testados, enquanto o Outlook exibiu os rótulos codificados. Futuras alterações na interface poderiam mostrar ambas as formas, sinalizar identidades visuais mistas ou avisar quando um remetente se parecer com um domínio conhecido.
Esse sinal importa porque o e-mail continua sendo um mecanismo natural de entrega para roubo de credenciais e fraude em pagamentos. Um patch no Chromium não pode proteger contra um nome de remetente enganoso renderizado como texto dentro de uma aplicação web.
Os pesquisadores também precisarão testar novamente as conclusões após atualizações. O trabalho original examinou comportamentos específicos de navegadores, nomes registrados e caixas de correio de teste em um momento determinado. Ele não estabeleceu que todas as compilações do Chromium, sistemas operacionais, fontes ou aplicativos de e-mail renderizarão os caracteres de forma idêntica.
Diferenças de fonte podem enfraquecer ou reforçar a ilusão. Em tamanhos maiores, a barra em ө é mais fácil de perceber. Dentro de uma barra de endereços ou campo de remetente compacto, essa distinção pode ficar menos evidente.
Os registros reportados também comprovam a possibilidade, não uma exploração disseminada. Evidências públicas de campanhas de phishing que usem exatamente esses caracteres aumentariam a urgência. A ausência desses relatos não demonstraria que a lacuna é inofensiva, mas afetaria a priorização de riscos.
Para os usuários, a lição imediata é mais restrita do que “nunca confie em Unicode”. Verifique solicitações inesperadas por um canal conhecido, especialmente quando envolverem credenciais, pagamentos ou recuperação de conta. Um favorito ou gerenciador de senhas oferece uma referência melhor do que apenas a inspeção visual.
Para administradores, faça um inventário dos domínios mais importantes e monitore registros que se pareçam com eles. Exija autenticação resistente a phishing para sistemas sensíveis. Trate novos dados de fornecedor ou pagamento como um evento de verificação, não como uma tarefa rotineira de e-mail.
Para equipes de produto, teste como os aplicativos exibem endereços de remetentes e links internacionalizados. Mostrar um nome Unicode amigável sem acesso à forma codificada pode ocultar evidências úteis. Mostrar apenas Punycode pode tornar identidades internacionais legítimas desnecessariamente hostis.
As defesas contra spoofing de IDN do Chromium continuam substanciais, mas esta pesquisa demonstra que substancial não é completo. O navegador bloqueia substituições óbvias de scripts mistos e truques conhecidos de scripts inteiros e, em seguida, verifica destinos populares e familiares durante a navegação.
Um caractere cuidadosamente escolhido ainda pode alterar a comparação da máquina sem mudar a impressão percebida por uma pessoa apressada. Essa lacuna é pequena no código, mas significativa onde quer que a confiança dependa do reconhecimento de um nome.
Os próximos meses devem revelar se Chromium, registros e provedores de e-mail tratarão os exemplos como adições isoladas a uma lista ou como evidência de que as camadas precisam de pressupostos diferentes. Até lá, as organizações devem testar seus próprios domínios, reforçar a autenticação vinculada à origem e deixar de pedir aos usuários que tomem decisões de segurança com base apenas na tipografia.
