security oauth google-api oauth-2.0

security - secreto del cliente en OAuth 2.0



google-api oauth-2.0 (3)

Para usar la API de Google Drive, tengo que jugar con la autenticación usando OAuth2.0. Y tengo algunas preguntas sobre esto.

  1. La identificación del cliente y el secreto del cliente se utilizan para identificar cuál es mi aplicación. Pero deben estar codificados si es una aplicación cliente. Entonces, todos pueden descompilar mi aplicación y extraerla del código fuente. ¿Significa que una aplicación incorrecta puede pretender ser una buena aplicación mediante el uso de la identificación del cliente de la aplicación y el secreto? Entonces, ¿el usuario estaría mostrando una pantalla pidiendo permiso a una buena aplicación, aunque realmente la pida una mala? Si es así, ¿qué debería hacer? ¿O realmente no debería preocuparme por esto?

  2. En la aplicación móvil, podemos incorporar una vista web a nuestra aplicación. Y es fácil extraer el campo de contraseña en la vista web porque la aplicación que solicita permiso es en realidad un "navegador". Entonces, ¿OAuth en la aplicación móvil no tiene el beneficio de que la aplicación cliente no tiene acceso a la credencial del usuario del proveedor del servicio?

Empecé a escribir un comentario sobre su pregunta, pero luego descubrí que hay mucho que decir, así que aquí están mis puntos de vista sobre el tema en la respuesta.

  1. Sí, hay una posibilidad real para esto y hubo algunos exploits basados ​​en esto. La sugerencia es no mantener la aplicación en secreto en su aplicación, incluso hay parte de la especificación de que las aplicaciones distribuidas no deben usar esta ficha. Ahora puede preguntar, pero XYZ lo requiere para poder trabajar. En ese caso, no están implementando la especificación correctamente y usted no debería usar ese servicio (no es probable) o B intentar proteger el token utilizando algunos métodos de ofuscación para dificultar la búsqueda o el uso de su servidor como proxy.

    Por ejemplo, había algunos errores en la biblioteca de Facebook para Android en los que se filtraban tokens a los registros, puedes encontrar más información al respecto aquí http://attack-secure.com/all-your-facebook-access-tokens-are-belong-to-us y aquí https://www.youtube.com/watch?v=twyL7Uxe6sk . En general, tenga mucho cuidado con el uso que haga de las bibliotecas de terceros (de hecho, tiene sentido común, pero si el secuestro de un token es su gran preocupación, agregue otro extra a la cautela).

  2. He estado despotricando sobre el punto 2 por bastante tiempo. Incluso he hecho algunas soluciones en mis aplicaciones para modificar las páginas de consentimiento (por ejemplo, cambiar el zoom y el diseño para adaptarse a la aplicación), pero no había nada que me impidiera leer valores de campos dentro de la vista web con nombre de usuario y contraseña. Por lo tanto, estoy totalmente de acuerdo con tu segundo punto y considero que es un gran "error" en las especificaciones de OAuth. Apuntar a que "la aplicación no tiene acceso a las credenciales de los usuarios" en la especificación es solo un sueño y le da a los usuarios una falsa sensación de seguridad ... También creo que las personas suelen sospechar cuando la aplicación les pide su Facebook, Twitter, Dropbox u otras credenciales. Dudo que muchas personas comunes y corrientes lean las especificaciones de OAuth y digan "Ahora estoy seguro", sino que usen el sentido común y generalmente no usen aplicaciones en las que no confíen.

Tuve la misma pregunta que la pregunta 1 aquí, e investigué un poco recientemente, y mi conclusión es que está bien no mantener el "secreto del cliente" en secreto. El tipo de clientes que no mantienen la confidencialidad del secreto del cliente se denomina "cliente público" en la especificación OAuth2. La posibilidad de que alguien malintencionado pueda obtener el código de autorización y luego acceder al token se evita con los siguientes hechos.

1. El cliente necesita obtener el código de autorización directamente del usuario, no del servicio

Incluso si el usuario indica el servicio en el que confía en el cliente, el cliente no puede obtener el código de autorización del servicio simplemente mostrando la identificación del cliente y el secreto del cliente. En cambio, el cliente debe obtener el código de autorización directamente del usuario. (Esto generalmente se hace mediante redirección de URL, de lo que hablaré más adelante). Por lo tanto, para el cliente malicioso, no es suficiente conocer la identificación del cliente / el secreto en el que el usuario confía. Tiene que implicar de alguna manera o suplantar al usuario para darle el código de autorización, que debería ser más difícil que simplemente conocer el id / secreto del cliente.

2. La URL de redireccionamiento está registrada con el ID del cliente / secreto

Supongamos que el cliente malicioso de alguna manera logró involucrar al usuario y hacer que haga clic en el botón "Autorizar esta aplicación" en la página del servicio. Esto disparará la respuesta de redirección de URL del servicio al navegador del usuario con el código de autorización. Luego, el código de autorización se enviará desde el navegador del usuario a la URL de redireccionamiento, y se supone que el cliente estará escuchando en la URL de redireccionamiento para recibir el código de autorización. (La URL de redireccionamiento también puede ser localhost, y calculé que esta es una forma típica en que un "cliente público" recibe el código de autorización.) Dado que esta URL de redireccionamiento está registrada en el servicio con el ID / secreto del cliente, el cliente malicioso no lo hace tener una forma de controlar dónde se otorga el código de autorización. Esto significa que el cliente malicioso con su id. De cliente / secreto tiene otro obstáculo para obtener el código de autorización del usuario.