Cómo las solicitudes de nombres de host Unicode pueden aprobar el destino equivocado

Una tarjeta de aprobación para la solicitud HTTP de un agente es un límite de seguridad, no un simple aviso. Si la tarjeta indica un destino y la pila HTTP envía las credenciales a otro, el usuario no tomó una decisión informada. La pasarela decidió por él, con una tipografía más agradable.

Unicode facilita crear esa discrepancia porque un nombre de host tiene varias formas que parecen relacionadas, pero cumplen funciones distintas. El usuario puede ver Unicode. DNS recibe etiquetas compatibles con ASCII. Un analizador de URL puede normalizar separadores, escapes porcentuales, mayúsculas y minúsculas, la notación IPv4 o una etiqueta final vacía. Un gestor de redirecciones puede analizar la siguiente ubicación mediante otra ruta de código. Si una capa aprueba una representación y otra conecta usando una representación diferente, las credenciales pueden acabar en la autoridad equivocada.

La solución no es «prohibir los dominios no ASCII». Eso penaliza los nombres internacionales legítimos y deja intactos trucos ASCII como subdominios engañosos, userinfo, formas numéricas de IP y saltos de redirección. La solución consiste en convertir un único registro de autoridad analizado en el único objeto que pueda llegar a la interfaz de aprobación y autorizar la inyección de credenciales. Después hay que probar las entradas problemáticas antes de llegar a producción.

La tarjeta de aprobación debe describir la solicitud que se ejecutará

La solicitud de aprobación debe proceder del mismo objeto de solicitud canónico que ejecutará el cliente HTTP. Cualquier otra opción crea dos fuentes de verdad: una cadena para que la vean las personas y otra para el transporte del código. Esa separación es la que convierte la confusión del nombre de host en una filtración de credenciales.

Construye la solicitud en este orden:

1. Acepta la URL sin procesar como una entrada no confiable y analízala una sola vez con la implementación de URL elegida para la pasarela.
2. Rechaza los esquemas no compatibles, las autoridades mal formadas, las credenciales incrustadas y las entradas cuya forma canónica no cumpla las reglas de nombres de host.
3. Obtén un registro de autoridad estructurado con el esquema, el host canónico, el puerto efectivo y una marca que indique si la entrada tenía un punto raíz final.
4. Genera la tarjeta de aprobación a partir de ese registro y entrega el mismo registro al código que selecciona e inyecta las credenciales.
5. Exige una nueva autorización si una redirección, un reintento, un proxy o una dirección alternativa cambia el registro de autoridad.

Una URL sin procesar es una prueba, no una autoridad. Consérvala en el registro de actividad porque ayuda a explicar qué intentó hacer el agente. No la uses por sí sola para asociar credenciales, almacenar aprobaciones en caché o mostrar el destino.

En HTTP, la autoridad es algo más que un nombre de host aislado. https://api.example.test:8443/ y https://api.example.test/ pueden llevar a servicios y políticas de certificados distintos. El puerto predeterminado puede omitirse en la pantalla después de que el analizador lo establezca, pero un puerto no predeterminado debe aparecer en la tarjeta. También hay que mostrar el esquema. Enviar un token bearer mediante http en lugar de https cambia el riesgo aunque el texto del host sea idéntico.

RFC 3986 define la parte de host como un literal IP, una dirección IPv4 o un nombre registrado. Es una sintaxis útil, pero no indica a un sistema de aprobación qué puede reconocer una persona de forma segura. Trata el análisis como un requisito previo y construye después una representación específica de seguridad a partir del resultado analizado.

Punycode es un identificador, no un nombre amigable

Punycode existe para que DNS pueda transportar etiquetas internacionalizadas mediante ASCII. Una A-label comienza con el prefijo ASCII xn seguido de dos guiones, mientras que una U-label es la forma Unicode correspondiente. La conversión solo es reversible cuando la etiqueta es válida según las reglas IDNA aplicables. Esta diferencia importa porque una cadena que solo se parece a una A-label no es automáticamente válida ni segura para mostrarla como Unicode.

