URLs codificadas explicadas: percent-encoding y sus riesgos
Si alguna vez ha visto una URL con secuencias como %20, %2F o %40, ha encontrado el percent-encoding. Esta técnica es un estándar fundamental de Internet, pero también la aprovechan los atacantes para disfrazar enlaces de phishing.
¿Qué es el percent-encoding?
El RFC 3986 —el estándar que define el formato de las URLs— establece que solo ciertos caracteres ASCII pueden aparecer directamente en una URL. Cualquier otro carácter debe representarse mediante el símbolo % seguido de dos dígitos hexadecimales que corresponden al valor del carácter en la tabla ASCII.
- Espacio →
%20 /→%2F@→%40:→%3A- Letra "p" →
%70
El navegador decodifica estas secuencias automáticamente antes de mostrar la dirección o conectarse al servidor.
¿Cuándo es legítimo el percent-encoding?
En el uso diario normal, el encoding aparece constantemente y de forma completamente inocua:
- En búsquedas:
?q=seguridad%20inform%C3%A1tica - En formularios: los espacios y caracteres especiales se codifican antes de enviarse.
- En rutas con caracteres no ASCII, por ejemplo acentos en nombres de archivo.
Cuando el encoding aparece en la ruta o en los parámetros de una URL conocida, no hay motivo de alarma.
¿Cómo abusan los atacantes del percent-encoding?
El abuso ocurre cuando los atacantes codifican el nombre del dominio completo o esconden una URL maliciosa dentro de un parámetro:
Codificar el nombre del dominio
En lugar de escribir paypal.com directamente, el atacante lo codifica carácter a carácter:
%70%61%79%70%61%6C.com=paypal.com
El navegador lo resuelve y accede al dominio real, pero los filtros de correo o los sistemas de reputación basados en texto plano no detectan la palabra "paypal" en la URL.
Esconder la URL de destino en un parámetro
Los atacantes aprovechan funciones de redirección legítimas para ocultar su destino:
https://sitio-conocido.com/ir?url=https%3A%2F%2Fphishing.xyz%2Flogin
La URL visible parece pertenecer a un sitio conocido. El destino real está codificado como valor del parámetro url=. Al decodificarlo: https://phishing.xyz/login.
Doble encoding
El atacante codifica la URL una segunda vez para eludir los filtros que solo decodifican una capa:
%252F→ primer decode →%2F→ segundo decode →/
Cómo detectar URLs codificadas sospechosas
- Muchos
%consecutivos en el nombre del dominio son una señal de alerta clara. - Un parámetro
url=,redirect=ogoto=seguido de una cadena codificada merece inspección. - Si la URL decodificada revela un dominio diferente al del enlace original, es sospechoso.
Cómo decodificar una URL codificada
Puede pegar la URL en 2check.click, que decodifica automáticamente todas las capas de encoding y muestra el destino real. También puede copiar el string codificado y usar un decodificador online básico, aunque esto no le dirá si el destino es malicioso.
Compruebe un enlace sospechoso
Pegue una URL, mensaje o código QR en 2check.click para analizar el destino, redirecciones, antigüedad del dominio y otras señales de phishing.
Preguntas frecuentes
¿Una URL con %20 es automáticamente sospechosa?
No. %20 para representar un espacio es completamente normal. Lo sospechoso es ver el nombre de dominio codificado carácter a carácter, o encontrar una URL completa de phishing escondida como valor de un parámetro.
¿Mi navegador muestra la URL codificada o decodificada?
Los navegadores modernos muestran generalmente la versión legible (decodificada) en la barra de direcciones. Para ver la URL codificada en bruto, cópiela y péguela en un editor de texto.
¿Puede el percent-encoding eludir los filtros antiphishing?
Sí, con frecuencia. Los filtros basados en listas de dominios conocidos buscan cadenas de texto exactas. Si el dominio está codificado como %70%61%79%70%61%6C, el filtro no lo reconoce como "paypal" y lo deja pasar.
¿Cuál es la diferencia entre encoding y cifrado?
El encoding (como el percent-encoding o Base64) transforma datos usando un algoritmo público y reversible sin clave. El cifrado protege datos con una clave y no puede revertirse sin ella. El encoding no ofrece seguridad; solo es una forma de representar datos.
¿Es diferente el encoding en la ruta y en el dominio?
En cuanto a la técnica, no. Pero en cuanto al riesgo, sí: encoding en la ruta o en los parámetros es muy común y generalmente inofensivo. Encoding en el nombre del dominio en sí es inusual y debe generar sospechas.