Labs de OAuth

OAuth 2.0 / SSO Attacks

¿Qué es OAuth?

Los ataques a OAuth 2.0 y SSO explotan implementaciones incorrectas del flujo de autorización: validación laxa de redirect_uri, ausencia del parámetro state, fuga del authorization code y account linking inseguro. El resultado típico es account takeover de cualquier usuario.

¿Por qué practicar OAuth?

El 'login con Google/GitHub/Facebook' está en casi toda app moderna y su flujo es sutil y fácil de implementar mal. Un redirect_uri laxo o un state ausente convierten el SSO en account takeover de toda la base de usuarios. Bounties típicos: $2,000-$25,000 por un ATO vía OAuth.

¿Qué aprenderás con los labs de OAuth?

Aprenderás a diagramar el flujo authorization code, manipular redirect_uri para fugar el code, detectar la ausencia de state (CSRF de account linking), abusar de account linking por email no verificado, y robar tokens combinando OAuth con Open Redirect o XSS en el cliente.

Tipos de OAuth que cubrimos

redirect_uri manipulation
Validación laxa (prefijo, subpath, wildcard) permite desviar el authorization code a un dominio del atacante.
state ausente / CSRF
Sin state, el atacante fija su code en el callback de la víctima y enlaza la cuenta de la víctima a su cuenta social.
Code/token leak
El code se fuga por el header Referer, un Open Redirect o un postMessage inseguro hacia el dominio del atacante.
Account linking inseguro
Enlazar por email sin verificar permite reclamar la cuenta de otro usuario que usa el mismo email.

¿Cómo encontrar y explotar OAuth?

Playbook práctico — del recon a la prueba de concepto.

1
Diagramar el flujo
Captura toda la danza OAuth: /authorize, los parámetros (client_id, redirect_uri, state, scope) y el callback que canjea el code por el token.
```
GET /oauth/authorize?client_id=X&redirect_uri=https://app/cb&state=S&response_type=code
```
2
Atacar redirect_uri
Prueba variantes del redirect_uri (otro path, subdominio, sufijo, @, //) para ver si el provider acepta enviar el code a un destino que controlas.
```
redirect_uri=https://app.com.evil.com/cb   ·   redirect_uri=https://app/cb/../evil
```
3
Comprobar el parámetro state
Si falta o no se valida, puedes hacer CSRF en el callback: la víctima usa tu code y acaba enlazada/logueada en tu cuenta o tú en la suya.
```
Quitar &state= del flujo → ¿el callback sigue aceptando el code?
```
4
Fugar el code
Combina con un Open Redirect del cliente o el header Referer para que el authorization code salga hacia tu dominio.
```
redirect_uri apunta a un Open Redirect del propio app → 302 a evil.com?code=...
```
5
Abusar del account linking
Si la app enlaza identidades por email sin verificar, regístrate con el email de la víctima y vincula su cuenta social a la tuya.
```
Sign in with Google (email=victima@x.com no verificado) → toma de control
```

Aprende la teoría

Academy: OAuth & SSO

Cargando labs...

Ver en catálogo completo →

Preguntas frecuentes

¿Qué es un ataque a OAuth?

Es la explotación de fallos en el flujo de OAuth 2.0 / SSO ('login con Google/GitHub'): validación laxa de redirect_uri, ausencia del parámetro state, fuga del authorization code o account linking inseguro. Suelen acabar en account takeover de cualquier usuario.

¿Cómo se explota una implementación OAuth insegura?

Se manipula redirect_uri para desviar el authorization code a un dominio del atacante, se aprovecha la falta de state para hacer CSRF de account linking, o se fuga el code vía Referer/Open Redirect. Con el code o el token robado, se accede a la cuenta de la víctima.

¿Cómo encontrar fallos OAuth en bug bounty?

Captura el flujo completo y juega con redirect_uri (paths, subdominios, sufijos, @), comprueba si state existe y se valida, y busca si el code se fuga por Referer o por un Open Redirect del cliente. El account linking por email no verificado también es un clásico.

¿Cómo prevenir ataques a OAuth?

Exige coincidencia exacta del redirect_uri registrado (sin wildcards ni prefijos), usa y valida el parámetro state (o PKCE) en cada flujo, no expongas el code en URLs que puedan fugarse, y verifica el email antes de enlazar identidades en el account linking.

¿Diferencia entre un ataque OAuth y un Authentication Bypass de JWT?

El ataque OAuth abusa del flujo de autorización entre la app y el proveedor de identidad (redirect_uri, state, code). El ataque a JWT abusa de cómo la app firma/verifica sus propios tokens de sesión. Ambos pueden acabar en ATO, pero atacan fases distintas de la autenticación.