Vulnerabilidad OAuth authentication

www.onlinetis.com
 

La vulnerabilidad de la autenticación OAuth se refiere a fallos de seguridad en la implementación del protocolo de autorización Open Authorization (OAuth). OAuth permite que una aplicación (cliente) acceda a los recursos de otra aplicación (servidor de recursos) en nombre del usuario, sin que este comparta sus credenciales. Un atacante puede explotar estos fallos para obtener acceso no autorizado a la cuenta de un usuario en un servicio de terceros.


¿Cómo funciona OAuth?

En un flujo estándar de OAuth, el usuario otorga a la aplicación cliente un permiso para acceder a sus datos en otro servicio. El proceso general incluye:

  1. Redirección: La aplicación cliente redirige al usuario al proveedor de OAuth (por ejemplo, Google, Facebook).

  2. Autorización: El usuario se autentica en el proveedor y autoriza a la aplicación cliente a acceder a sus datos.

  3. Código de autorización: El proveedor redirige al usuario de vuelta a la aplicación cliente con un código de autorización.

  4. Token de acceso: La aplicación cliente usa este código para solicitar un token de acceso al proveedor. Este token es la clave que permite a la aplicación acceder a los recursos del usuario.


Vulnerabilidades comunes ⚠️

Las vulnerabilidades de OAuth no residen en el protocolo en sí, sino en la forma en que los desarrolladores lo implementan.

  1. Redirección insegura (Open Redirect): Si la aplicación cliente utiliza un parámetro de URL para especificar la página de redirección (redirect_uri) y no lo valida, un atacante puede manipular este parámetro para redirigir al usuario, junto con el código de autorización, a un sitio malicioso.

  2. Falta de validación de estado (state parameter): El parámetro state es un token de un solo uso generado por la aplicación cliente que se envía en la solicitud de autorización. Cuando el usuario es redirigido de vuelta, el cliente debe verificar que el state devuelto coincida con el que se envió. Si no se valida, un atacante puede realizar un ataque de Cross-Site Request Forgery (CSRF) para secuestrar el flujo de autenticación e iniciar sesión con la cuenta de un atacante en la sesión del usuario víctima.

  3. Fuga de token de acceso: Si el token de acceso se almacena de forma insegura en el navegador del usuario o se transmite a través de un canal no cifrado (HTTP en lugar de HTTPS), un atacante podría interceptarlo y utilizarlo para acceder a los datos del usuario.

  4. Ataque de client_id: En implementaciones vulnerables, el client_id no se valida adecuadamente en la respuesta del token. Un atacante podría usar un client_id registrado por él mismo para engañar al proveedor de OAuth y que le entregue un código de autorización que pertenece a otra aplicación.


Prevención ✅

  • Validación estricta de la URL de redirección: La aplicación cliente debe utilizar una URL de redirección registrada y validarla de manera estricta. Nunca se debe permitir que el usuario envíe una URL de redirección arbitraria.

  • Utilizar y validar el parámetro state: Generar un token único para cada solicitud de autorización, enviarlo en el parámetro state y verificar que el token devuelto en la redirección sea el mismo.

  • Usar HTTPS: Toda la comunicación entre la aplicación cliente, el usuario y el proveedor de OAuth debe realizarse exclusivamente a través de HTTPS para proteger los códigos y tokens de acceso de la interceptación.

  • Implementar el control de acceso en el servidor: La lógica de validación de los tokens y los permisos de acceso debe estar en el servidor, no en el cliente.

  • Usar OAuth 2.0 con PKCE (Proof Key for Code Exchange): El estándar PKCE es un mecanismo que previene la interceptación del código de autorización, lo que hace que el flujo sea más seguro, especialmente para aplicaciones móviles y de una sola página (SPA).

Entradas populares de este blog

Ciberseguridad y hacking con Whatweb

Como robar contraseñas haciendo un phishing web

Arsenal software hacking NFC