Un open redirect 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 el redirect.
Esa distinción importa porque los redirects 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, todos redirects. 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 del redirect, así que este es un tema sobre el que tengo opiniones. Los enlaces cortos son redirects por definición, lo que hace que "¿es un acortador solo un open redirect?" sea una pregunta justa - y la respuesta, hecha bien, es un no rotundo. Llegamos a eso más abajo. Si la mecánica de los redirects es nueva para ti, tipos de redirects es la introducción, y cómo funcionan los acortadores de URL cubre los fundamentos del nivel de redirect.
Qué es realmente un open redirect#
Redúcelo al mecanismo. Una página acepta un parámetro que nombra a dónde ir a continuación, y lo usa en un redirect 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 un redirect a evil.example. El navegador obedece, porque un redirect 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 un redirect malicioso. La vulnerabilidad no es que el sitio redirija. Es que alguien de fuera eligió el destino.
Por qué un redirect "inofensivo" 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 un redirect y un clon.
Empeora cuando los redirects se sitúan cerca de la autenticación. Un open redirect 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 los open redirects 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 los open redirects#
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 un redirect 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 un redirect silencioso en uno informado.
El tema recurrente es que los redirects seguros los 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 redirects 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 el open redirect.
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 redirect 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 redirect en el edge, y el presupuesto de latencia que eso paga es el tema de alcanzar un p95 por debajo de 15 ms en los redirects.
La advertencia honesta: un acortador todavía puede ser objeto de abuso, solo que no a través de un open redirect. 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 un open redirect 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. Los redirects 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 redirects 301 vs 302 es una nota al pie al lado de esa única regla.
Relacionado en el blog#
Prueba Elido
Pega una URL, obtén un enlace corto
Sin registro. El enlace vive 30 días. Crea una cuenta para conservarlo.
Gratis, sin registro · 2 por día