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

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

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

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

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

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

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