Um ataque homográfico registra um domínio construído com caracteres que parecem os de um domínio real, mas não são. Um "о" cirílico faz o papel de um "o" latino, e o endereço que você lê e o endereço que o navegador resolve passam a ser duas coisas diferentes. O truque viaja como punycode: o DNS só entende ASCII, então todo nome não ASCII é convertido em um rótulo xn-- antes de tocar a rede, e os navegadores o convertem de volta para exibir. É nessa conversão de volta que mora o engano.
Os navegadores modernos já pegam os casos óbvios e mostram o punycode cru quando um rótulo mistura alfabetos de forma suspeita. Mas essa proteção fica dentro da barra de endereços. Este texto mostra como o ataque funciona, o que os padrões e os navegadores fazem a respeito, onde eles param e o que um verificador de links pode ou não enxergar. Para a questão mais ampla dos links curtos, encurtadores de URL são seguros cobre esse terreno; este aqui trata do domínio por baixo do link.
O que é punycode e por que ele existe
O DNS foi feito para ASCII. Ponto. Ele não tem forma nativa de armazenar letras acentuadas, cirílico, árabe ou chinês, o que virou problema assim que o registro de domínios se abriu fora dos mercados de língua inglesa.
O punycode é a solução: uma codificação reversível, padronizada na RFC 3492, que converte um rótulo Unicode em letras, dígitos e hifens que o DNS transporta sem alteração. Uma padaria alemã com trema no nome ou uma loja ucraniana que registra em cirílico obtém um domínio internacionalizado funcional, que resolve como qualquer outro. O rótulo codificado começa com xn--, o que sinaliza "decodifique antes de mostrar a um humano".
Nada disso é falha. Domínios internacionalizados são um recurso necessário. O problema começa uma camada acima: o software decide como exibir o nome decodificado.
Como funciona um ataque homográfico
O ataque explora a distância entre o que um domínio contém e o que ele parece depois de renderizado. O relatório de segurança do Unicode, UTS #39, fornece o vocabulário (acessado em 2026-10-25). Duas strings são confundíveis quando se reduzem ao mesmo "skeleton". Ele então separa o confundível de alfabeto inteiro, em que uma string escrita inteiramente em um alfabeto, como "scope" em latino, tem uma imitação escrita inteiramente em outro, aqui o cirílico, do confundível de alfabetos mistos, em que a imitação mistura alfabetos.
A versão de alfabeto inteiro exige um nome em que toda letra tenha um equivalente em outro alfabeto. É mais rara. Poucas marcas reais podem ser escritas assim. A versão de alfabetos mistos exige uma única substituição. Pegue novacloud.com, troque o "o" latino pelo "о" cirílico (U+043E) e você obtém um domínio com a mesma forma e o mesmo tamanho que codifica para xn--nvacloud-nbh.com. O olho quase não tem o que sinalizar. Esse é o ponto.
Depois que o domínio é registrado, o resto é phishing comum. Uma página de login copiada, uma mensagem urgente, um alvo sem motivo para duvidar de um endereço que parece certo.
O que os navegadores fazem a respeito
Os navegadores fecharam a versão fácil desse ataque com regras sobre quais alfabetos podem dividir um rótulo. A política de IDN do Chrome decide por rótulo e recorre ao punycode em muitos casos (acessado em 2026-10-25). Ela afirma que caracteres latinos, cirílicos e gregos não podem ser misturados entre si, e também mostra punycode para confundíveis de alfabetos mistos, para rótulos formados inteiramente por confundíveis de alfabeto inteiro, a menos que o domínio de topo esteja no território habitual daquele alfabeto, e para rótulos cujo skeleton coincide com o de um domínio de topo. O Firefox executa uma verificação comparável, descrita no algoritmo de exibição de IDN da Mozilla, e o Safari tem a sua.
O resultado é que nоvacloud.com com uma letra cirílica aparece como xn--nvacloud-nbh.com no Chrome. Não é proteção completa. As regras variam conforme o navegador, e uma imitação em um único alfabeto que nenhuma lista previu ainda pode ser exibida como um nome legível e enganoso.
Onde essa proteção termina
A verificação de mistura de alfabetos vive na renderização da barra de endereços do navegador. Ela não viaja com a URL.
Clientes de e-mail podem mostrar qualquer texto de âncora sobre qualquer destino. Muitos não fazem nenhuma checagem de confundíveis, e os apps de e-mail para celular são os mais fracos. Apps de chat expandem um link em um cartão de prévia montado a partir dos metadados da página. Códigos QR eliminam a etapa do texto, uma lacuna que tratamos em códigos QR são seguros, e o material impresso não tem camada de software alguma.
| Canal | Mostra o destino real antes de você agir | Exposição típica |
|---|---|---|
| Navegador desktop moderno | Normalmente, pelas regras de mistura de alfabetos | Baixa, se mantido atualizado |
| Cliente de e-mail | Raramente, pois o texto da âncora pode dizer qualquer coisa | Alta, sobretudo em apps de e-mail no celular |
| Apps de chat e mensagens | Raramente, as prévias usam metadados da página | Alta, links expandidos parecem idênticos |
| Código QR | Não, nada é renderizado até depois da leitura | Alta, a decisão leva um segundo |
| Material impresso | Nunca, nenhum software está envolvido | Máxima, nenhuma checagem técnica é possível |
O que um encurtador de links pode checar
Um encurtador fica entre o remetente e o navegador, então pode olhar um destino antes que alguém clique. O quanto ele enxerga depende da implementação, e aqui está o que o Elido faz hoje, segundo o código.
A heurística do url-scanner soma 25 pontos quando o host do destino começa com um rótulo xn--, ou contém um. Soma mais por nomes de marcas no host ou no caminho, por um @ que esconde o host real, por hosts com IP bruto e por hostnames com hifens em excesso. As pontuações da heurística são limitadas a 75, abaixo dos 80 necessários para bloquear, então um host punycode sozinho é sinalizado como suspeito, nunca bloqueado. Cruzar a linha exige um acerto em lista de ameaças ou um segundo sinal. O scanner também consulta listas de ameaças, que incluem domínios parecidos depois que alguém os denuncia.
Há uma lacuna, e é real. Esse teste de xn-- roda sobre o hostname como foi enviado, e não encontrei no api-core nem no scanner nenhuma etapa que converta antes um hostname Unicode para a forma ASCII. Um destino colado em forma Unicode (a versão cirílica) pode, portanto, pular o sinal de punycode que seu gêmeo ASCII acionaria. A checagem de imitação de marca também é uma correspondência de substring ASCII, então não casa com um "раураl" cirílico de jeito nenhum. Registramos os dois como itens de backlog. Até serem corrigidos, trate a heurística como um filtro inicial barato, não como um detector de homógrafos.
Do outro lado, os domínios personalizados são mais rígidos. O handler de adição de domínio aceita apenas letras ASCII, dígitos e hifens, então um workspace não consegue anexar um hostname Unicode cru, embora consiga adicionar a forma xn--.
Por que um domínio de marca ajuda você
Um ataque homográfico precisa de uma marca reconhecível para falsificar. Isso não é motivo para evitar construir uma. Um link curto de marca distintivo, que seu público associa a você, dá a ele algo com que comparar uma mensagem suspeita. Um domínio genérico compartilhado dá ao atacante um molde. Os clientes não conseguem distingui-lo do provedor real.
Configurar um domínio personalizado faz com que todo link que você envia leve um nome que os destinatários conhecem, o que eleva a barreira para quem tenta falsificá-lo. Veja como funcionam os domínios personalizados no Elido; você tem um no Pro e cinco no Business. Isso é o oposto do cloaking de links, que é uma escolha declarada de rotear links pelo seu próprio domínio. Um ataque homográfico esconde a identidade do atacante enquanto imita a sua.
Controles do registrador para domínios que você possui
O registrar lock, muitas vezes exibido como clientTransferProhibited, bloqueia transferências automáticas de rotina. Ative-o. O registry lock aciona o operador do registro, de modo que qualquer alteração, transferência ou exclusão exige verificação manual por outro canal. Reserve-o para os domínios em que uma alteração não autorizada sairia cara.
Nenhum dos dois impede que alguém registre um domínio parecido ao lado do seu. Só o monitoramento pega isso: acompanhe novos registros e os logs de transparência de certificados em busca de nomes próximos à sua marca, e mantenha um responsável nomeado e um caminho para denunciar um domínio parecido ao registrador. O checklist de segurança para escolher um provedor de links cobre controles adjacentes de fornecedores.
Uma receita de verificação que qualquer pessoa pode seguir
Você não precisa entender punycode. Quatro passos pegam quase tudo em que esse ataque se apoia.
- Expanda o link primeiro. Como ver para onde vai uma URL curta lista as ferramentas, e o verificador de links do Elido é uma delas. Em um link curto do Elido, adicionar
+ao final mostra uma página de prévia com o destino em vez de redirecionar. - Leia o domínio registrável, a parte logo antes do domínio de topo. É a parte que um atacante precisa controlar.
- Procure um rótulo
xn--na URL expandida ou na barra de endereços. Onde você esperava um nome de marca simples, pare e trate-o como um domínio parecido. - Confira o nome no certificado do destino. Ele reflete o que foi emitido ao dono do domínio, o que é mais difícil de falsificar de forma convincente que um rótulo renderizado, embora certificados também sejam emitidos a domínios parecidos, então um cadeado não prova honestidade.
Um ataque homográfico é um problema de exibição, não um bug de protocolo. O punycode faz o que foi projetado para fazer; o engano acontece entre o que um domínio é e o que o software mostra a você. Os navegadores fecharam a maior parte dessa distância na barra de endereços. Em todo o resto, ela está aberta. Expandir um link e ler o domínio registrável continua sendo o hábito que funciona, qualquer que seja o canal que o entregou.
Relacionados no blog
Perguntas frequentes
O que é um ataque homográfico IDN?
Ele registra um domínio com caracteres de outro alfabeto que parecem iguais aos de um domínio real, de modo que o leitor não consegue diferenciá-los. O caso clássico troca uma letra latina por uma parecida do alfabeto cirílico ou grego. Os dois domínios diferem no nível do ponto de código, então donos diferentes podem ser titulares de cada um. O ataque funciona só pela aparência, e é por isso que mira nomes de marcas conhecidas.
O que é punycode e por que ele existe?
O punycode, definido na RFC 3492, transforma um rótulo de domínio não ASCII em uma string ASCII que o DNS consegue armazenar e resolver. Um domínio escrito em cirílico, árabe, chinês ou com letras latinas acentuadas é convertido assim antes da consulta, e o rótulo codificado sempre começa com xn--. Os navegadores o decodificam de volta para exibição. Isso é um recurso legítimo, não a vulnerabilidade em si.
O que significa o prefixo xn-- em uma URL?
Ele marca um rótulo como a codificação compatível com ASCII de um nome que continha caracteres não ASCII. No exemplo deste texto, xn--nvacloud-nbh.com decodifica para um nome que parece novacloud.com com um o latino trocado por um cirílico. Um domínio ASCII comum nunca produz um rótulo xn--, então ver um onde você esperava uma marca conhecida merece uma segunda olhada.
Os navegadores protegem contra ataques homográficos?
Em boa parte, na barra de endereços. O Chrome mostra punycode em vez de Unicode quando um rótulo mistura latino, cirílico ou grego, quando é um confundível de alfabetos mistos ou quando o seu skeleton coincide com o de um domínio de topo. Firefox e Safari têm regras próprias. Atacantes ainda podem usar imitações em um único alfabeto que escapam, e a proteção não acompanha o link até o e-mail, o chat ou um código QR.
Como saber se um link é um domínio parecido antes de clicar?
Expanda o link para ver o destino real, leia o domínio registrável logo antes do domínio de topo e procure um rótulo xn--. Se um aparecer onde você esperava um nome de marca simples, trate-o como um domínio parecido até prova em contrário. Digitar o endereço você mesmo ou usar um favorito salvo para bancos e páginas de pagamento evita a questão por completo.
O que é registry lock e meu domínio precisa dele?
O registry lock bloqueia qualquer alteração, transferência ou exclusão de um domínio até que seja verificada por outro canal, geralmente por telefone ou uma frase secreta, de modo que nem uma conta de registrador comprometida consiga movê-lo. É mais forte que o registrar lock, que só bloqueia transferências automáticas de rotina. Serve para os domínios cujo sequestro seria caro, normalmente o domínio principal da sua marca. Ele não impede que alguém registre um domínio de aparência parecida ao lado do seu; isso é tarefa do monitoramento.
Experimente Elido
Cole uma URL, obtenha um link curto
Sem cadastro. O link vive 30 dias. Cadastre-se para mantê-lo para sempre.
É necessária uma conta grátis. O plano grátis inclui 25 links no total. Já tem uma conta? Entrar