MEDIUM

Open Redirect

El servidor redirige al usuario a cualquier URL sin validar el destino, facilitando phishing y bypass de controles de seguridad

Ejemplos de explotación:

Redirect a URL interna (legítima)

Redirigir a una ruta relativa interna — debería estar permitido

/api/lab/open-redirect?to=/api/users
Phishing — dominio externo

Redirigir a un dominio controlado por el atacante con apariencia legítima por el origen

/api/lab/open-redirect?to=https://evil-phishing.example.com/login
Protocol-relative URL (//)

//attacker.com hereda el protocolo, bypassea filtros que bloquean 'http://' explícitamente

/api/lab/open-redirect?to=//attacker.example.com
Subdomain spoofing bypass

Filtros que comprueban si la URL 'contiene aitana.cloud' son bypasseados

/api/lab/open-redirect?to=https://aitana.cloud.evil.com
Path-based bypass

Filtros de prefijo son bypasseados añadiendo el dominio legítimo como path

/api/lab/open-redirect?to=https://attacker.com?return=https://aitana.cloud
OAuth redirect_uri hijack

Si este redirect_uri se usa en OAuth, el atacante captura el authorization code

/api/lab/open-redirect?to=https://attacker.com/callback?code=
✅ Modo SEGURO — mismo dominio

Con ?safe=true el servidor valida el destino contra la allowlist

/api/lab/open-redirect?safe=true&to=/api/users
✅ Modo SEGURO — externo bloqueado

Dominio externo bloqueado por la allowlist en modo seguro

/api/lab/open-redirect?safe=true&to=https://evil.example.com

Vulnerabilidad Media

El parámetro ?to= se usa directamente en la redirección HTTP 302 sin validar el dominio de destino. Un atacante puede construir un enlace con el dominio legítimo (aitana.cloud/api/lab/open-redirect?to=...) que redirige a un sitio de phishing. Los usuarios ven el dominio legítimo en el enlace. También permite bypass de controles de seguridad basados en el Referer, y puede usarse para robar tokens OAuth. CVSS 6.1 — OWASP A01:2021.

Esta aplicación es vulnerable por diseño - Solo para propósitos educativos

© 2025 Aitana Security Lab