El servidor redirige al usuario a cualquier URL sin validar el destino, facilitando phishing y bypass de controles de seguridad
Redirigir a una ruta relativa interna — debería estar permitido
/api/lab/open-redirect?to=/api/usersRedirigir 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//attacker.com hereda el protocolo, bypassea filtros que bloquean 'http://' explícitamente
/api/lab/open-redirect?to=//attacker.example.comFiltros que comprueban si la URL 'contiene aitana.cloud' son bypasseados
/api/lab/open-redirect?to=https://aitana.cloud.evil.comFiltros de prefijo son bypasseados añadiendo el dominio legítimo como path
/api/lab/open-redirect?to=https://attacker.com?return=https://aitana.cloudSi este redirect_uri se usa en OAuth, el atacante captura el authorization code
/api/lab/open-redirect?to=https://attacker.com/callback?code=Con ?safe=true el servidor valida el destino contra la allowlist
/api/lab/open-redirect?safe=true&to=/api/usersDominio externo bloqueado por la allowlist en modo seguro
/api/lab/open-redirect?safe=true&to=https://evil.example.comEl 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