RFC 5891 exige que una aplicación de consulta compatible con IDNA valide una A-label aparente antes de tratar su salida Unicode decodificada como una U-label. En particular, cuando una aplicación decodifica una A-label para mostrarla en el idioma del usuario, debe comprobar que volver a convertirla produce la etiqueta original. Ese recorrido de ida y vuelta no es una cuestión académica. Sin él, una interfaz puede transformar ASCII mal formado en un texto Unicode convincente y entregar al revisor una historia que el transporte nunca contó.

La tarjeta de aprobación debe mostrar ambas formas cuando la entrada esté internacionalizada:

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

Coloca el nombre de host ASCII canónico en su propia línea, con una tipografía monoespaciada o un tratamiento igualmente legible. No lo ocultes detrás de un control desplegable. La representación Unicode ayuda a reconocer un servicio legítimo, pero la forma ASCII es el identificador estable que debe coincidir con las listas de permitidos, los registros de auditoría, las claves de caché y la ruta real de consulta DNS.

No decodifiques cada etiqueta solo porque comienza con el marcador de A-label. Decodifica, valida, vuelve a codificar y compara. Si la validación falla, muestra la etiqueta ASCII literal e indica claramente que el nombre de host no superó la validación IDNA. La acción segura es denegar la inyección de credenciales, no adivinar qué quiso decir el agente.

Aquí falla una recomendación popular: «Muestra siempre Unicode porque Punycode parece sospechoso». Ese consejo crea una interfaz amigable, pero elimina la única representación estable entre fuentes y sistemas de escritura. Mostrar solo ASCII tampoco es una buena práctica para un servicio internacionalizado legítimo. Muestra ambas formas, considera autoritativa la ASCII y asegúrate de que las dos procedan de un único resultado de análisis validado.

Los distintos scripts requieren una advertencia, no un veredicto falso

Un nombre de host que combina caracteres latinos y cirílicos puede parecer casi idéntico a un nombre ASCII. Por ejemplo, una etiqueta puede contener una letra cirílica minúscula que se parece a la a, c, e, o, p o x latina en muchas fuentes. Un revisor que examine rápidamente una tarjeta de aprobación puede pasar por alto la sustitución, especialmente cuando la parte significativa del nombre es corta.

Unicode Technical Standard #39 denomina a este caso un confusible de varios scripts cuando las cadenas son visualmente confundibles y el resultado no es un confusible de un solo script. También describe los confusibles de script completo, en los que una etiqueta usa un solo script pero se parece a otra etiqueta escrita en un sistema diferente. El estándar reconoce claramente el límite: la confusión depende de las fuentes, la composición contextual y la familiaridad de las personas. Un detector puede identificar el riesgo, pero no demostrar que un nombre sea engañoso.

Por eso una pasarela no debe convertir la comprobación de varios scripts en una lista de bloqueo automática. Una organización japonesa, coreana, china, griega o multilingüe puede tener un dominio legítimo que incumpla una regla simplista. Usa la señal para cambiar el nivel de aprobación:

• Marca toda etiqueta con resultado de varios scripts para exigir una aprobación explícita por llamada.
• Muestra los scripts y los puntos de código en una vista detallada cuando el revisor amplíe el host.
• Compara el esqueleto UTS #39 del nombre de host con los nombres internos protegidos y los destinos de alto valor configurados explícitamente.
• Deniega la reutilización automática de credenciales si el destino puede confundirse con un nombre protegido, aunque no haya aparecido antes.
• Registra la versión y el resultado del detector en el historial de actividad para que una revisión posterior pueda reproducir la decisión.

El esqueleto sirve para comparar, no para sustituir al nombre de host. UTS #39 indica explícitamente que los resultados del esqueleto no son adecuados para mostrarse, almacenarse o transmitirse como identificadores. Guarda el host ASCII canónico. Usa el esqueleto solo para responder a una pregunta concreta: «¿Se parece este candidato a un nombre que hemos decidido proteger especialmente?»

El conjunto de nombres protegidos debe ser pequeño e intencionado. Incluye tus propios puntos de despliegue, registros de paquetes, servidores de control de código fuente, proveedores de identidad y API de pagos o producción. No generes una lista enorme de todos los dominios públicos que podrían ser importantes. Crearás advertencias que nadie leerá y la advertencia relevante acabará pareciendo rutinaria.

Los puntos de código invisibles convierten la revisión en un problema de visualización

