Respuesta rápida
POE (Quora) tenía un validador de redirect_url que comprobaba que empezara por /, no empezara por //, y no contuviera :. Bypass: /\evil.com. El backslash pasa los tres checks porque "no es un slash". Pero los navegadores normalizan \ → / según WHATWG URL spec → resuelve a //evil.com → https://evil.com. Combinado con la cookie p-b ya emitida + un canvas shouldAutoOpen whitelist que confiaba en poe.com como hostname → cadena zero-click. $1,100 H1 #3652197.
1. La validación vulnerable
// redirectUrlUtils.ts (POE — anonimizado)
function isValidRedirect(redirectUrl: string): boolean {
return (
redirectUrl.startsWith("/") && // 1: debe ser path relativo
!redirectUrl.startsWith("//") && // 2: bloquea protocol-relative
!redirectUrl.includes(":") // 3: bloquea javascript:, https:, etc
);
}
A primera vista parece OK. El payload /\evil.com lo rompe:
| Check | Input /\evil.com | Resultado |
|---|---|---|
startsWith("/") | Sí, empieza por / | ✅ pasa |
!startsWith("//") | Es /\, no // | ✅ pasa |
!includes(":") | No hay : | ✅ pasa |
| Validador | ACEPTA | ❌ |
Pero el browser, al ver /\evil.com, lo normaliza según WHATWG URL spec:
/\evil.com → //evil.com → https://evil.com
Esa normalización ocurre cuando el navegador resuelve la URL final del Location: header o de un window.location = "...". El validador comprueba antes de la normalización; el browser ejecuta después.
2. La URL de ataque
https://poe.com/login?redirect_url=/%5Cevil.com
%5Ces URL-encoding de\(backslash).- Server decodea →
redirect_url = /\evil.com. - Validador acepta → embebe en
googleOauthState.next_url. - Post-OAuth callback →
Location: /\evil.com. - Browser resuelve →
https://evil.com.
3. Flujo de ataque end-to-end
[Atacante] envía link: poe.com/login?redirect_url=/%5Cevil.com
↓
[Víctima] click → poe.com/login (página real)
↓
[POE] valida redirect_url (pasa) → embebe en googleOauthState
↓
[Víctima] click "Continue with Google" → autenticación
↓
[Google] callback con código válido a poe.com
↓
[POE] lee next_url del estado → emite Location: /\evil.com
↓
[Browser] normaliza /\ → // → resuelve a https://evil.com
↓
[Víctima] llega a evil.com con cookie p-b ya emitida en poe.com
Si la víctima ya estaba logueada, el paso OAuth se salta y el redirect ocurre directo.
Sigue leyendo el chain completo
La parte que falta incluye el PoC paso a paso, código de explotación y la cadena completa que llevó al impacto. Disponible para suscriptores.
La checklist que repaso en cada objetivo nuevo
47 comprobaciones ordenadas por coste: primero lo que te puede meter en un lío, luego lo barato, y al final lo caro — que es donde están los bounties grandes. Te la mando al correo ahora mismo.
Te das de baja en un clic, desde cualquier correo.
Practica esto en un lab
Open Redirect Backslash Bypass
Sigue aprendiendo · cuenta gratis
Guarda tu progreso, desbloquea payloads avanzados y rankea tus flags.
Artículos relacionados
Open Redirect vía Backslash Bypass en redirect_url del Login OAuth
El validador del cliente comprueba //, : y /. El backslash pasa. Los navegadores lo normalizan a slash y la víctima acaba en evil.tld con la cookie de sesión activa.
OAuth attacks — state CSRF, redirect_uri bypass, token reuse, IDOR de tokens
Vulnerabilidades en flujos OAuth 2.0: ausencia de state parameter, redirect_uri loose validation, token reuse cross-app, IDOR en endpoints de token refresh.
OAuth attacks — state CSRF, redirect_uri bypass, code/token leakage
El state parameter ausente, redirect_uri mal validado, response_type confusion. Cómo robar OAuth tokens y forzar account linking.
