Безопасность облачных сообщений google

Компания создает проект и получает идентификатор отправителя. Компания создает приложение, запекает свой идентификатор отправителя и помещает приложение в магазин.

Attacker обращает инженеров приложение и извлекает как идентификатор отправителя, так и интерфейс сервера, используемый для получения идентификаторов регистрации GCM.

Attacker создает свое приложение, испекает идентификатор отправителя и серверный интерфейс регистрации, помещает приложение в магазин. Приложение для атаки в основном олицетворяет реальное приложение компании в отношении GCM: оно регистрирует получение сообщений от идентификатора отправителя компании, а затем отправляет свой идентификатор регистрации GCM на серверы компании так же, как это делает «реальное» приложение.

Теперь компания хочет транслировать некоторую информацию во все экземпляры своего приложения. Возможно, это напоминание, но обновление доступно. Есть ли способ отличить «приложение атаки» (которое зарегистрировано как реальное) от «реальных» версий приложения компании?

Solutions Collecting From Web of "Безопасность облачных сообщений google"

Та же проблема могла бы существовать и с C2DM, который вы можете обнюхать адресом электронной почты отправителя, а не идентификатором проекта для GCM.

C2DM или GCM, никогда не следует использовать для отправки конфиденциальной информации пользователя (например, имя учетной записи, личная информация и т. Д.), Она в основном полезна для уведомления, которое реальное приложение может использовать для выполнения дальнейших действий.

Я не вижу, насколько полезным может быть уведомление для «поддельного / взломанного» приложения, что они собираются делать с уведомлением «У вас есть новое сообщение»?

Я думаю, что из вашего сценария злоумышленник не может отправить сообщение пользователю, даже если у него есть идентификатор регистрации. Сервер компании, который отправляет сообщения, которые им необходимы для аутентификации (OAuth2), имеет аккаунт сначала через Google. Таким образом, только если злоумышленник знает пароль отправляющей стороны и идентификатор регистрации, чем может отправить пользователя. Но пароль отправившей стороны, конечно, никогда не отправляется на клиентскую сторону.

Хорошо, это может даже работать в отладочной версии приложения злоумышленников, но он не может поместить свое приложение в магазин. Частью идентификатора GCM является идентификатор приложения, который должен быть уникальным в магазине.

Идентификатор регистрации GCM запрашивается Google, запрашивается у приложения и отправляется на ваш сервер. Когда кто-то с другим приложением (но тот же идентификатор отправителя) создает Regid, он все равно должен быть привязан к серверу, и вам сначала нужно явно отправить сообщение этому определенному региду.

Установка приложения, независимо от того, законна она или нет, никогда не может получать сообщения, на которые она не разрешена. (Если вы заявляете и используете разрешение C2D_MESSAGE )

На самом деле, google позволяет вам зарегистрировать ключ сервера для GCM, который позволяет вам использовать IP-адреса White-List Server … Поэтому вы должны добавить свой IP-адрес сервера, и вы будете в безопасности, поскольку только ваш сервер может отправлять сообщения с этим ключом.

В этом случае GCM безопасен.
Вы даже не можете использовать свой идентификатор отправителя в своем оригинальном приложении, прежде чем регистрировать приложение в GoogleApiConsole. Это означает, что вы указываете отпечаток секретного ключа в GoogleApiConsole. Достаточно.

Я бы предложил иметь собственный «промежуточный сервер», который использует ключ API (идентификатор отправителя, как вы его называли). Вместо того, чтобы внедрять его в самом приложении.