Los caracteres invisibles son peores que los caracteres no ASCII evidentes porque el revisor no puede verlos de forma fiable. Según el carácter y el software implicado, pueden afectar al comportamiento de unión, la dirección del texto, los saltos de línea o la selección de glifos. Algunos pueden ser rechazados por IDNA. Otros pueden mapearse o gestionarse de manera distinta según la biblioteca. El flujo de aprobación no debe depender de que un revisor detecte la ausencia de tinta.

Hay dos preguntas distintas que los equipos suelen mezclar:

1. ¿Es válido este punto de código en una etiqueta de nombre de host IDNA?
2. ¿Puede este punto de código hacer que la pantalla de aprobación resulte engañosa, que el registro sea ambiguo o que el código de comparación sea incoherente?

Superar la primera pregunta no resuelve la segunda. IDNA tiene reglas contextuales para algunos puntos de código y su validación de consulta rechaza varias categorías de entradas no válidas. Pero una pasarela HTTP también trabaja con URL sin procesar, interfaces, registros JSON, texto copiado y posiblemente formas de host que no proceden de DNS. La revisión de seguridad necesita reglas para toda esa ruta, no solo para la validez DNS. RFC 5891 indica que IDNA se aplica a nombres de dominio, no a texto libre arbitrario. Limítalo al procesamiento de nombres de host y no finjas que sanea una URL completa.

En una pantalla de aprobación, rechaza un nombre de host antes de inyectar credenciales si su representación Unicode analizada contiene un punto de código ignorado por defecto, un control bidireccional o un carácter que la implementación IDNA elegida considere inválido. Es deliberadamente más estricto que «prueba la consulta y comprueba qué ocurre». Un navegador público anónimo puede decidir intentar una consulta. Una pasarela de credenciales no debe enviar un token mientras investiga una cadena ambigua.

Al registrar una entrada rechazada, conserva dos formas: una secuencia de puntos de código escapada de forma segura y la secuencia de bytes original o el texto UTF-8 en un campo que no sufra una normalización silenciosa. Una buena entrada de actividad contiene texto como este:

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

No pongas el nombre de host sin procesar dentro de una frase que un operador pueda leer por encima. Los registros suelen convertirse en la siguiente interfaz de aprobación durante la respuesta a incidentes. Si un carácter invisible vuelve a ser invisible en un terminal, solo has trasladado la trampa.

Un punto final es un dato, aunque DNS lo trate como la raíz

Un nombre de host que termina en un punto no contiene una puntuación decorativa. En la forma de presentación DNS, el punto final representa la etiqueta raíz e indica que el nombre es absoluto. RFC 1034 explica que todo nombre de dominio completo termina en la etiqueta raíz y que, por eso, su forma impresa termina en un punto.

Eso no significa que todos los componentes HTTP traten api.example.test y api.example.test. de la misma manera. Un analizador puede conservar el punto en su propiedad de nombre de host. Otro puede normalizarlo antes de conectarse. Un verificador de certificados, una implementación de cookies, un proxy, una lista de permitidos o una caché de redirecciones pueden comportarse de una tercera forma. La única regla segura es decidir si tu pasarela los considera equivalentes y probar esa decisión en todos los componentes que gestionan la solicitud.

Para una pasarela de credenciales, recomiendo conservar el dato de entrada y normalizar la autoridad solo después de definir una regla de comparación documentada. Guarda ambas cosas:

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

Después usa canonical_dns_name para asociar el registro del destino, pero muestra el punto final en la tarjeta de aprobación cuando estuviera presente. El revisor debe ver que el agente proporcionó una forma ligeramente inusual. Un punto normal no debe ampliar la autoridad en silencio. Si se aprobó una credencial para api.example.test, la solicitud para api.example.test. solo puede reutilizar esa aprobación si el analizador, el resolvedor, el verificador del nombre TLS y la regla de comparación de la pasarela coinciden en que se trata del mismo destino.

No elimines un punto final con código genérico de cadenas antes del análisis. El recorte genérico suele convertirse en «limpiar el host» y pronto elimina espacios, puntuación o separadores Unicode que deberían haber provocado un rechazo. Analiza primero. Normaliza solo los atributos que tengan una regla semántica escrita.

