Vulnerabilidades de OAuth y patrones de ataque

Los servidores de autorización OAuth deben validar estrictamente el parámetro redirect_uri. Si el servidor permite coincidencias por prefijo o comodines (por ejemplo, acepta cualquier URL que comience por "https://app.example.com"), un atacante puede crear una solicitud de autorización que redirija a "https://app.example.com.attacker.com/steal" o a una redirección abierta en el dominio legítimo, y robar el código de autorización.

Sin protección contra CSRF, un atacante puede iniciar un flujo OAuth y conseguir que el navegador de una víctima complete la autorización. La víctima autoriza inadvertidamente al cliente del atacante. El parámetro "state" (RFC 6749) evita esto: el cliente genera un state aleatorio, lo incluye en la solicitud y verifica que coincida en el callback. Si no coincide, se cancela el flujo.

En las plataformas móviles, las aplicaciones maliciosas pueden registrar el mismo esquema de URI personalizado que un cliente OAuth legítimo e interceptar los códigos de autorización redirigidos después de la autenticación del usuario. PKCE (RFC 7636) ofrece una defensa completa: el código interceptado no sirve de nada sin el verificador de código que solo la aplicación legítima generó al comienzo del flujo.

Cuando un token de ID o un token de acceso se incluye en un fragmento o parámetro de consulta de una URL, las navegaciones posteriores desde esa página incluyen la URL en la cabecera Referer, lo que puede filtrar el token a scripts de analítica de terceros o proveedores de CDN. Utilice siempre el flujo de código de autorización con entrega de tokens mediante el canal de retorno para evitar que los tokens aparezcan en las URL.

Cuando un cliente admite varios proveedores OAuth, los ataques de confusión hacen que el cliente envíe a la interfaz de tokens del proveedor B un código de autorización obtenido del proveedor A. El cliente debe validar el claim "iss" en los tokens de ID y vincular el callback al proveedor específico que inició el flujo mediante el parámetro state o JARM (JWT-Secured Authorization Response Mode).

Los ataques de falsificación de solicitudes del lado del servidor (SSRF) tienen como objetivo las implementaciones OAuth que realizan solicitudes HTTP desde el servidor a redirect_uri. Si el servidor de autorización obtiene redirect_uri para verificarlo, un atacante puede proporcionar una dirección IP interna (por ejemplo, http://169.254.169.254/latest/meta-data/) para acceder a los metadatos de una instancia en la nube o a servicios internos. Una validación estricta de redirect_uri basada en una lista de permitidos evita este ataque.

Muchas aplicaciones utilizan el claim de email de un token de ID de OIDC para vincular cuentas entre proveedores. Si un atacante controla una dirección de correo electrónico que coincide con la cuenta de una víctima en otro proveedor, puede registrarse con un proveedor diferente utilizando ese correo y obtener acceso a la cuenta de la víctima. Defensa: vincule las cuentas únicamente mediante el par (iss, sub), nunca solo mediante el correo electrónico.

Los ataques de confusión del algoritmo JWT explotan las implementaciones que confían en la cabecera "alg" para seleccionar el algoritmo de verificación. El ataque consiste en cambiar "alg" de "RS256" a "HS256" y firmar el token con la clave pública del servidor como secreto HMAC (ya que la clave pública es pública). Defensa: especifique siempre explícitamente el algoritmo esperado en el código de verificación; nunca confíe en el claim alg de la cabecera del token.

Los atacantes registran clientes OAuth maliciosos con nombres y logotipos de apariencia legítima y después envían enlaces de phishing a sus objetivos. La víctima ve una pantalla de consentimiento OAuth auténtica (alojada por Google, Microsoft, etc.) correspondiente a una aplicación maliciosa y concede acceso. Defensa: verifique que client_id corresponda a la aplicación esperada; Google y Microsoft ofrecen programas de verificación de clientes para aplicaciones legítimas.

La escalada de scopes ocurre cuando un cliente obtiene tokens con permisos más amplios que los que autorizó el usuario. Los fallos de implementación que omiten la validación de scopes en el punto de conexión de tokens, almacenan en caché tokens con scopes combinados de distintas solicitudes o no validan que el scope del token emitido no supere el scope autorizado pueden provocar una escalada de privilegios mediante OAuth.

Proteja las implementaciones OAuth mediante: validación de redirect_uri con coincidencia exacta, PKCE obligatorio para todos los clientes públicos, validación del parámetro state para protegerse contra CSRF, vinculación de tokens de ID mediante (iss, sub) y no mediante el correo electrónico, especificación explícita de los algoritmos JWT esperados, solicitud de scopes mínimos, uso de tokens de acceso de corta duración con rotación de tokens de actualización y auditoría del aspecto de la pantalla de consentimiento para detectar riesgos de suplantación de marca.

Un servidor de autorización OAuth acepta cualquier redirect_uri que comience por "https://app.example.com". ¿Qué ataque permite esto?

Ataques clave de OAuth: redirección abierta mediante una validación débil de redirect_uri (utilice una coincidencia exacta), CSRF por la ausencia del parámetro state, interceptación de códigos en dispositivos móviles (mitigada mediante PKCE), filtración de tokens en las URL, ataques de confusión en configuraciones con varios proveedores (valide iss), SSRF mediante redirect_uri obtenido por el servidor, colisión del claim de email (utilice iss+sub), confusión del algoritmo JWT (fije el alg esperado) y phishing mediante pantallas de consentimiento falsas.