Como as solicitações de hostname Unicode podem aprovar o destino errado

Um cartão de aprovação para a solicitação HTTP de um agente é um limite de segurança, não um aviso por cortesia. Se o cartão informa um destino e a pilha HTTP envia as credenciais para outro, o usuário não tomou uma decisão consciente. O gateway decidiu por ele, com uma tipografia mais agradável.

O Unicode facilita a criação dessa diferença porque um hostname tem várias formas que parecem relacionadas, mas cumprem funções diferentes. O usuário pode ver Unicode. O DNS recebe rótulos compatíveis com ASCII. Um analisador de URL pode normalizar separadores, escapes percentuais, maiúsculas e minúsculas, a notação IPv4 ou um rótulo final vazio. Um gerenciador de redirecionamentos pode analisar o próximo destino por outro caminho. Se uma camada aprova uma representação e outra se conecta usando uma representação diferente, as credenciais podem sair para a autoridade errada.

A solução não é «proibir domínios não ASCII». Isso pune nomes internacionalizados legítimos e ainda deixa passar truques ASCII, como subdomínios enganosos, userinfo, formas numéricas de IP e saltos de redirecionamento. A solução é fazer com que um único registro de autoridade analisado seja o único objeto capaz de chegar à interface de aprovação e autorizar a injeção de credenciais. Depois, teste as entradas problemáticas antes que elas cheguem à produção.

O cartão de aprovação deve descrever a solicitação que será executada

Uma solicitação de aprovação deve vir do mesmo objeto de requisição canônico que o cliente HTTP executará. Qualquer outra abordagem cria duas fontes de verdade: uma string de exibição para as pessoas e uma string de transporte para o código. É nessa separação que a confusão de hostname se transforma em divulgação de credenciais.

Monte a solicitação nesta ordem:

1. Aceite a URL bruta como uma entrada não confiável e faça o parsing uma única vez, usando a implementação de URL escolhida para o gateway.
2. Rejeite esquemas não compatíveis, autoridades malformadas, credenciais incorporadas e entradas cuja forma canônica não passe pelas regras de hostname.
3. Derive um registro de autoridade estruturado com esquema, host canônico, porta efetiva e um sinal que indique se a entrada tinha um ponto final de raiz.
4. Renderize o cartão de aprovação a partir desse registro e entregue o mesmo registro ao código que seleciona e injeta as credenciais.
5. Exija uma nova autorização se um redirecionamento, uma nova tentativa, um proxy ou um endereço alternativo alterar o registro de autoridade.

Uma URL bruta é uma evidência, não uma autoridade. Mantenha-a no registro de atividade, pois ela ajuda a explicar o que o agente tentou fazer. Não a use sozinha para associar credenciais, armazenar aprovações em cache ou exibir o destino.

No HTTP, a autoridade é mais do que um hostname isolado. https://api.example.test:8443/ e https://api.example.test/ podem levar a serviços e políticas de certificado diferentes. A porta padrão pode ser omitida na exibição depois que o analisador a estabelecer, mas uma porta não padrão deve aparecer no cartão. O mesmo vale para o esquema. Enviar um bearer token por http em vez de https muda o risco mesmo quando o texto do host é idêntico.

A RFC 3986 define a parte host como um literal IP, um endereço IPv4 ou um nome registrado. Isso é útil como sintaxe, mas não informa a um sistema de aprovação o que uma pessoa consegue reconhecer com segurança. Trate o parsing como um pré-requisito e construa uma exibição específica de segurança a partir do resultado analisado.

Punycode é um identificador, não um nome amigável

O punycode existe para que o DNS possa transportar rótulos internacionalizados usando ASCII. Um A-label começa com o prefixo ASCII xn seguido de dois hífens, enquanto um U-label é a forma Unicode correspondente. A conversão só é reversível quando o rótulo é válido segundo as regras IDNA aplicáveis. Essa distinção importa porque uma string que apenas se parece com um A-label não é automaticamente válida nem segura para ser exibida como Unicode.

A RFC 5891 exige que uma aplicação de consulta compatível com IDNA valide um A-label aparente antes de tratar sua saída Unicode decodificada como um U-label. Em particular, quando uma aplicação decodifica um A-label para exibição no idioma nativo, ela deve verificar se a conversão de volta produz o rótulo original. Essa ida e volta não é uma questão acadêmica. Sem ela, uma interface pode transformar ASCII malformado em um texto Unicode convincente e entregar ao revisor uma história que o transporte nunca contou.

