# Authentication bypass on Airbnb via OAuth tokens theft

Login CSRF plus Referer-based open redirect in Airbnb's OAuth callback let an attacker steal Facebook/Google OAuth code and access_token, authenticating as the victim on web and mobile.

- Payout: $5,000
- Severity: high
- Program: Airbnb
- Credited: Arne Swinnen
- Disclosed: 2017-06-22
- Write-up quality: 9/10
- Original: https://www.arneswinnen.net/2017/06/authentication-bypass-on-airbnb-via-oauth-tokens-theft/
- Library page: https://bugbountylibrary.com/r/blog%3Aarneswinnen-net-2017-06-authentication-bypass-on-airbnb-via-oauth-tokens-theft
- Tags: domain:web impact:ato kind:bounty platform:blog sev:high tech:oauth technique:chained technique:source-review vuln:account-takeover vuln:auth-bypass vuln:csrf vuln:open-redirect

**Target:** OAuth login flow (/oauth_connect, /oauth_callback) on localized airbnb domains
**Root cause:** The /oauth_callback endpoint redirected logged-in users based solely on the attacker-controllable HTTP Referer header from the initiating /oauth_connect call, and /oauth_connect was forgeable via GET (login CSRF), letting an attacker plant an arbitrary redirect target.
**Steps:**
1. Victim logged into Facebook/Google with Airbnb linked, not necessarily logged into Airbnb.
2. Attacker page loads `https://www.airbnb.cat/oauth_connect?from=google_login&service=google` in an <object>, silently logging victim into Airbnb and planting Referer = attacker site.
3. Attacker then navigates victim to `https://accounts.google.com/o/oauth2/auth?response_type=code,token&...&redirect_uri=https%3A%2F%2Fwww.airbnb.cat%2Foauth_callback` (same redirect_uri, only response_type changed to code,token).
4. IDP returns code in GET param and access_token in URL fragment to /oauth_callback; since victim is logged in, callback redirects to planted Referer (attacker site).
5. Attacker JS reads `window.location.hash` to steal code and access_token.
**How found:** Observed that /oauth_callback redirected logged-in users based on the HTTP Referer header from /oauth_connect, which is attacker-controllable by design. Noted redirect_uri tampering was blocked by IDPs, so pivoted to fragment-based token delivery and used login CSRF to satisfy the logged-in precondition and plant the redirect seed.
**Exploitation:** Attacker hosts a page with two chained <object> loads: first the Airbnb /oauth_connect to force a silent login (login CSRF) and set Referer to attacker origin, then a direct IDP authorize call with response_type=code,token keeping the same redirect_uri. The IDP response lands on /oauth_callback, which redirects to the attacker Referer carrying the fragment; JS reads the hash to exfiltrate code and access_token.
**Escalation:** Stolen code authenticates to airbnb.com as victim; stolen access_token authenticates as victim on Airbnb mobile app (which uses long-term IDP access_token), and grants IDP data access.
**Insight:** When redirect_uri is locked down, look at how the SP decides where to send the user after callback: a Referer-based redirect-back is an open redirect. Combine with login CSRF (state param doesn't help when logging victim into their own account) to satisfy the logged-in precondition, and switch response_type to code,token so tokens arrive in the fragment that survives cross-origin redirects.