Separe a internacionalização da personificação
Os nomes de domínio internacionalizados permitem que as pessoas usem rótulos de domínio além das tradicionais letras, dígitos e hífens ASCII. Essa capacidade é legítima e importante. A preocupação com a segurança não é a presença de um script específico; é se um identificador exibido pode ser confundido com outra identidade em um contexto consequente. Uma investigação homográfica ou de domínio confundível deve, portanto, preservar o nome real, sua representação DNS validada e a apresentação do destinatário, sem declarar malicioso todo nome não-ASCII.
RFC 5890 define a terminologia para nomes de domínio internacionalizados em aplicativos, incluindo rótulos A e rótulos U. Padrão Técnico Unicode 39 descreve mecanismos para identificar strings confundíveis. Estas são tarefas relacionadas, mas diferentes. A representação e validade da IDNA não são um veredicto sobre afiliação; uma comparação confusa não é prova de fraude. Este artigo propõe um método de revisão defensiva sem registrar nomes, enviar mensagens ou visitar domínios suspeitos.
Preserve os formulários em vez de recolhê-los
A seção 2.3.2.1 RFC 5890 define um rótulo A como a forma compatível com ASCII de um rótulo válido para IDNA e um rótulo U como seu formato Unicode sob os requisitos especificados. Nem toda string que começa com o familiar prefixo xn-- é um rótulo A válido. Um analisador deve validar o relacionamento em vez de tratar apenas o prefixo como prova. Da mesma forma, uma string Unicode arbitrária não é automaticamente um rótulo U válido simplesmente porque se parece com um rótulo de domínio.
Retenha o valor bruto observado antes da transformação. Em seguida, registre o analisador e a versão usada, os rótulos validados produzidos e quaisquer erros. Mantenha o valor exibido no cliente de email como uma observação separada. Uma captura de tela pode documentar a aparência, mas não pode substituir os pontos de código subjacentes ou o endereço analisado. Este manuscrito não executou uma ferramenta de normalização e não fornece conversões supostamente medidas. Exemplos reais devem ser gerados e retidos em um exercício de evidência autorizado.
Um esqueleto confuso não é um nome DNS
Unicode TR39 descreve a detecção confusa usando transformações e dados definidos. O documento atual retido inclui processamento de esqueleto com reconhecimento de direção e observa que as comparações podem ser excessivamente inclusivas. Um esqueleto é um artefato de comparação. Não deve ser usado como o endereço a ser consultado, o domínio a ser incluído na lista de permissões ou o valor a ser publicado no DNS . Duas strings correspondentes em um método de comparação não se tornam o mesmo domínio nem adquirem o mesmo proprietário.
Registre a versão dos dados Unicode, o algoritmo e as suposições de direção relevantes ao usar esse método. Não simplifique a especificação atual em uma instrução não documentada para colocar letras minúsculas e substituir caracteres visualmente semelhantes. Esse seria um algoritmo diferente com comportamento desconhecido. Se um produto oferecer uma pontuação de similaridade, mantenha o método e as limitações do produto separadamente do padrão. Uma pontuação pode priorizar a revisão humana sem estabelecer intenções maliciosas ou o comportamento real de exibição do receptor.
A apresentação depende da aplicação consumidora
O mesmo domínio subjacente pode ser apresentado de forma diferente por diferentes aplicações e contextos. Não prometa que todo cliente de e-mail exiba Unicode, sempre exponha um formulário ASCII ou avise consistentemente sobre scripts mistos. O resultado atual do receptor precisa de uma observação real do contexto relevante do cliente, versão, plataforma e mensagem. Este artigo não realizou essas observações e, portanto, não afirma que um determinado provedor exibiria ou bloquearia um nome de teste específico.
Ao coletar evidências autorizadas posteriormente, preserve a identidade bruta e o que o usuário viu. Inclua se o endereço foi expandido ou recolhido, se o nome de exibição foi mostrado separadamente e qual interface forneceu algum aviso. Evite generalizar a partir de uma captura de tela para todos os destinatários. A revisão da acessibilidade também é importante: uma semelhança visual e uma representação falada podem criar diferentes problemas de compreensão, mas nenhuma delas deve ser afirmada sem um exemplo observado apropriado.
A autenticação segue domínios, não semelhança percebida
RFC 9989, seção 2.2, afirma que DMARC não aborda nomes de domínio visualmente semelhantes ou abuso de nomes de exibição. Um domínio separado pode autenticar mensagens por si mesmo, mesmo quando um destinatário o confunde com uma organização confiável. Isso não é motivo para parar de verificar alinhamento. É uma razão para preservar a distinção entre o domínio real e a identidade que o destinatário infere da sua aparência.
Use evidências de autenticação de receptor confiável, seguindo as preocupações de limite de confiança em RFC 8601. Registre qual domínio foi autenticado e qual domínio visível foi avaliado. Não substitua esses domínios por um esqueleto confuso antes de avaliar seu relacionamento. A normalização de uma exibição para comparação não deve alterar silenciosamente a identidade do protocolo que está sendo investigada. Mantenha o resultado da autenticação e a questão do reconhecimento humano como observações interligadas, mas distintas.
Uma planilha de representação de identidade
Crie uma planilha com o campo da mensagem original, domínio bruto extraído, representação de ponto de código quando necessário, formulários validados de rótulo A e U, versão do analisador, resultado da validação e formulário do cliente exibido. Adicione o alvo de comparação de um registro comercial confiável, método e versão de detecção de confusão, resultado da comparação, proveniência da autenticação do receptor e ação solicitada. Inclua colunas separadas para fatos observados e interpretação do analista.
Para privacidade, edite o conteúdo da mensagem não relacionado e os identificadores pessoais, preservando as distinções exatas de domínio necessárias para o caso. Não publique um domínio realmente suspeito como um link clicável apenas para ilustrar a planilha. Use uma apresentação de evidências não interativa aprovada. Se sequências fictícias forem usadas para ensino, rotule-as como ilustrativas e não afirme que foram registradas, aceitas por um fornecedor ou exibidas por um receptor. Um resultado fabricado do receptor anularia o propósito da exigência de evidência.
Diagnóstico fictício: um nome que parece familiar
Um analista de compras fictício percebe que uma mensagem de fornecedor parece usar um nome familiar, mas uma visualização de endereço expandida revela um domínio subjacente diferente. A equipe de segurança propõe preservar o endereço bruto e comparar as representações validadas por meio de uma ferramenta documentada. Nesta fase, a equipa está preocupada com a confusão e não com a prova de intenção maliciosa ou propriedade. A alteração solicitada no registro do fornecedor permanece pausada no processo comercial normal.
A equipe verificaria a afiliação através de um contato de fornecedor já registrado de forma independente. Também reteria as provas reais do receptor se uma investigação autorizada prosseguisse. O caso hipotético não inclui deliberadamente nenhuma conversão Unicode inventada, saída de esqueleto ou afirmação de que um cliente de email nomeado exibiu uma string específica. Essas são observações que devem ser coletadas, e não detalhes a serem preenchidos por conveniência narrativa. Nenhum domínio foi consultado, registrado ou utilizado para envio de e-mail durante este trabalho.
Libere apenas com os exemplos necessários
Uma conclusão defensável distingue representação válida, similaridade, afiliação, autenticação e dano observado. Pode afirmar que um método de comparação encontrou confusão sem alegar crime. Pode indicar que um domínio diferente foi autenticado sem certificar a solicitação comercial. Pode documentar a apresentação de um receptor sem afirmar que todos os receptores se comportam da mesma maneira. Essas distinções tornam a orientação resultante útil em nomeações internacionalizadas legítimas, bem como em investigações de personificação.
O catálogo requer exemplos de identidade brutos e exibidos com formulários DNS normalizados e resultados do receptor. Essas observações originais permanecem abertas. Este manuscrito contém uma planilha e um processo de diagnóstico fictício, não essa evidência. A revisão de especialistas humanos, a aplicabilidade da fonte, as rotas de produção, a acessibilidade visual e a liberação do proprietário também permanecem em aberto. A publicação exige exemplos retidos e autorizados com versões exatas da ferramenta e resultados observados, revisados sem expor dados pessoais desnecessários ou fazer alegações infundadas sobre um operador de domínio.