Una redirección abierta es una vulnerabilidad en la que una aplicación web toma una URL de destino de una entrada de usuario sin validar - normalmente un parámetro de consulta como ?next= o ?url= - y reenvía allí el navegador sin comprobarla. El enlace empieza en un dominio en el que la víctima confía, así que pasa la inspección, y luego la deposita silenciosamente en otro lugar. La corrección no es dejar de redirigir. Es dejar de permitir que la petición decida a dónde va la redirección.
Esa distinción importa porque las redirecciones están en todas partes y la mayoría de ellos están bien. Iniciar sesión y rebotar de vuelta a la página que querías, ceder el control a un proveedor de pagos, una devolución de llamada de OAuth - todos normales, todas redirecciones. El fallo, catalogado como CWE-601 y agrupado bajo el control de acceso roto en el OWASP Top 10, es específicamente el caso en el que el destino proviene de una entrada controlada por el usuario y nada lo valida antes. Un atacante suministra su propia URL, el sitio de confianza la reenvía, y la confianza se transfiere con el clic.
Paso mis días en la ruta de la redirección, así que este es un tema sobre el que tengo opiniones. Los enlaces cortos son redirecciones por definición, lo que hace que "¿es un acortador solo una redirección abierta?" sea una pregunta justa - y la respuesta, hecha bien, es un no rotundo. Llegamos a eso más abajo. Si la mecánica de las redirecciones es nueva para ti, tipos de redirecciones es la introducción, y cómo funcionan los acortadores de URL cubre los fundamentos del nivel de redirección.
Qué es realmente una redirección abierta
Redúcelo al mecanismo. Una página acepta un parámetro que nombra a dónde ir a continuación, y lo usa en una redirección HTTP sin confirmar que apunte a algún lugar permitido.
https://trusted.example/login?next=https://evil.example/fake-login
La víctima ve trusted.example al principio y hace clic. Tras el inicio de sesión, la aplicación lee next y emite una redirección a evil.example. El navegador obedece, porque una redirección no es más que una cabecera Location y un estado 3xx - la especificación HTTP define ese comportamiento con claridad y el navegador no tiene forma de saber que este destino en particular es hostil. El usuario, que ve cambiar la barra de direcciones después de haber confiado ya en el enlace, a menudo no se da cuenta.
OWASP describe el peligro central sin rodeos: el nombre del servidor en el enlace modificado es idéntico al del sitio original, lo que presta credibilidad a una redirección maliciosa. La vulnerabilidad no es que el sitio redirija. Es que alguien de fuera eligió el destino.
Por qué una redirección "inofensiva" es una amenaza real
El reflejo es encogerse de hombros: así que envía a alguien a otro sitio web, ¿qué daño hay? El daño es la confianza prestada, y se escala.
El phishing es el uso estrella. Un enlace que empieza con un banco, un inicio de sesión de SaaS o un portal gubernamental se desliza más allá del rápido control visual que hace la mayoría de la gente, y más allá de un número sorprendente de filtros automatizados que solo inspeccionan el dominio inicial. La víctima llega a una falsificación perfecta píxel a píxel de la página de inicio de sesión que esperaba, en un dominio que se veía correcto un salto atrás, y teclea su contraseña. Sin malware, sin carga exótica - solo una redirección y un clon.
Empeora cuando las redirecciones se sitúan cerca de la autenticación. Una redirección abierta en un flujo de OAuth puede filtrar un código de autorización o un token a un redirect_uri controlado por el atacante, lo que escala un fallo "menor" hasta una toma de control completa de la cuenta. Por eso las redirecciones abiertas son un clásico de los informes de bug-bounty en lugar de una nota al pie. El mismo truco también lava reputación: a los spammers y operadores de malware les encanta rebotar a través de un dominio de confianza porque eso hace pasar su enlace real más allá de las listas de bloqueo. Cubrimos la categoría más amplia en la lista de verificación de seguridad del acortador de URL, y el ángulo de la confianza desde el lado del visitante en ¿son seguros los acortadores de URL?.
Cómo prevenir las redirecciones abiertas
Hay una jerarquía de correcciones, y en lo más alto está la que realmente acaba con el problema. La hoja de referencia de OWASP las clasifica, y vale la pena seguir el orden.
- No tomes una URL de la petición en absoluto. Haz que el cliente envíe un nombre corto, un ID o un token, y resuélvelo al destino completo del lado del servidor. OWASP llama a esto el grado más alto de protección, porque la petición entrante ya no puede nombrar un destino arbitrario. Si ese patrón te suena familiar, debería: así es como funciona un acortador de URL.
- Lista de permitidos, no lista de bloqueados. Cuando debas aceptar un destino, compáralo con una lista de hosts de confianza o una expresión regular estricta. La lista de permitidos falla en cerrado - cualquier cosa no permitida explícitamente se rechaza. La lista de bloqueados falla en abierto, y a los atacantes les pagan por encontrar las entradas que olvidaste.
- Parsea de forma estricta. Rechaza las URLs relativas al protocolo (
//evil.example), normaliza las barras invertidas, decodifica antes de validar, y trata el host - no solo el prefijo de la cadena - como lo que hay que comprobar. La mayoría de los sorteos de filtros viven en un parseo perezoso. - Muestra un intersticial como respaldo. Si una redirección a un sitio externo es inevitable, enrútalo a través de una página que nombre el destino y pida al usuario que confirme. Es fricción, pero convierte una redirección silenciosa en una informada.
El tema recurrente es que las redirecciones seguras las decide el servidor, a partir de datos en los que el servidor ya confía - nunca lo que sea la cadena que llegó en la consulta.
Si estás construyendo redirecciones en un producto y preferirías no asumir este modo de fallo, la plataforma de desarrolladores de Elido mapea códigos a destinos del lado del servidor por diseño - empieza con la guía rápida de la API y nunca vuelvas a improvisar a mano un parámetro ?url=.
Por qué los enlaces cortos son la defensa, no el fallo
Aquí está la parte que sorprende a la gente. Un acortador de URL bien construido es la implementación de manual de la corrección número uno de OWASP contra la redirección abierta.
Cuando se crea un enlace corto, su destino se valida y se almacena del lado del servidor, atado a un código corto. Cuando alguien lo visita, el nivel de redirección busca ese código y reenvía al destino almacenado. El destino nunca proviene de la petición entrante - el visitante no puede añadir un ?url= y torcer el enlace hacia otro lugar, porque no existe tal parámetro que torcer. Eso es exactamente el mapeo de token a URL que OWASP recomienda, ejecutándose en producción millones de veces al día. Arquitectónicamente esto vive en nuestro nivel de redirección en el edge, y el presupuesto de latencia que eso paga es el tema de alcanzar un p95 por debajo de 15 ms en las redirecciones.
La advertencia honesta: un acortador todavía puede ser objeto de abuso, solo que no a través de una redirección abierta. Si una plataforma deja que cualquiera acuñe enlaces a cualquier cosa sin escaneo ni moderación, los atacantes usarán su reputación de dominio para encubrir sus propios destinos maliciosos - por eso los acortadores responsables escanean los destinos y aplican políticas contra el abuso. Ese es un problema de moderación de contenido, distinto del fallo de validación de entrada del que trata este artículo, y conviene no confundirlos. La práctica relacionada de ocultar deliberadamente un destino se cubre en link cloaking y enmascaramiento de URL explicados, y el primo de ingeniería social de todo esto - los códigos QR hostiles - en ¿son seguros los códigos QR?.
La conclusión en una línea
Si tu código lee un destino desde la petición y redirige a él, tienes una redirección abierta esperando a ser encontrado. En su lugar, mapea un ID a un destino del lado del servidor, usa una lista de permitidos para cualquier cosa que no puedas evitar tomar de la entrada, y parsea como si esperaras ser atacado. Las redirecciones no son el riesgo. Dejar que la petición elija a dónde van sí lo es. La diferencia entre un 301 y un 302 en redirecciones 301 vs 302 es una nota al pie al lado de esa única regla.
Relacionado en el blog
Preguntas frecuentes
¿Qué es una vulnerabilidad de open redirect?
Una redirección abierta es un fallo en el que una aplicación web envía a los usuarios a una URL de destino tomada de una entrada sin validar, normalmente un parámetro de consulta como ?next= o ?url=. Como el enlace empieza en un dominio de confianza, el navegador de la víctima y cualquier filtro de escaneo de enlaces lo tratan como seguro, pero la aplicación luego los reenvía a cualquier sitio que nombre el parámetro - incluido el de un atacante. Se clasifica como CWE-601 y se ubica dentro del control de acceso roto en el OWASP Top 10. El fallo es la comprobación que falta, no la redirección en sí.
¿Por qué son peligrosos los open redirects si solo te envían a otro sitio?
Porque el peligro es la confianza que presta el dominio de partida. Un enlace de phishing que dice https://trusted-bank.example/login?next=evil.example pasa la prueba a simple vista, sobrevive a muchos filtros de correo y deposita a la víctima en una página de inicio de sesión falsa convincente - todo mientras parece venir del banco real. Las redirecciones abiertas también encadenan ataques mayores: pueden filtrar códigos de autorización o tokens de OAuth cuando el destino de la redirección está controlado por el atacante, convirtiendo un fallo de baja severidad en una toma de control de la cuenta. La redirección es el mecanismo de entrega, no el exploit completo.
¿Son los acortadores de URL una vulnerabilidad de open redirect?
No, no cuando están bien construidos - y la distinción es el punto clave. Una redirección abierta toma un destino arbitrario de la entrada del usuario en el momento de la petición y lo reenvía sin validación. Un enlace corto mapea un código fijo a un destino que se fijó y se almacenó del lado del servidor cuando se creó el enlace; el destino de la redirección nunca proviene de la petición entrante. Ese mapeo del lado del servidor es exactamente la defensa que OWASP recomienda contra las redirecciones abiertas. Un acortador solo se vuelve un problema si permite que usuarios no auditados creen enlaces a cualquier cosa y les presta una reputación de dominio de la que pueden abusar - lo cual es un problema de abuso y moderación, no un fallo de redirección abierta.
¿Cómo se previenen las vulnerabilidades de open redirect?
La corrección más fuerte es nunca aceptar una URL de destino de la petición. Haz que el cliente envíe un nombre corto, un ID o un token, y mapéalo al destino completo del lado del servidor - el mismo modelo que usa un acortador de URL. Cuando realmente debas aceptar una URL, valídala contra una lista de permitidos de hosts de confianza en lugar de una lista de bloqueados de hosts malos, rechaza cualquier cosa que no sea una ruta relativa o un dominio aprobado, y sé estricto al parsear para que trucos como //evil.example o las barras invertidas no se cuelen. Como último recurso, enruta la redirección a través de una página intersticial que muestre el destino antes de enviar al usuario.
¿Cómo explotan los atacantes un open redirect?
Encuentran un endpoint que refleja un parámetro de URL en una redirección, luego elaboran un enlace en el dominio de confianza con su propio sitio en ese parámetro y lo distribuyen por correo, anuncio o mensaje. Las variaciones incluyen codificar la carga en URL para sortear filtros débiles, usar URLs relativas al protocolo como //attacker.example, explotar solo la porción del host mientras mantienen una ruta de aspecto legítimo, y abusar del manejo del redirect_uri de OAuth para capturar tokens. El hilo común es que la víctima ve y confía en el primer dominio y nunca ve el segundo hasta que es demasiado tarde.
¿Es un open redirect una vulnerabilidad de severidad alta o baja?
Por sí solo una redirección abierta a menudo se califica de baja a media, porque no compromete directamente el servidor - envía a los usuarios a otro lugar. Pero la severidad depende de con qué se encadena. Cerca de un flujo de autenticación puede filtrar tokens de OAuth y llevar a una toma de control de la cuenta, lo cual es de severidad alta; como ayuda al phishing puede causar una pérdida real de credenciales que una puntuación CVSS no captura. Trátalo por su impacto en contexto, no por la etiqueta base, y corrígelo de todos modos: la solución es barata y el potencial de abuso no lo es.
Prueba Elido
Pega una URL, obtén un enlace corto
Sin registro. El enlace vive 30 días. Crea una cuenta para conservarlo.
Se necesita una cuenta gratuita. El plan gratuito incluye 25 enlaces en total. ¿Ya tienes una cuenta? Iniciar sesión