O cartão de aprovação deve mostrar as duas formas quando a entrada for internacionalizada:

Destination
https://xn--example-ascii-label.test
Unicode rendering: example-unicode-label.test
Port: 443
Credential: deploy token

Coloque o hostname ASCII canônico em sua própria linha, com fonte monoespaçada ou outro tratamento muito legível. Não o esconda atrás de um controle de expansão. A representação Unicode ajuda uma pessoa a reconhecer um serviço legítimo, mas a forma ASCII é o identificador durável que deve corresponder às listas de permissões, aos registros de auditoria, às chaves de cache e ao caminho real da consulta DNS.

Não decodifique cada rótulo apenas porque ele começa com o marcador de A-label. Decodifique, valide, recodifique e compare. Se a validação falhar, mostre o rótulo ASCII literal com um aviso claro de que o hostname não passou pela validação IDNA. A ação segura é negar a injeção de credenciais, não tentar adivinhar o que o agente quis dizer.

Este é um caso em que uma recomendação popular falha: «Sempre exiba Unicode porque o punycode parece suspeito». Esse conselho cria uma interface amigável, mas remove a única representação estável entre fontes e sistemas de escrita. Exibir apenas ASCII também é uma má prática para um serviço internacionalizado legítimo. Mostre os dois formatos, trate o ASCII como autoridade e garanta que ambos venham do resultado de um único parser validado.

Scripts misturados merecem um alerta, não um veredito falso

Um hostname que combina caracteres latinos e cirílicos pode parecer quase idêntico a um hostname ASCII. Por exemplo, um rótulo pode conter uma letra cirílica minúscula que se parece com a, c, e, o, p ou x latinos em muitas fontes. Um revisor que examina rapidamente um cartão de aprovação pode não perceber a substituição, principalmente quando a parte significativa do nome é curta.

O Unicode Technical Standard #39 chama isso de confusable de scripts misturados quando as strings são visualmente confundíveis e o resultado não é um confusable de um único script. O padrão também descreve confusables de script completo, em que um rótulo usa um script, mas se parece com um rótulo de outro. O padrão é claro sobre a limitação: a confundibilidade depende das fontes, da forma contextual e da familiaridade das pessoas. Um detector pode identificar risco, mas não provar que um nome é enganoso.

Por isso, um gateway não deve transformar uma verificação de scripts misturados em uma lista de bloqueio automática. Uma organização japonesa, coreana, chinesa, grega ou multilíngue pode ter um domínio legítimo que falhe em uma regra simplista. Em vez disso, use o sinal para mudar o nível de rigor da aprovação:

• Marque qualquer rótulo com resultado de scripts misturados para exigir aprovação explícita a cada chamada.
• Mostre os scripts e pontos de código em uma visualização detalhada quando o revisor expandir o host.
• Compare o esqueleto UTS #39 do hostname com nomes internos protegidos e destinos importantes configurados explicitamente.
• Negue a reutilização automática de credenciais se o destino for confundível com um nome protegido, mesmo que ainda não tenha aparecido antes.
• Registre a versão e o resultado do detector no log de atividade para que uma análise posterior possa reproduzir a decisão.

O esqueleto é um artefato de comparação, não um substituto do hostname. A UTS #39 afirma explicitamente que os resultados do esqueleto não são adequados para exibição, armazenamento ou transmissão como identificadores. Armazene o host ASCII canônico. Use o esqueleto apenas para fazer uma pergunta restrita: «Este candidato se parece com um nome que decidimos proteger especialmente?»

O conjunto de nomes protegidos deve ser pequeno e intencional. Inclua seus endpoints de implantação, registros de pacotes, hosts de controle de versão, provedores de identidade e APIs de pagamento ou produção. Não crie uma lista enorme de todos os domínios públicos que possam ser importantes. Você produzirá alertas que ninguém lê, e o único alerta importante parecerá rotineiro.

Pontos de código invisíveis transformam a revisão em um problema de renderização

Caracteres invisíveis são piores que caracteres não ASCII óbvios porque o revisor não consegue vê-los de forma confiável. Dependendo do caractere e do software envolvido, eles podem afetar a junção, a direção do texto, as quebras de linha ou a seleção de glifos. Alguns podem ser rejeitados pelo IDNA. Outros podem ser mapeados ou tratados de forma diferente pelas bibliotecas. O fluxo de aprovação não pode depender de o revisor perceber a ausência de tinta.

