Nuevos labs cada semana — Accede a todos desde 7,99€/mes

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

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.

Empieza con labs de OAuth

Practica OAuth 2.0 / SSO Attacks con labs basados en reportes reales. En español. Desde 7,99€/mes.

Empieza con el primer lab de OAuth