Quick answer
POE (Quora) had a redirect_url validator that checked it started with /, didn't start with //, and didn't contain :. Bypass: /\evil.com. The backslash passes all three checks because "it isn't a slash." But browsers normalize \ → / per the WHATWG URL spec → it resolves to //evil.com → https://evil.com. Combined with the already-issued p-b cookie + a canvas shouldAutoOpen whitelist that trusted poe.com as a hostname → zero-click chain. $1,100 H1 #3652197.
1. The vulnerable validation
// 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
);
}
At first glance it looks OK. The payload /\evil.com breaks it:
| Check | Input /\evil.com | Result |
|---|---|---|
startsWith("/") | Yes, starts with / | ✅ passes |
!startsWith("//") | It's /\, not // | ✅ passes |
!includes(":") | No : | ✅ passes |
| Validator | ACCEPTS | ❌ |
But the browser, upon seeing /\evil.com, normalizes it per the WHATWG URL spec:
/\evil.com → //evil.com → https://evil.com
That normalization happens when the browser resolves the final URL of the Location: header or of a window.location = "...". The validator checks before the normalization; the browser executes after.
2. The attack URL
https://poe.com/login?redirect_url=/%5Cevil.com
%5Cis the URL-encoding of\(backslash).- Server decodes →
redirect_url = /\evil.com. - Validator accepts → embeds it in
googleOauthState.next_url. - Post-OAuth callback →
Location: /\evil.com. - Browser resolves →
https://evil.com.
3. End-to-end attack flow
[Attacker] sends link: poe.com/login?redirect_url=/%5Cevil.com
↓
[Victim] click → poe.com/login (real page)
↓
[POE] validates redirect_url (passes) → embeds in googleOauthState
↓
[Victim] clicks "Continue with Google" → authentication
↓
[Google] callback with valid code to poe.com
↓
[POE] reads next_url from state → emits Location: /\evil.com
↓
[Browser] normalizes /\ → // → resolves to https://evil.com
↓
[Victim] lands on evil.com with the p-b cookie already issued on poe.com
If the victim was already logged in, the OAuth step is skipped and the redirect happens directly.
Keep reading the full chain
The remaining part includes the step-by-step PoC, exploitation code and the full chain that led to impact. Available to subscribers.
Practice this in a lab
Open Redirect Backslash Bypass
Keep learning · free account
Save your progress, unlock advanced payloads and rank your flags.
Related articles
Open Redirect via Backslash Bypass in the OAuth Login's redirect_url
The client-side validator checks //, : and /. The backslash slips through. Browsers normalize it to a slash and the victim ends up on evil.tld with an active session cookie.
OAuth attacks — state CSRF, redirect_uri bypass, token reuse, token IDOR
Vulnerabilities in OAuth 2.0 flows: missing state parameter, redirect_uri loose validation, cross-app token reuse, IDOR in token refresh endpoints.
OAuth attacks — state CSRF, redirect_uri bypass, code/token leakage
The missing state parameter, poorly validated redirect_uri, response_type confusion. How to steal OAuth tokens and force account linking.