Há duas perguntas distintas que as equipes costumam misturar:

1. Este ponto de código é válido em um rótulo de hostname IDNA?
2. Este ponto de código pode tornar a exibição enganosa, o log ambíguo ou o código de comparação inconsistente?

Passar na primeira pergunta não resolve a segunda. O IDNA tem regras contextuais para alguns pontos de código, e sua validação de consulta rejeita várias categorias de entradas inválidas. Mas um gateway HTTP também lida com URLs brutas, renderização da interface, logs JSON, texto copiado e possivelmente formas de host que não usam DNS. A revisão de segurança precisa de regras para todo esse percurso, não apenas para a validade no DNS. A RFC 5891 diz que o IDNA serve para nomes de domínio, não para texto livre arbitrário. Restrinja-o ao processamento de hostnames e não finja que ele higieniza uma URL completa.

Na tela de aprovação, rejeite um hostname antes da injeção de credenciais se sua renderização Unicode analisada contiver um ponto de código ignorável por padrão, um controle bidirecional ou um caractere que a implementação IDNA escolhida considere inválido. Isso é deliberadamente mais rigoroso do que «tente a consulta e veja». Um navegador público anônimo pode optar por tentar uma consulta. Um gateway de credenciais não deve enviar um token enquanto investiga uma string ambígua.

Ao registrar uma entrada rejeitada, preserve duas formas: uma sequência de pontos de código escapada com segurança e a sequência de bytes original ou o texto UTF-8 em um campo que não passe por normalização silenciosa. Uma boa entrada de atividade contém texto como:

raw_host_escaped: "api\\u200d.example.test"
parsed_host_ascii: null
rejection: "default-ignorable code point in hostname display"
credential_attached: false

Não coloque o hostname bruto em uma frase que um operador possa ler rapidamente. Os logs muitas vezes se tornam a próxima interface de aprovação durante a resposta a incidentes. Se um caractere invisível voltar a ficar invisível em um terminal, você apenas transferiu a armadilha.

Um ponto final é um dado, mesmo quando o DNS o trata como a raiz

Um hostname terminado em ponto não é uma pontuação decorativa. Na forma de apresentação do DNS, o ponto final indica o rótulo raiz e marca o nome como absoluto. A RFC 1034 explica que todo nome de domínio completo termina no rótulo raiz e que, por isso, a forma impressa termina em ponto.

Isso não significa que todos os componentes HTTP tratem api.example.test e api.example.test. da mesma forma. Um parser pode preservar o ponto em sua propriedade hostname. Outro pode normalizá-lo antes da conexão. Um verificador de certificados, uma implementação de cookies, um proxy, uma lista de permissões ou um cache de redirecionamentos pode adotar um terceiro comportamento. A única regra segura é decidir se o gateway trata os dois como equivalentes e testar essa decisão em todos os componentes que lidam com a solicitação.

Para um gateway de credenciais, recomendo preservar esse fato da entrada e normalizar a autoridade apenas depois de definir uma regra de comparação documentada. Armazene os dois dados:

input_host: "api.example.test."
canonical_dns_name: "api.example.test"
had_root_dot: true

Depois, use canonical_dns_name para comparar o registro de destino, mas mostre o ponto final no cartão de aprovação quando ele estiver presente. O revisor deve saber que o agente forneceu uma forma um pouco incomum. Um ponto normal não deve ampliar a autoridade silenciosamente. Se uma credencial foi aprovada para api.example.test, a solicitação para api.example.test. só pode reutilizar essa aprovação se o parser, o resolvedor, o verificador do nome TLS e a regra de comparação do gateway concordarem que se trata do mesmo destino.

Não remova um ponto final usando código genérico de strings antes do parsing. Esse tipo de remoção tende a evoluir para «limpar o host», o que logo passa a remover espaços, pontuação ou separadores Unicode que deveriam causar uma rejeição. Faça o parsing primeiro. Normalize apenas atributos que tenham uma regra semântica escrita.

O conjunto de testes do parser precisa de casos hostis, não de exemplos de apresentação

Uma suíte de testes de hostname deve verificar a concordância entre parsing, canonicalização, exibição, associação de credenciais, configuração da conexão e registro. Testar um helper que converte um rótulo Unicode em ASCII é útil, mas não prova que o caminho completo da solicitação é seguro.

