Labs de OAuth
OAuth 2.0 / SSO Attacks
Deja de leer sobre bugs y empieza a cazarlos
Sin tarjeta · Academy gratis · cancela cuando quieras
¿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.
Otras categorías relacionadas
hunters entrenando
labs de hackeos reales
completaciones
pagados por estos bugs
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 OAuth en labs reales
Cada lab de OAuth replica un reporte real de bug bounty que se pagó. Crea tu cuenta gratis, empieza por la Academy y pasa a los labs cuando quieras.
Sin tarjeta · Academy gratis · cancela cuando quieras
La comunidad
Esto no es una plataforma con usuarios.Es gente rompiendo lo mismo que tú.
Dentro se pregunta, se enseña lo que se ha encontrado y se resuelve en grupo lo que atascaría a cualquiera solo. Se entra gratis: sin cuenta, sin plan y sin dejar el correo.
Es gratis y abierto. No hace falta tener cuenta en BBLABS para entrar.