Lathack

Open Redirect

Open Redirect

En este post estaremos indagando sobre el origen, generación e impacto que puede tener la vulnerabilidad de open redirect en aplicaciones web.

¿Qué es un Open Redirect?

Los open redirect son un tipo de vulnerabilidad que se produce cuando una aplicación web acepta una entrada controlada por el usuario para redirigirlo a una URL especificada, pero no valida o sanitiza correctamente dicha entrada. Esto puede conducir a ataques de phishing y otras actividades maliciosas.

De esta forma, los atacantes pueden aprovecharse de ello creando URLs que redirijan a los usuarios a sitios web maliciosos, facilitando así su engaño.

Ejemplos

A continuación exploraremos algunos ejemplos reales para comprender cómo funcionan los open redirect y los riesgos potenciales que plantean.

1. En página de login

Imaginemos un sitio web con un formulario de inicio de sesión que incluye un parámetro «return» en la URL para redirigir a los usuarios a una página específica después de iniciar sesión:

http://example.com/login?return=http://example.com/dashboard

Un atacante puede aprovecharse de esto cambiando el parámetro «return» a un sitio malicioso:

http://example.com/login?return=http://malicious.com

Si la aplicación no valida el parámetro «return», redirigirá a los usuarios al sitio malicioso después de iniciar sesión.

2. En correo de marketing

Consideremos un correo electrónico de marketing que incluye un enlace a una oferta de promoción con un parámetro de redirección:

http://example.com/offer?redirect=http://example.com/thankyou

Un atacante podría modificar el parámetro de redirect para que apunte a un sitio de phishing:

http://example.com/offer?redirect=http://phishing.com

Cuando los usuarios hacen clic en el enlace, son redirigidos al sitio de phishing, que puede parecerse al sitio legítimo y pedirles que introduzcan información confidencial.

3. En URL acortada

Existen muchos acortadores de URL que las toman como entrada y redirigen a los usuarios al destino. En este caso, puede producirse una vulnerabilidad de open redirect si el servicio no valida correctamente la URL de entrada:

http://shortener.com/?url=http://example.com

Un atacante podría crear una URL acortada que redirija a un sitio malicioso:

http://example.com/?url=http://evil.com

Los usuarios que hicieran clic en la URL acortada serían redirigidos al sitio malicioso

¿Cómo encontrar un Open redirect?

