El callback de inicio de sesión SSO tiene un open redirect (redirige a cualquier URL pasada en un parámetro). ¿Cuál es el riesgo?
Respuesta breve
Un open redirect en un flujo de autenticación permite al atacante crear un enlace de login de apariencia fiable que, tras la autenticación, envía al usuario — y potencialmente un código de autorización o token — a un dominio controlado por el atacante, permitiendo el secuestro de cuenta y un phishing convincente. Corríjalo allow-listando estrictamente los redirect URI exactos del lado del servidor y rechazando cualquier otro. No es cosmético ni un problema de rendimiento, y HTTPS no ayuda porque el destino del atacante también puede ser un sitio HTTPS válido.
Un open redirect suele descartarse como de baja gravedad — hasta que se sitúa en un callback de autenticación. Allí deja de ser una molestia de phishing para convertirse en una vía hacia el secuestro de cuenta, porque lo que se redirige puede transportar credenciales, un código de autorización o un token.
Por qué el riesgo es alto
En un flujo SSO/OAuth, el usuario se autentica y el proveedor lo devuelve a su callback, que luego lo reenvía más adelante. Si ese destino de reenvío lo controla el atacante (porque el parámetro de redirección no se valida), suceden dos cosas malas:
- Phishing con un dominio real y de confianza. El enlace malicioso parte de su URL de login legítima, así que supera la comprobación «¿es el sitio real?» del usuario, y luego lo rebota a la página del atacante para cosechar credenciales o consentimiento.
- Robo de token/código. Si el código de autorización o el token viaja a través de la redirección (en la URL o por fuga vía Referer/fragmento), el dominio del atacante lo recibe y puede canjearlo o reproducirlo para secuestrar la cuenta.
La solución correcta
Allow-liste estrictamente los redirect URI del lado del servidor, comparando contra un conjunto exacto y preregistrado de valores — no un prefijo, una subcadena ni una comprobación de «mismo dominio», todas las cuales eluden los atacantes (https://susitio.com.evil.com, //evil.com, trucos de ruta). Rechace cualquier cosa que no esté en la lista. Combine esto con el parámetro OAuth state (protección CSRF) y PKCE para endurecer el flujo de extremo a extremo.
Por qué las demás respuestas son incorrectas
- «Puramente cosmético» y «inicios de sesión ligeramente más lentos» juzgan muy mal la gravedad — el fallo puede filtrar el propio token que es la sesión del usuario.
- «Sin riesgo mientras el sitio use HTTPS» malinterpreta la amenaza: HTTPS protege la conexión, pero el atacante simplemente aloja su página de aterrizaje en su propio sitio HTTPS válido. El cifrado del transporte no hace nada para detener una redirección a un destino malicioso.
El entrevistador sondea si reconoce que un open redirect en una ruta de autenticación es una primitiva de robo de credenciales, y si recurre al allow-listing por coincidencia exacta en lugar de un filtro ingenioso pero eludible.
Posibles preguntas de seguimiento
- ¿Cómo se convierte un open redirect en un redirect_uri de OAuth en robo de código de autorización?
- ¿Por qué el allow-listing por coincidencia exacta es más seguro que la coincidencia por prefijo o por dominio?
- ¿Qué papel juegan el parámetro state y PKCE junto a la validación del redirect_uri?