¿Qué es OAuth?

OAuth no es un protocolo de seguridad; es un framework de delegación. Las vulnerabilidades nacen cuando los desarrolladores confían ciegamente en los datos que viajan por el lado del cliente.

Actores principales:

  1. Client Application: El sitio web que quiere acceder a los datos del usuario.
  2. Resource Owner: El usuario dueño de los datos.
  3. OAuth Service Provider: El servicio que controla los datos (ej. Google, GitHub) y provee la API.

¿Cómo funciona OAuth 2.0?

OAuth 2.0 es una forma de compartir el acceso a datos específicos entre aplicaciones. Funciona definiendo una serie de interacciones entre tres partes distintas: Una aplicación cliente, Un propietario de recursos y el proveedor de servicios OAuth.

  • Aplicación cliente: El sitio web o aplicación web que desea acceder a los datos del usuario.
  • Propietario del recurso: El usuario a cuyos datos la aplicación cliente desea acceder.
  • Proveedor de servicios OAuth: El sitio web o aplicación que controla los datos del usuario y el acceso a los mismos.

Cómo surgen las vulnerabilidades

Las fallas suelen aparecer porque la especificación de OAuth es flexible y deja gran parte de la seguridad en manos de los desarrolladores. Los errores comunes incluyen:

  • Falta de validación de entrada.
  • Configuraciones opcionales ignoradas.
  • Envío de datos sensibles a través del navegador, facilitando la interceptación.

Lógica de Detección (Fingerprinting)

No hay que limitarse a lo obvio. El comportamiento del servidor ante errores dice más que su documentación.

Verbosidad de Errores: Si al enviar un redirect_uri inválido el servidor responde con el dominio esperado en el cuerpo del error, tienes un punto de entrada para inyección de contenido o reflejo de XSS.

Discovery Endpoint (/.well-known/openid-configuration):

  • Busque frontchannel_logout_supported. Si es true, se podría forzar el cierre de sesión de un usuario (DoS de sesión) o intentar ataques de fijación de sesión.
  • Analice request_parameter_supported. Si el servidor acepta objetos de petición (JAR), es una invitación directa a intentar KID/JKU Injection.

Payloads de Evasión: Rompiendo la Lógica de Validación

Las RegEx son el enemigo débil. Usa estos vectores para confundirlas:

Vectores Críticos (El camino al $ bounty)

A. Pre-Auth Account Takeover (Race Condition)

  • El Escenario: Registro híbrido (Email/Pass + OAuth).
  • El Ataque: Envíe dos peticiones simultáneas: una para crear la cuenta con email/pass y otra para vincularla vía OAuth. Si el backend no tiene bloqueos transaccionales (locks), podrías terminar con una cuenta "fantasma" donde tú tienes el control vía OAuth pero la víctima cree que es suya.

B. JKU (JWK Set URL) Injection en OIDC

Si el header del JWT permite jku, aloja tu propio archivo keys.json en un servidor controlado y apunta el token hacia allí.

  • Impacto: Firma de tokens arbitrarios, permitiéndote personificar a cualquier usuario (incluyendo admins).

C. Abuso de Dynamic Client Registration (DCR)

Si el registration_endpoint no requiere autenticación:

  1. Registre un cliente malicioso.
  2. Utilice sector_identifier_uri para forzar un SSRF hacia la red interna o servicios de metadatos de la nube (169.254.169.254).

Estrat egia de Encadenamiento (Vulnerability Chaining)

Un bug de OAuth rara vez muere solo. Conéctalo:

  1. OAuth + PostMessage: Si el token se pasa al opener vía postMessage, pero el targetOrigin es *, cualquier sitio malicioso puede robar el token simplemente abriendo el flujo en un iframe o popup.
  2. OAuth + Open Redirect: Usa el redirector legítimo para exfiltrar el code o el access_token hacia tu servidor aunque la redirect_uri esté estrictamente validada para el dominio principal.
  3. OAuth + XSS: Si se encuentra un XSS en cualquier subdominio del redirect_uri permitido, se puede usar fetch() para iniciar el flujo de OAuth y capturar el code sin que el usuario vea ninguna redirección.
  4. OAuth + CSRF: Si el parámetro state no se valida o es predecible, se puede hacer un Account Linking Attack, forzando a la víctima a conectar su cuenta de redes sociales a tu cuenta en la plataforma.

Bypass de Protecciones Modernas

  • SameSite Cookie Bypass: Para saltar SameSite=Lax, usa una navegación de nivel superior (window.location = ...). Como OAuth es un flujo de redirecciones GET, el navegador enviará las cookies de sesión aunque estén protegidas por Lax.
  • CORS & Referrer Policy: Si el sitio usa Referrer-Policy: unsafe-url, el code de OAuth se filtrará en el header Referer a cualquier recurso externo (como una imagen o script de tracking) cargado en la página de redirección.
  • PostMessage TargetOrigin Abuse:
// Si el sitio hace: window.opener.postMessage(data, '*')
// Exploit:
window.addEventListener("message", (e) => {
    console.log("Token robado: " + e.data.access_token);
});
window.open("https://victim.com/oauth/authorize?...");

Business Impact

Esta vulnerabilidad puede llegar a permitir el Account Takeover total sin interacción del usuario (en flujos pre-auth) o la Persistencia Silenciosa. El impacto trasciende el robo de sesión, ya que permite a un atacante mantener acceso a la cuenta incluso después de que la víctima cambie su contraseña, comprometiendo la integridad de la autenticación en toda la plataforma y exponiendo datos sensibles (PII) de forma masiva.

Conéctate conmigo

¿Te fue útil esta información? Puedes encontrar más contenido en:

Support Me ☕