Para ello se pueden encontrar formas habituales de redirección como:

  • Parámetros más comunes: redirect, url, next, return, dest, goto, out, continue, target, callback, returnTo.

  • Patrones sospechosos en URLs:

    • /login?redirect=

    • /auth?next=

    • /page?url=

  • Valores controlables: Probando si se permite usar URLs externas (por ejemplo, http://evil-site.com).

Técnicas comunes de detección

  1. Fuzzing manual: Insertar URLs externas en parámetros sospechosos y verificar si la redirección se ejecuta. Por ejemplo:

  • URL original: https://example.com/login?redirect=/dashboard

  • URL maliciosa: https://example.com/login?redirect=https://malicious-site.com

  1. Automatización con herramientas:

    • Burp Suite: Usando funciones como Repeater para análizar el envío de datos o Intruder para automatizar ataques.

    • Scripts personalizados: Automatizando pruebas con listas de palabras clave comunes.

  1. Encadenamiento con codificación: Usar técnicas de ofuscación para evadir validaciones básicas, como:

    • Redirecciones codificadas (%2F%2Fmalicious-site.com).

    • Uso de subdominios falsos (https://example.com.malicious-site.com).

  1. Análisis manual del código fuente: Buscar los parámetros que controlan las redirecciones y verifique si están correctamente validados. Por ejemplo:

<form action=»redirect.php» method=»POST»>

<input type=»hidden» name=»url» value=»https://example.com»>

</form>

Uso de Google Dorks

Google Dorks son consultas de búsqueda especiales que utilizan operadores avanzados para refinar los resultados de búsqueda. Estos operadores permiten buscar tipos de archivos específicos, palabras clave en ubicaciones concretas de una página web e incluso vulnerabilidades conocidas.

A continuación exploraremos cómo utilizar Google Dorks para descubrir parámetros de redirección vulnerables en sitios web.

Para encontrar parámetros de redirección:

  • inurl: Busca una palabra clave específica dentro de la URL especificada.web

  • site: Limita la búsqueda a un sitio web concreto.

    Combinando estos operadores podemos crear los siguientes dorks:

  • inurl:redirect site:*.com

  • inurl:url site:*.edu

  • inurl:return site:*.gov

  • inurl:next site:*.org

Estos dorks buscarán parámetros como «redirect», «url», «return» y “next” en sitios web gubernamentales (.gov), educativos (.edu), comerciales (.com) y de organizaciones (.org).

¿Cómo elevar el impacto de esta vulnerabilidad?

Para aumentar la criticidad del hallazgo, es necesario demostrar cómo la vulnerabilidad puede ser explotada en combinación con otros problemas o contextos específicos. A continuación, se explican una serie de ejemplos para

1. Combinar con ataques de phishing

Una práctica frecuente es explorar la posibilidad de utilizar la URL vulnerable en correos de phishing, haciendo que parezca legítima. Por ejemplo:

https://banco-example.com/redirect?url=https://evil-site.com

De esta manera, se muestra cómo los usuarios pueden ser engañados para ingresar credenciales en un sitio falso.

2. Explotación en aplicaciones móviles

Las aplicaciones móviles suelen seguir automáticamente las redirecciones, lo que puede facilitar ataques como redirigir a sitios con descarga automática de APK maliciosos. Por ejemplo:

https://tienda.com/app_redirect?next=https://malware.com/download.apk

También se puede explorar si el endpoint es utilizado internamente en apps o APIs móviles. Es decir, si las APIs de una app usan el mismo endpoint, un atacante puede redirigir las solicitudes de la app a servidores maliciosos.

3. Omisión de controles de seguridad (Bypass)

Podemos usar el open redirect para evadir listas blancas en flujos de autenticación o validaciones de redirección. Por ejemplo, en OAuth o Single Sign-On (SSO), se podría redirigir a un dominio controlado por el atacante para robar tokens de sesión de la siguiente manera:

https://banco.com/oauth?redirect_uri=https://evil.com/callback

Esto eleva el impacto a crítico, ya que afecta la autenticación.

4. Explorar subdominios sensibles

Los subdominios suelen tener menos controles de seguridad y pueden contener información crítica. Por tanto, podemos probar si el endpoint vulnerable está alojado en dominios relevantes como:

https://admin.banco.com/redirect?url=https://ofertas.com

De esta forma si el subdominio es de soporte técnico, o un dashboard administrativo, se puede redirigir a usuarios hacia sitios maliciosos simulando ser un recurso legítimo, elevando el impacto de dicha vulnerabilidad.

5. Conectar a ataques client-side (XSS)

Al incluir un vector de XSS en la URL redirigida, se puede inyectar código en el navegador del usuario final. Por ejemplo: 

https://example.com/redirect?url=javascript:alert(‘XSS’)

De esta forma, si un navegador o cliente sigue automáticamente una redirección con esquemas peligrosos (javascript:), se podría ejecutar código malicioso. Esto generaría una elevación en el impacto de un simple open redirect.

6. Evasión de seguridad en navegadores

Algunos navegadores implementan medidas para bloquear redirecciones externas, pero estas pueden ser evadidas. Por ejemplo, usando caracteres Unicode:

https://example.com/redirect?url=https//maliciouscom

Como así también codificación de caracteres:

https://example.com/redirect?url=%68%74%74%70%73%3A%2F%2Fmalicious.com

De esta forma se busca evadir sistemas de protección, como listas negras en navegadores corporativos. Y, a su vez, demostrar cómo estas evasiones pueden llevar a accesos no autorizados. Como conclusión podemos destacar que la vulnerabilidad de Open Redirect puede parecer de bajo impacto inicialmente, pero al combinarla con otras técnicas o contextos, se convierte en una amenaza significativa.

¿Cómo mitigar un open redirect?

A continuación se describen de forma resumida las técnicas más comunes para mitigar o sanitizar esta vulnerabilidad.

1. Validación estricta de URLs de redirección

Usar una lista blanca:

  • Permitir redirecciones solo hacia URLs o dominios predefinidos y confiables.

  • Ejemplo: Si redirect_url apunta únicamente a example.com, cualquier otra URL debe rechazarse.

Validar dominios y subdominios:

  • Verificar que la URL de destino coincida exactamente con un dominio aprobado.

  • Evitar coincidencias parciales (por ejemplo, example.com.evil.com).

2. Prohibir redirecciones externas

Eliminar parámetros dinámicos:

  • Evitar aceptar URLs externas en parámetros de redirección.

  • En lugar de esto, usar nombres de rutas internas como https://example.com/redirect?to=home donde home se traduce internamente a /home.

Bloquear esquemas inseguros:

  • Rechazar URLs con esquemas peligrosos como javascript:, data:, o URLs codificadas.

3. Uso de confirmación del usuario

Advertencia explícita:

  • Mostrar al usuario un mensaje, con el fin que haga click para continuar, antes de redirigir fuera del dominio, indicando la URL de destino:

Estás saliendo del sitio. Serás redirigido a: https://example.com

4. Codificar y sanitizar parámetros

Normalización de parámetros:

  • Decodificar y normalizar URLs antes de validarlas para evitar bypass mediante codificaciones como Unicode o %xx.

Escapado de salida:

  • Si la URL se muestra en el navegador antes de la redirección, asegurarse de escapar caracteres especiales para evitar inyecciones (como XSS).

5. Implementar controles a nivel del servidor

Redirecciones fijas:

  • No usar parámetros dinámicos para determinar la URL de destino. En su lugar, asociar las rutas a valores internos seguros.

Limitaciones en subdominios:

  • Controlar que las redirecciones no apunten a subdominios sensibles o inseguros, como: admin.example.com.

6. Monitorear y auditar

Escanear parámetros de redirección:

  • Usar herramientas automatizadas para buscar posibles vulnerabilidades en rutas con parámetros como redirect_url, next, url, dest, etc.

Registros de actividad:

  • Registrar intentos de redirección y analizar patrones sospechosos.

7. Aplicar encabezados de seguridad

Usar Content-Security-Policy (CSP):

  • Limitar los destinos permitidos para cargas o redirecciones.

Habilitar Referrer-Policy:

  • Reducir la exposición de información sobre la fuente de una redirección.

8. Ejemplo de validación vía Python

from urllib.parse import urlparse

def validate_redirect_url(url):

    # Lista blanca de dominios permitidos

    allowed_domains = [«example.com», «sub.example.com»]

    parsed_url = urlparse(url)

    

    # Verificar dominio

    if parsed_url.netloc not in allowed_domains:

        raise ValueError(«Redirección no permitida»)

    

    return url   # URL segura

De esta forma podemos comprender esta simple vulnerabilidad de Open Redirect que, aunque en muchos casos pueda ser de impacto bajo, existen muchos métodos o situaciones en las que se puede elevar dicho impacto y generar un daño crítico en una organización u empresa.

Recuerda que en lathack puedes seguir aprendiendo sobre vulnerabilidades web, reportes y demás información sobre Ciberseguridad.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

uno × 5 =

Lathack
Scroll al inicio