En la plataforma Android, ¿es seguro usar un esquema URI personalizado para recibir una respuesta de autorización OAuth 2.0 de la plataforma de identidad de Google?

Question

En la plataforma Android, ¿es seguro usar un esquema URI personalizado para recibir una respuesta de autorización OAuth 2.0 de la plataforma de identidad de Google?

#1 de Steve (1 votos)
#2 de Merk (1 votos)

1

Suponiendo que he desarrollado una aplicación para Android utilizando la plataforma de identificación de Google como su sistema de identificación. En el documento Identify Platform ( enlace ) de Google, dice "Su aplicación debe registrarse en el sistema para el esquema de URI personalizado. para recibir la respuesta de autorización ".

Mi pregunta es si un hacker realizó una ingeniería inversa de mi APK y descubrió mi esquema de URI personalizado. Luego usó ese esquema URI personalizado y lanzó su propia aplicación de Android con ese esquema URI ( enlace ). Luego, Google puede estar enviando la respuesta de autorización OAuth 2.0 (código de autenticación) a la aplicación de Android del pirata informático.

¿No es un gran problema de seguridad?

oauth2 access-control

pregunta ytw 12.12.2016 - 16:56

fuente

2 respuestas

Lea otras preguntas en las etiquetas oauth2 access-control

¿Qué tan prácticos son los códigos de prueba para garantizar la seguridad de un programa? problema de tamaño de tokens JWT

score 1 · Answer 1

En realidad, ese es uno de los problemas de seguridad fundamentales. Si alguien sabe cómo se supone que debe funcionar tu aplicación, entonces pueden imitarla y hacer cosas malas como robar fichas.

Dado eso, no hay una solución directa al problema, sino un montón de soluciones relacionadas para problemas ligeramente diferentes. Estos incluyen (pero no se limitan a):

Restricciones de dispositivos para evitar la carga lateral de aplicaciones
validación de la aplicación al enviar a la tienda
Almacenar solicitudes de desmontaje

Este es el precio que pagamos (actualmente) por tener capacidades de SSO dentro de una aplicación. Hay otras opciones como requerir claves personalizadas por instancia de aplicación, pero eso es imposible de administrar, y solo hace que el trabajo de los atacantes sea un poco pequeño un poco más difícil. A la inversa, puede enviar la autenticación y el intercambio de tokens al dispositivo en sí mismo dentro de un proceso similar a un sistema, pero eso solo significa que la aplicación malvada debe hacer lo mismo, lo que en realidad podría facilitar su trabajo.

Entonces, básicamente, se reduce a si está cómodo con las protecciones anteriores que ya están en su lugar.

score 1 · Answer 2

Este riesgo de seguridad en particular se ha analizado en un estándar llamado PKCE, que intenta mitigarlo: enlace . PKCE es una extensión de OAuth, y tanto su servidor como su aplicación deben implementarla para usarla.

La biblioteca de código abierto AppAuth patrocinada por Google implementa PKCE para usted. enlace

Personalmente, creo que es mejor usar una redirección https: // en lugar de una redirección URI personalizada. Esto requiere una configuración en un servidor que coincida con el enlace https: // para asegurarse de que su aplicación y solo su aplicación puedan controlar ese redireccionamiento. Consulte enlace para una discusión.

Una discusión de algunos de los temas involucrados aquí está enterrada en esta discusión mucho más amplia: enlace

Observe que este último documento sugiere utilizar la mitigación de PKCE incluso si elige la ruta https: // redirect. No he descubierto qué tipo de ataque teórico tienen en mente. Mencionan la "comunicación interapp" por la cual podrían significar (supongo) un caso de ventaja en el que se ha inyectado malware en otra aplicación instalada firmada con su clave de desarrollador.