google cloud mensajería de seguridad

Question

La empresa crea un proyecto y recibe un ID de remitente. La empresa crea una aplicación, cuece en su ID de remitente y coloca la aplicación en la tienda.

Attacker realiza una ingeniería inversa de la aplicación y extrae la ID del remitente y la interfaz del servidor utilizada para recibir los ID de registro de GCM.

Atacante crea su propia aplicación, hornea en el identificador de remitente de la empresa y la interfaz de registro del servidor, coloca la aplicación en la tienda. La aplicación de ataque básicamente personifica la aplicación real de la empresa en lo que respecta a GCM: se registra para recibir mensajes de la ID del remitente de la empresa y luego envía su ID de registro de GCM a los servidores de la Compañía al igual que la aplicación "real".

Ahora la empresa desea transmitir cierta información a todas las instancias de su aplicación. Tal vez es un recordatorio de que hay una actualización disponible. ¿Hay alguna manera de diferenciar la "aplicación de ataque" (que se registró como la real) de las versiones "reales" de la aplicación de la empresa?

Answer 1

El mismo problema también podría haber existido con C2DM, que puede oler la dirección de correo electrónico del remitente, en lugar de la ID del proyecto para GCM.

C2DM o GCM, nunca se debe utilizar para enviar información sensible del usuario (es decir, nombre de la cuenta, información privada, etc.), es principalmente útil para la notificación, que la aplicación real puede usar para realizar otras acciones.

No puedo ver qué tan útil puede ser una notificación para una aplicación 'falsa/piratear', ¿qué van a hacer con la notificación 'Tienes un nuevo mensaje'?

Answer 2

bueno, esto incluso podría funcionar en una versión de depuración de la aplicación de atacantes, pero no puede poner su aplicación en la tienda. Parte de la identificación de GCM es la identificación de la aplicación que debe ser única en la tienda.

Answer 3

Creo que, desde su escenario, el atacante no puede enviar un mensaje al usuario, incluso si tiene el ID de registro. El servidor de la empresa que envía los mensajes que necesitan para autenticarse (OAuth2) allí cuenta primero a través de Google. Por lo tanto, solo si el atacante conoce la contraseña de la parte que envía y la ID de registro de la que puede enviar al usuario. Pero la contraseña de la parte que envía, por supuesto, nunca se envía al lado del cliente.

Answer 4

El ID de registro de GCM es solicitado por Google, solicitado desde la aplicación y enviado a su servidor. Cuando alguien con una aplicación diferente (pero con el mismo ID de remitente) crea un Regid, todavía tiene que estar comprometido con el servidor, y primero debe enviar un mensaje explícitamente a ese regid específico.

La instalación de una aplicación, ya sea legítima o no, nunca puede recibir mensajes para los que no está autorizada. (Siempre que declare y use el permiso C2D_MESSAGE)

Answer 5

En realidad, google le permite registrar una Clave de servidor para GCM, que le permite el IP de la lista blanca del servidor ... Debería agregar su IP de servidor y estaría a salvo , ya que solo su servidor puede enviar mensajes con esa clave.

Answer 6

GCM es seguro en este caso.
Incluso no puede usar su Id. De remitente en su aplicación original antes de registrar la aplicación en GoogleApiConsole. Esto significa que señala la huella digital de clave privada en GoogleApiConsole. Es suficiente.

Answer 7

Sugeriría tener su propio "servidor interino" que utiliza la clave de la API (Id. Del remitente como usted lo mencionó). En lugar de incrustarlo en la aplicación en sí.