Use o runtime de URL da sua produção na primeira etapa. O script Node a seguir exercita o parser de URL WHATWG e informa os campos que um gateway de aprovação deve comparar. Ele imprime JSON de propósito, para facilitar a leitura das diferenças na CI.

const cases = [
  "https://example.test/",
  "https://example.test./",
  "https://münich.example.test/",
  "https://xn\\u002d\\u002dexample-ascii-label.test/",
  "https://pаypal.example.test/",
  "https://api\\u200d.example.test/",
  "https://[email protected]/",
  "https://example.test:8443/",
  "https://127.0.0.1./"
];

for (const raw of cases) {
  try {
    const u = new URL(raw);
    console.log(JSON.stringify({
      raw,
      href: u.href,
      protocol: u.protocol,
      hostname: u.hostname,
      host: u.host,
      port: u.port,
      username: u.username,
      passwordPresent: u.password.length \u003e 0
    }));
  } catch (error) {
    console.log(JSON.stringify({ raw, rejected: error.message }));
  }
}

O formato esperado da saída importa mais do que uma string universalmente esperada, pois os runtimes mudam e as regras de parsing de host variam entre plataformas. Cada caso aceito deve produzir exatamente um hostname canônico que chegue a todas as etapas seguintes. Cada caso rejeitado deve provar que o gateway não anexa credenciais nem envia uma solicitação de rede.

Amplie o conjunto com rótulos dos scripts que sua equipe realmente encontra, caracteres Unicode semelhantes a pontos, codificação percentual no host, marcas combinantes iniciais, formas com colchetes e IPv6, A-labels em maiúsculas, A-labels malformados, rótulos vazios, nomes locais e redirecionamentos. Acrescente casos dos relatórios de bugs. A suíte se torna útil quando contém as strings que fizeram um engenheiro praguejar diante de um arquivo de log, não quando contém dez variações de example.com.

O WHATWG URL Standard é uma boa referência para o comportamento de URLs na web porque especifica o parsing de hosts, as falhas de hosts codificados em porcentagem, o processamento de Unicode para ASCII e os casos extremos de IPv4. Isso não autoriza presumir que toda pilha HTTP, biblioteca DNS ou componente de interface tenha comportamento idêntico. Execute o conjunto na sua pilha real.

Redirecionamentos exigem uma nova decisão sobre a autoridade

A primeira aprovação não autoriza todos os hosts que uma solicitação possa visitar depois. O tratamento de redirecionamentos costuma ficar abaixo do código da aplicação que exibiu a solicitação, o que o torna um local comum para encaminhar credenciais por acidente.

Imagine que um agente solicite https://build.example.test/artifact. O usuário aprova um token de implantação para esse host. A resposta redireciona para https://downloads.example.test/file ou, pior, para um hostname Unicode parecido com outro. Se o cliente seguir os redirecionamentos automaticamente e mantiver o cabeçalho Authorization, o gateway terá contornado o limite de aprovação.

Use uma regra simples: um redirecionamento HTTP que altere o esquema, o hostname canônico ou a porta efetiva invalida a autorização de credenciais anterior. O gateway pode seguir o redirecionamento sem credenciais se isso for seguro para a operação, mas deve parar antes de injetar uma credencial na nova autoridade. Mostre um novo cartão de aprovação construído a partir da URL recém-analisada.

Separe também uma mudança de origem de uma mudança de caminho. Um redirecionamento dentro do mesmo esquema, host e porta canônicos pode manter a autorização se as regras de caminho da operação permitirem. Não reduza isso a uma comparação de prefixos de texto. https://api.example.test.evil.test/ começa com uma string tranquilizadora, mas pertence a outro host.

Para bearer tokens, remova Authorization por padrão em todo redirecionamento entre autoridades. Para certificados de cliente e credenciais no estilo SSH, a camada de transporte pode escolher uma identidade antes mesmo que um redirecionamento seja possível, portanto o gateway precisa de uma regra equivalente no estabelecimento da conexão. O princípio permanece: a autorização se vincula a uma autoridade analisada, não à intenção inicial do agente.

A seleção de credenciais precisa de limites exatos

Um gateway que armazena várias chaves de API precisa decidir qual delas pode ser enviada a um host. Isso não é uma preocupação da interface. É o ponto em que um erro de exibição se transforma em uma ação de rede.

