公司創建一個項目並收到發件人ID。公司創建應用程序，烘焙其發件人ID並將應用程序放入商店。谷歌雲郵件安全
攻擊者反向工程應用程序並提取發件人ID和用於接收GCM註冊ID的服務器接口。
攻擊者創建自己的應用程序，烘焙公司的發件人ID和服務器註冊界面，將應用程序放入商店。就GCM而言，攻擊應用程序基本上模仿了公司的真實應用程序：它註冊接收來自公司發件人ID的消息，然後將其GCM註冊ID發送到公司的服務器，就像「真實」應用程序一樣。
現在，公司希望向其應用程序的所有實例廣播一些信息。也許這是一個提醒，而不是可用的更新。有沒有什麼辦法可以將「攻擊應用程序」（它與真實的應用程序一樣）與「真實」版本的公司應用程序區分開來？
C2DM也存在同樣的問題，您可以嗅探發件人的電子郵件地址，而不是GCM的項目ID。
C2DM或GCM不應該用於發送敏感用戶信息（即帳戶名稱，私人信息等），它主要用於通知，真正的應用程序可以使用它來執行進一步的操作。
我看不出通知對'假/黑客'應用程序有多麼有用，他們將如何處理'您有新消息'通知？
你有什麼消息來源？ – Schiavini 2014-03-03 14:33:33
好吧，這甚至可以在攻擊者應用程序的調試版本中工作，但他無法將他的應用程序放入商店。 GCM標識的一部分是商店中需要唯一的應用ID。
我認爲從你的場景中，即使他有註冊ID，攻擊者也不可能向用戶發送消息。發送他們需要驗證的消息的公司服務器（OAuth2）首先通過Google帳戶進行驗證。所以只有當攻擊者知道發送方的密碼和註冊ID比它可以發送用戶。但發送方的密碼當然不會發送給客戶端。
谷歌要求GCM註冊ID，從應用程序請求並提交給您的服務器。當具有不同應用程序（但發件人ID相同）的人創建Regid時，它仍然必須提交給服務器，並且首先必須明確地向特定的regid發送消息。
應用程序安裝無論是否合法，都不能接收未經授權的消息。 （只要你聲明和使用C2D_MESSAGE權限）
其實，谷歌讓我們註冊一個GCM服務器密鑰，它可以讓你白名單服務器的IP ... 所以你應該添加你的服務器IP，你會很安全，因爲只有你的服務器被允許使用該密鑰發送消息。
GCM在這種情況下是安全的。
在GoogleApiConsole中註冊應用程序之前，您甚至無法在原始應用程序中使用您的發件人ID。這意味着您可以在GoogleApiConsole中指定私鑰指紋。這就夠了。
我會建議有你自己的「臨時服務器」，它使用API密鑰（發件人ID，你引用它）。而不是將其嵌入到應用程序本身中。
不錯的問題，但可能在這裏OT。 – ceving 2017-03-22 14:00:47