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.
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.