Open Redirect

Open Redirect: cuando la web confía demasiado en una URL 🔀

El Open Redirect es una vulnerabilidad que aparece cuando una aplicación redirige al usuario a una URL indicada en un parámetro (por ejemplo newurl o redirect) sin validar que ese destino pertenezca a dominios de confianza. A simple vista parece inofensiva —al fin y al cabo la app no expone datos ni ejecuta código—, pero es un vector clásico para phishing (un enlace que empieza por el dominio legítimo pero termina en un sitio malicioso) y también puede usarse para amplificar ataques de denegación de servicio contra terceros. Vamos a verlo en la práctica con los laboratorios de skf-labs en Node.js, de menor a mayor dificultad.

🔍 Escenario 1 — Redirección sin validar

El primer laboratorio está en /skf-labs/nodeJs/Url-redirection. Para levantarlo:

npm install
npm start

Esto arranca el servicio en el puerto 5000. La aplicación muestra un botón “go to new web site” que, al interceptarlo con un proxy, revela la petición real:

POST /redirect?newurl=/newsite HTTP/1.1

Paso 1 — Modificar el destino: el parámetro newurl apunta a una ruta interna (/newsite), pero nada impide sustituirlo por una URL externa:

newurl=https://marca.com

El servidor redirige igualmente. Ahí está el Open Redirect: la aplicación confía ciegamente en el valor recibido y no comprueba que el destino sea propio o esté en una lista de dominios permitidos.

🚫 Por qué esto es peligroso más allá del phishing: existen botnets que escanean masivamente hosts vulnerables a Open Redirect y los usan como intermediarios para enviar peticiones contra un dominio víctima, generando así una denegación de servicio distribuida sin que el atacante toque directamente al objetivo —el tráfico “legítimo” sale desde el host vulnerable.

💡 Escenario 2 — Bypass del filtro de puntos

El segundo laboratorio, en /skf-labs/nodeJs/Url-redirection-harder, añade un filtro. Interceptando de nuevo con Burp Suite y probando:

POST /redirect?newurl=/newsite
POST /redirect?newurl=https://google.es

Esta vez la aplicación no redirige y devuelve el mensaje “Sorry, you cannot use "." in the redirect”: está bloqueando el punto en el dominio.

Paso 2 — Ofuscar el punto con URL-encoding: seleccionando el carácter . en Burp y usando click derecho > Convert selection > URL > URL-encode all characters, el punto se convierte en %2e. El problema es que el servidor sigue interpretando %2e como un punto normal y lo bloquea igual.

Paso 3 — Doble URL-encoding: la vuelta de tuerca es codificar también el símbolo %, de forma que %2e pase a ser %252e. El filtro del servidor no reconoce esa doble codificación como un punto, pero el navegador sí la decodifica correctamente al hacer la petición. Resultado, probando directamente en el navegador:

/redirect?newurl=https://google%252ees

Y la redirección funciona, saltándose el filtro por completo.

💡 Escenario 3 — Sin puntos ni barras

El tercer laboratorio, en /skf-labs/nodeJs/Url-redirection-harder2, endurece aún más el filtro: ahora bloquea tanto puntos como barras (/) en el parámetro de redirección. Aquí entra en juego un detalle de cómo funciona HTTPS: las dos barras (//) que separan el esquema del dominio en una URL no son estrictamente obligatorias para que muchos navegadores y clientes interpreten correctamente la URL. Eso significa que se puede construir una redirección al dominio externo omitiendo las barras, esquivando así ese filtro concreto.

✅ Cómo abordar esta vulnerabilidad en una auditoría

1. Prueba la redirección básica. Busca parámetros que huelan a redirección (redirect, newurl, next, url…) e inserta una URL externa arbitraria:

http://example.com/?redirect=http://malicious.com

2. Explora redirecciones internas. Intenta apuntar a recursos internos de la propia infraestructura que no deberían ser accesibles directamente:

http://example.com/?redirect=/admin

3. Explota la confianza en el dominio. Un Open Redirect permite construir enlaces que arrancan con el dominio legítimo pero acaban en una página de phishing que imita el login real, aprovechando que a simple vista el enlace “parece” de confianza.

4. Encadénalo con otros ataques. Si el parámetro no se escapa correctamente, puede ser susceptible a XSS, o servir para camuflar la URL real en un ataque CSRF:

http://example.com/?redirect=javascript:alert('XSS')

🔐 Conclusión

El Open Redirect se produce, en esencia, porque una aplicación web deja que un parámetro externo decida a dónde va el usuario sin validar ese destino contra una lista de dominios o rutas permitidas. Como hemos visto en los tres laboratorios, los filtros basados en bloquear caracteres concretos (puntos, barras) son frágiles: el doble URL-encoding o los detalles de cómo se parsea una URL HTTPS bastan para saltárselos. La mitigación correcta no pasa por filtrar caracteres, sino por validar el destino contra una lista blanca de dominios o rutas conocidas, o bien usar identificadores internos (como un índice) en lugar de aceptar URLs completas del usuario. Para profundizar en las técnicas de mitigación recomendadas, la OWASP Cheat Sheet sobre Unvalidated Redirects and Forwards es una referencia obligada.