El conjunto de pruebas del analizador necesita casos hostiles, no ejemplos de una presentación

Una suite de pruebas de nombres de host debe comprobar que el análisis, la canonicalización, la visualización, la asociación de credenciales, la conexión y los registros coinciden. Probar una función auxiliar que convierte una etiqueta Unicode a ASCII es útil, pero no demuestra que la ruta completa de la solicitud sea segura.

Usa primero el entorno de URL de producción. El siguiente script de Node prueba el analizador de URL WHATWG e informa de los campos que una pasarela de aprobación debería comparar. Imprime JSON deliberadamente para que las diferencias sean legibles en 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 }));
  }
}

La forma esperada de la salida importa más que una cadena universal, porque los entornos cambian y las reglas de análisis de hosts varían según la plataforma. Cada caso aceptado debe producir exactamente un nombre de host canónico que llegue a todas las etapas posteriores. Cada caso rechazado debe demostrar que la pasarela no adjunta credenciales ni realiza una solicitud de red.

Amplía el conjunto con etiquetas de los scripts que tu equipo encuentre realmente, caracteres Unicode parecidos a puntos, codificación porcentual en el host, marcas combinantes iniciales, corchetes y formas IPv6, A-labels en mayúsculas, A-labels mal formadas, etiquetas vacías, nombres locales y redirecciones. Añade casos procedentes de informes de errores. La suite se vuelve útil cuando contiene las cadenas que hicieron maldecir a un ingeniero frente a un archivo de registro, no cuando incluye diez variaciones de example.com.

WHATWG URL Standard es una buena referencia para el comportamiento de las URL web porque especifica el análisis de hosts, los fallos de hosts codificados porcentualmente, el procesamiento de Unicode a ASCII y los casos extremos de IPv4. No autoriza a suponer que todas las pilas HTTP, bibliotecas DNS o componentes de interfaz se comportan igual. Ejecuta el conjunto en tu pila real.

Las redirecciones necesitan una nueva decisión sobre la autoridad

La primera aprobación no autoriza todos los hosts que una solicitud pueda visitar después. El tratamiento de redirecciones suele vivir por debajo del código de aplicación que mostró la solicitud, por lo que es un lugar habitual para trasladar credenciales por accidente.

Supón que un agente solicita https://build.example.test/artifact. El usuario aprueba un token de despliegue para ese host. La respuesta devuelve una redirección a https://downloads.example.test/file o, peor aún, a un nombre de host Unicode parecido. Si el cliente sigue las redirecciones automáticamente y conserva el encabezado Authorization, la pasarela ha saltado el límite de aprobación.

Usa una regla sencilla: una redirección HTTP que cambie el esquema, el nombre de host canónico o el puerto efectivo invalida la autorización anterior de credenciales. La pasarela puede seguir la redirección sin credenciales si el comportamiento es seguro para la operación, pero debe detenerse antes de inyectar una credencial en la nueva autoridad. Muestra una nueva tarjeta de aprobación construida a partir de la URL recién analizada.

También hay que separar un cambio de origen de un cambio de ruta. Una redirección dentro del mismo esquema, host y puerto canónicos puede conservar la autorización si las reglas de ruta de la operación lo permiten. No reduzcas esto a una comparación de prefijos de texto. https://api.example.test.evil.test/ empieza con una cadena tranquilizadora, pero pertenece a otro host.

Para los tokens bearer, elimina Authorization por defecto en toda redirección entre autoridades. En el caso de certificados de cliente y credenciales al estilo SSH, la capa de transporte puede elegir una identidad antes de que exista una redirección, así que la pasarela necesita una regla equivalente al establecer la conexión. El principio es el mismo: la autorización está vinculada a una autoridad analizada, no a la intención inicial del agente.

La selección de credenciales necesita límites exactos

Una pasarela que guarda varias claves API debe decidir cuál puede enviarse a un host. No es una cuestión de interfaz. Es el punto en el que un error de visualización se convierte en una acción de red.

Guarda la asociación de una credencial como datos estructurados, por ejemplo:

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