Armazene uma associação de credencial como dados estruturados, por exemplo:

{
  "scheme": "https",
  "host_ascii": "api.example.test",
  "port": 443,
  "allow_subdomains": false,
  "require_per_call_approval": true
}

Evite uma regra como host.endsWith("example.test"). Ela aceita notexample.test, e uma variante descuidada que verifica um ponto anterior ainda pode tratar incorretamente a normalização Unicode ou um ponto final de raiz. Se você permitir subdomínios, divida os rótulos ASCII canônicos e compare-os da direita para a esquerda. api.example.test só pode corresponder ao domínio pai example.test quando a associação permitir subdomínios explicitamente. O pai nunca deve corresponder ao filho no sentido inverso.

Mantenha literais IP separados de nomes registrados. Não faça uma resolução reversa de um IP e aplique depois uma regra de credencial de hostname. Os nomes DNS podem mudar, e o DNS reverso não prova que um IP está autorizado para uma credencial de API. Da mesma forma, não resolva um hostname e aprove todos os endereços retornados. A credencial se vincula ao hostname usado no TLS e na autoridade HTTP, enquanto os controles de conexão podem limitar separadamente endereços privados, de loopback, link-local ou outros endereços proibidos.

Um gateway também deve distinguir uma associação de credencial de uma aprovação. A associação responde «essa credencial poderia ser usada aqui?». A aprovação responde «uma pessoa autorizou este processo de agente a usá-la nesta solicitação ou sessão?». Misturar essas perguntas é como uma lista de permissões se transforma em um oráculo de assinatura sem supervisão.

Os registros de auditoria precisam preservar o que o revisor viu

Quando uma aprovação parece errada depois, os operadores precisam responder a três perguntas: o que o agente enviou, qual autoridade canônica o gateway executou e qual texto exato o revisor viu? Uma única URL renderizada não responde às três.

Registre estes campos separadamente:

• a URL bruta ou uma representação dela com escapes seguros;
• o esquema analisado, o hostname ASCII canônico, a porta efetiva e o caminho;
• a representação Unicode validada do hostname, quando existir;
• sinais de risco do hostname, como ponto final de raiz, resultado de scripts misturados, correspondência confundível com um nome protegido e rejeição por caractere invisível;
• a decisão de aprovação, o identificador da credencial e a informação sobre se o gateway anexou credenciais.

Torne o registro de aprovação imutável antes que o cliente inicie a solicitação. Se o cliente seguir um redirecionamento, crie um registro filho vinculado, com sua própria autoridade analisada e sua própria decisão. Uma linha de log dizendo «solicitação aprovada concluída» não basta quando o fato importante é que o primeiro host devolveu um cabeçalho Location apontando para um segundo host.

A separação do Sallyport entre um diário Sessions para as execuções dos agentes e um diário Activity para chamadas individuais é uma estrutura adequada para essa evidência: a sessão informa qual processo recebeu autoridade, enquanto o registro da chamada mostra qual destino a utilizou. O log de auditoria encadeado por hash pode verificar o histórico offline, mas os campos úteis ainda precisam ser capturados antes da ação. Um campo vazio, mesmo em um registro à prova de adulteração, continua vazio.

Torne hostnames suspeitos caros para o agente, não confusos para o revisor

A interface de aprovação mais segura não exige que uma pessoa se torne especialista em Unicode em dois segundos. Ela exige mais autoridade do agente para formas arriscadas e fornece ao revisor evidências suficientes para uma decisão clara.

Use esta matriz de comportamento:

Não transforme o cartão de alerta em um espetáculo. Um bloco de texto vermelho ensina as pessoas a clicar para avançar. Explique o motivo em linguagem simples: «Este hostname mistura caracteres latinos e cirílicos» ou «Este hostname contém um caractere Unicode invisível». Depois, mostre o host ASCII canônico, a credencial solicitada e a ação. As pessoas aprovam ações, não palestras.

O primeiro teste a adicionar é uma solicitação que parece ser de um host protegido para um leitor casual, mas é analisada como outra autoridade. Execute-a pelo shim exato do agente, pela interface de aprovação, pelo seletor de credenciais, pela biblioteca HTTP, pelo código de redirecionamento e pelo registrador de auditoria. Se qualquer etapa produzir uma string de hostname diferente sem causar uma rejeição, o gateway ainda tem duas verdades. Corrija isso antes de adicionar outra opção de política.