Analizar URL

La descomposición viene de la interfaz `URL` incorporada y no de una expresión regular escrita a mano. Ese es el punto donde se separan las herramientas de este género: la especificación de la WHATWG está llena de reglas que uno no sospecha al construirlas por su cuenta, y en esas reglas viven los errores interesantes.

Un ejemplo es la normalización del host: se unifica el uso de mayúsculas, se quita un punto final y los nombres internacionalizados se convierten a Punycode. Una expresión regular lo deja todo tal cual, y entonces señala una diferencia entre dos direcciones que para cualquier navegador son la misma.

En `https://[email protected]/` el host es `malicioso.example` y no `ejemplo.com`: todo lo anterior a la arroba son credenciales. Es conforme a la norma y es la base de una de las técnicas de phishing más antiguas que existen, porque la vista se queda en el primer nombre conocido.

Por eso el host tiene aquí su propia línea. Quien revise una dirección sospechosa no tiene que contar, sino leer a dónde apunta de verdad. Y va en el mismo paquete: un nombre como `ejemplo.com.malicioso.example` es también una dirección en `malicioso.example`, porque lo que manda es el último par de etiquetas.

La dirección se descompone, no se abre. No hay petición al host, no hay vista previa y no hay resolución de redirecciones, y es una decisión y no una función que falte: quien está examinando una URL sospechosa es el último que quiere que la herramienta la visite.

Visitarla además delataría algo. La petición saldría de un servidor, su IP y la hora quedarían en el registro del otro lado, y con una dirección de un solo uso — un enlace de confirmación, un restablecimiento de contraseña — la gastaría por el camino. Descomponer es la operación inofensiva, y es la única que ocurre aquí.

Un `..` en la ruta se resuelve al analizar: `/docs/a/../b` se convierte en `/docs/b`. Forma parte de la normalización y no es algo que esta herramienta añada — cualquier navegador lo hace antes de lanzar la petición, y un servidor no ve nunca la forma original.

Importa en todo lo que compare rutas o decida permisos sobre ellas. Quien compruebe una regla de acceso contra la cadena en bruto en lugar de contra la ruta normalizada está comprobando otra cosa distinta de la que se va a pedir — el agujero que se conoce como path traversal desde hace décadas.

Todo lo que va después de `#` se queda en el navegador. No aparece en ninguna petición, no llega a ningún servidor y no consta en ningún registro de acceso. Es una propiedad de HTTP y no una función de privacidad, y corta en las dos direcciones.

Es útil porque un valor ahí no llega al servidor — históricamente, el motivo por el que los tokens de OAuth viajaban en el fragmento. Es incómodo porque aun así queda en el historial, en la cadena de referrer de algunos scripts y en cualquier enlace compartido. «No llega al servidor» no significa «es privado».

Si el puerto es el habitual del esquema — 443 en https, 80 en http — el analizador lo omite, porque es redundante. `https://ejemplo.com:443/` y `https://ejemplo.com/` son la misma dirección, y la normalización lo hace visible.

Es la explicación habitual de que una comparación entre dos cadenas de URL falle aunque las dos signifiquen lo mismo. Quien compare direcciones debería pasarlas antes por un analizador y comparar la forma normalizada, que es justo la que aparece aquí en las líneas.

Una errata como `htp://ejemplo.com` no se rechaza: se lee como una dirección con el esquema `htp`. No es un fallo del analizador — la especificación admite cualquier esquema, porque hay cientos: `mailto:`, `tel:`, `git+ssh:`, `spotify:`, y ninguno puede saber cuáles son válidos en tu mundo.

En la práctica: si aquí aparece un esquema que no esperabas, has encontrado tu errata. Y significa además que una comprobación del tipo «¿se puede analizar?» no es una comprobación de que la dirección apunte a la web; para eso hay que contrastar el esquema con una lista explícita.

La forma `https://usuario:contraseña@host/` sigue existiendo, y aparece en scripts antiguos, en cadenas de conexión a bases de datos y en ejemplos de documentación. Los navegadores han restringido su uso porque era ideal para el phishing, pero las bibliotecas y las herramientas de línea de comandos la siguen aceptando.

Aquí se muestra el nombre de usuario y no la contraseña: en su lugar aparece una indicación de que hay una. El motivo es banal y cuenta igual — estos resultados acaban con frecuencia en una captura de pantalla o en un ticket, y una contraseña que ya se tiene no necesita imprimirse otra vez.

Un host con eñe o con tilde se convierte a Punycode: `español.example` se vuelve `xn--espaol-zwa.example`. Esa es la forma que existe de verdad en el DNS, porque el sistema de nombres solo conoce ASCII; la escritura legible es una ayuda visual del navegador.

Hacer visible lo que realmente se consulta tiene utilidad de seguridad. Los ataques homográficos usan caracteres de otras escrituras que se parecen a los latinos; en la forma Punycode saltan a la vista, porque en lugar de un nombre familiar aparece una sopa de letras.