Evita una regla como host.endsWith("example.test"). Acepta notexample.test, y una variante descuidada que compruebe si hay un punto delante aún puede gestionar mal la normalización Unicode o un punto raíz final. Si admites subdominios, separa las etiquetas ASCII canónicas y compáralas de derecha a izquierda. api.example.test solo puede coincidir con el dominio principal example.test cuando la asociación permita explícitamente los subdominios. El dominio principal nunca debe coincidir con el hijo al revés.

Mantén los literales IP separados de los nombres registrados. No hagas una resolución inversa de una IP para aplicar después una regla de credenciales de nombre de host. Los nombres DNS pueden cambiar y el DNS inverso no demuestra que una IP esté autorizada para una credencial API. Del mismo modo, no resuelvas un nombre de host y apruebes todas las direcciones que devuelva. La credencial está vinculada al nombre de host usado para TLS y la autoridad HTTP, mientras que los controles de conexión pueden limitar por separado las direcciones privadas, de bucle local, de enlace local u otras direcciones no permitidas.

Una pasarela también debe distinguir entre una asociación de credencial y una aprobación. La asociación responde a «¿podría usarse alguna vez esta credencial aquí?». La aprobación responde a «¿autorizó una persona a este proceso del agente a usarla para esta solicitud o sesión?». Confundir ambas preguntas es la forma en que una lista de permitidos se convierte en un oráculo de firma desatendido.

Los registros de auditoría deben conservar lo que vio el revisor

Cuando una aprobación posterior parece incorrecta, los operadores necesitan responder a tres preguntas: qué envió el agente, qué autoridad canónica ejecutó la pasarela y qué texto exacto vio el revisor. Una única URL renderizada no puede responder a las tres.

Registra estos campos por separado:

• la URL sin procesar o una representación escapada de forma segura;
• el esquema analizado, el nombre de host ASCII canónico, el puerto efectivo y la ruta;
• la representación validada del nombre de host Unicode, si existe;
• indicadores de riesgo del host, como el punto raíz final, el resultado de varios scripts, la coincidencia con un nombre protegido confusable y el rechazo de caracteres invisibles;
• la decisión de aprobación, el identificador de la credencial y si la pasarela adjuntó credenciales.

Haz que el registro de aprobación sea inmutable antes de que el cliente comience la solicitud. Si después el cliente sigue una redirección, crea un registro hijo vinculado con su propia autoridad analizada y su propia decisión. Una línea de registro que diga «la solicitud aprobada tuvo éxito» no basta cuando el dato relevante es que el primer host devolvió una cabecera Location hacia un segundo host.

La separación de Sallyport entre un diario de sesiones para las ejecuciones de los agentes y un diario de actividad para las llamadas individuales es una estructura adecuada para estas pruebas: la sesión indica qué proceso recibió la autoridad, mientras que el registro de la llamada indica qué destino la utilizó. Su registro de auditoría encadenado mediante hashes puede verificar el historial sin conexión, pero los campos útiles aún deben capturarse antes de que ocurra la acción. Un campo vacío que no se puede alterar sigue siendo un campo vacío.

Haz que los nombres de host sospechosos le cuesten autoridad al agente, no claridad al revisor

La interfaz de aprobación más segura no pide a una persona que se convierta en especialista en Unicode en dos segundos. Hace que las formas arriesgadas requieran más autoridad del agente y proporciona al revisor pruebas suficientes para decidir con claridad.

Usa esta matriz de comportamiento:

No hagas que la tarjeta de advertencia sea teatral. Un bloque enorme de texto rojo enseña a las personas a hacer clic para continuar. Explica el motivo con palabras sencillas: «Este nombre de host mezcla caracteres latinos y cirílicos» o «Este nombre de host contiene un carácter Unicode invisible». Después presenta el host ASCII canónico, la credencial solicitada y la acción. Las personas aprueban acciones, no lecciones.

La primera prueba que debes añadir es una solicitud que parezca corresponder a un host protegido para un lector casual, pero que se analice como otra autoridad. Ejecútala mediante el adaptador exacto del agente, la interfaz de aprobación, el selector de credenciales, la biblioteca HTTP, el código de redirecciones y el registrador de auditoría. Si alguna etapa produce una cadena de nombre de host diferente sin provocar un rechazo, la pasarela todavía tiene dos verdades. Corrígelo antes de añadir otro interruptor de política.