Supongamos que tiene una aplicación que utiliza OAuth para que la aplicación pueda iniciar sesión en los servicios del usuario (por ejemplo, OneDrive, Google Drive, etc.)
Dentro de la aplicación, has incluido el secreto del cliente OAuth (y el ID del cliente) como constantes de cadena.
Un atacante extrae estos de su aplicación usando técnicas de ingeniería inversa. ¿Qué es lo peor que puede hacer el atacante ahora, sabiendo el secreto del cliente OAuth de su aplicación?
Distribuir un secreto de cliente compartido es como distribuir las claves completas del reino y una violación de CWE-602: Aplicación del lado del cliente de la seguridad del lado del servidor . Esto se debe a que cualquier persona que tenga la aplicación tendrá acceso completo a los recursos compartidos del servidor.
El impacto de un token de acceso OAuth robado depende totalmente del alcance , que se define en la base64 token de acceso codificado.
En el tipo de concesión de código de autorización, donde los secretos del cliente deben permanecer en secreto, el usuario puede informar al servicio que su aplicación está autorizada para acceder a ciertos elementos de su cuenta. Lo importante aquí es que han autorizado su aplicación, no cualquier otra aplicación. El secreto del cliente es cómo usted autentica su aplicación al servicio.
La adquisición de un secreto de cliente puede permitir que una aplicación maliciosa se haga pasar por su aplicación y cualquier autorización que se haya otorgado. Esto podría incluir la reproducción del acceso y la actualización de tokens para acceder a la cuenta de un usuario sin su permiso.
Creo que el atacante generalmente necesitaría adquirir información adicional (por ejemplo, tokens de acceso) para que el secreto del cliente sea útil en la práctica (me encantaría conocer cualquier escenario en el que este no sería el caso). Los ataques en los que un usuario existente es atraído a una página maliciosa (con acceso al secreto del cliente) pueden funcionar en algunos contextos, aunque puede haber complicaciones en la referencia y en la página a la que se devuelve el usuario.
La gravedad ("lo peor que podría hacer") variaría según el alcance, pero es probable que tenga un impacto negativo en los usuarios de la aplicación. En sus ejemplos de Google Drive y OneDrive, podría permitir que un atacante lea o modifique los archivos de un usuario, por ejemplo, si esa es la autorización que dieron.
Refs:
El tipo de concesión implícita es mejor para entornos donde un token no se puede mantener en secreto (escritorio nativo, móvil nativo, navegador del lado del cliente, etc.).
Lea otras preguntas en las etiquetas oauth secret-sharing