secreto de cliente en OAuth 2.0

95

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 se trata de una aplicación cliente. Entonces, todos pueden descompilar mi aplicación y extraerla del código fuente. ¿Significa que una mala aplicación puede pretender ser una buena aplicación usando la identificación del cliente y el secreto de la buena aplicación? Entonces, ¿el usuario estaría mostrando una pantalla que solicita otorgar permiso a una buena aplicación a pesar de que en realidad es solicitada por una mala aplicación? Si es así, ¿qué debo hacer? ¿O en realidad no debería preocuparme por esto?

  2. En la aplicación móvil, podemos incrustar una vista web en 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 de usuario del proveedor de servicios?

security  oauth  google-api  oauth-2.0 
— Oso
fuente
2
También supongo que la gente suele sospechar cuando la aplicación les pide sus credenciales de Facebook, Twitter, Dropbox u otras. Dudo que mucha gente común lea las especificaciones de OAuth y diga "Ahora estoy seguro", sino que usa el sentido común y, en general, no usa aplicaciones en las que no confía.
— Igor Čordaš
Realmente una gran pregunta definitivamente debería tener más puntos
— Shravan
simplemente puede descargar el ClientId y el secreto de su servidor y guardarlo en un llavero en el primer inicio de sesión exitoso, eso es todo
— Shravan
@Sharvan Puedo estar equivocado, pero creo que los llaveros son vulnerables en teléfonos rooteados, por lo que el secreto de su cliente podría hacerse público.
— chichilatte

Respuestas:

16

Comencé a escribir un comentario a 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í, existe 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 una parte en la especificación de que las aplicaciones distribuidas no deben usar este token. Ahora puede preguntar, pero XYZ lo requiere para funcionar. En ese caso, no están implementando la especificación correctamente y no debería A usar ese servicio (no es probable) o B intentar asegurar el token usando algunos métodos de ofuscación para hacer más difícil encontrar o usar su servidor como proxy.

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

  2. He estado despotricando sobre el punto 2 durante bastante tiempo. Incluso he realizado algunas soluciones en mis aplicaciones para modificar las páginas de consentimiento (por ejemplo, cambiar el zoom y el diseño para que se ajusten a la aplicación), pero no hubo nada que me impidiera leer los valores de los campos dentro de la vista web con nombre de usuario y contraseña. Por lo tanto, estoy totalmente de acuerdo con su segundo punto y lo encuentro un gran "error" en las especificaciones de OAuth. El hecho de que "La aplicación no tiene acceso a las credenciales de los usuarios" en la especificación es solo un sueño y les da a los usuarios una falsa sensación de seguridad ... También creo que la gente suele sospechar cuando la aplicación les pide sus credenciales de Facebook, Twitter, Dropbox u otras. Dudo que mucha gente común lea las especificaciones de OAuth y diga "Ahora estoy a salvo", sino que usa el sentido común y, en general, no usa aplicaciones en las que no confía.

— Igor Čordaš
fuente
3
Su ID de cliente y su secreto de cliente no estarán seguros solo porque los publique en un túnel SSL. Sí, están más seguros de los ataques de hombre en el medio. Si un usuario hace proxy de su llamada HTTP, puede aceptar el certificado incorrecto y ver todo lo que publica. Por cierto, esta es la forma más fácil de robar el secreto del cliente de alguien en dispositivos móviles.
— EpicThreeDev
5
Aprecio tu comentario, pero no puedo conectarlo con mi respuesta de ninguna manera ... ¿Podrías explicar por qué comentaste mi respuesta porque dije explícitamente que el secreto del cliente no debe usarse en aplicaciones distribuidas y el otro punto fue que Existen soluciones para obtener las credenciales de usuario en las aplicaciones, incluso si se usa OAuth, por lo que los usuarios deben confiar en el proveedor de la aplicación y no en OAuth.
— Igor Čordaš
Además, no entiendo lo que quiere decir con "Si un usuario usa su llamada HTTP", sí, los usuarios obtienen acceso a los datos que enviaron mediante HTTP y son libres de hacer llamadas proxy como quieran. Según entendí, estás sugiriendo esto como una buena alternativa a desmontar la apk para obtener el secreto, pero, de nuevo, no deberías enviar el secreto de la aplicación en primer lugar.
— Igor Čordaš
Entonces, para el punto 1) ¿la aplicación incorrecta debe tener acceso al mismo sistema y recuperar el token de acceso / actualización del mismo dispositivo?
— Gauteh
No está claro qué considera "mismo sistema" en este contexto. La aplicación crea una vista web en la que se muestra la página de confirmación y puede acceder a todos los datos en esa vista (incluidas las cookies o los parámetros de URL que alojan el token de acceso). El acceso entre aplicaciones también es posible en algunos casos, por ejemplo, si una aplicación puede acceder a los registros de otras aplicaciones, podría encontrar el token allí, como se menciona con el error fb lib.
— Igor Čordaš
16

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

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

Incluso si el usuario indica al servicio que confía en el cliente, el cliente no puede obtener el código de autorización del servicio simplemente mostrando la identificación 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 la redirección de URL, de la que hablaré más adelante). Por lo tanto, para el cliente malintencionado, no es suficiente conocer la identificación / secreto del cliente en el que confía el usuario. Tiene que involucrar o engañar al usuario de alguna manera para darle el código de autorización, lo que debería ser más difícil que solo saber la identificación / secreto del cliente.

2. La URL de redireccionamiento está registrada con la identificación / secreto del cliente.

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 de servicio. Esto activará la respuesta de redireccionamiento de URL desde el 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 debe estar escuchando la URL de redireccionamiento para recibir el código de autorización. (La URL de redireccionamiento también puede ser localhost, y supuse que esta es una forma típica en la que un "cliente público" recibe un código de autorización). Dado que esta URL de redireccionamiento está registrada en el servicio con la identificación / secreto del cliente, el cliente malicioso no tener una forma de controlar dónde se da el código de autorización.

— Hideaki
fuente
3
Esto es prometedor, ¿tiene alguna referencia para esto? Sería reconfortante saberlo.
— Gauteh
1
Vi en los documentos de Drive que en las aplicaciones instaladas el secreto del cliente no es realmente un secreto, pero no explican por qué está bien almacenarlo allí. ¡Tu explicación ayudó mucho!
— Martin Spasov
1

Respondiendo a la segunda pregunta: las API de Google por motivos de seguridad exigen que la autenticación / inicio de sesión no se pueda realizar dentro de la aplicación en sí (como las vistas web no están permitidas) y debe realizarse fuera de la aplicación mediante el navegador para una mayor seguridad, que se explica a continuación: https: //developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html

— vj
fuente
al menos está "arreglado" 3 años después de haber preguntado :)
— Bear
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.