0

我有一个跨 iOS 和 Android 运行的应用程序。我正在努力向该应用程序添加推送通知。

在非常高的级别上，设备向 Apple Push Notification Service (APNS) 或 Google Cloud Messaging (GCM) 注册并接收令牌。然后，他们将该令牌交还给负责发送通知的服务器。该服务器在需要时向 APNS 或 GCM 发送通知，并说“将此通知发送到具有这些令牌的设备”。

因此，我的应用程序需要能够安全地将其令牌发送到我的服务器，并在用户不再希望接收通知时从服务器中删除这些令牌。在服务器端添加一个简单的 CRUD 页面非常容易，它处理?create=<token>,?delete=<token>等。

但是，当有人访问我的服务器并开始向我的服务器发送随机值时会发生什么?delete=<token>——他们似乎可以随意删除随机设备令牌？

我对“删除”案例进行了更多思考，我认为这应该很简单：应用程序只需发送生成的公共解密密钥和初始“创建此令牌”请求即可。该密钥可以针对令牌存储。当应用程序想要删除时，它可以发送令牌的加密副本，服务器可以将令牌与解密副本进行匹配，验证应用程序必须拥有与私有加密密钥匹配的存储公钥（这是一个已知的秘密仅适用于应用程序）。

当有人开始向随机值发送垃圾邮件时会发生什么?create=<token>——他们是否只能用假设备令牌填充我的数据库表？

I can't see an easy answer — rate limiting "create" requests from any single IP address seems to be about the best we can do without registration involved. That obviously isn't going to help us against any distributed attack.

理想情况下，我希望默认启用推送通知/无需用户“注册”或类似的东西。我的第一个想法是每个设备令牌都应该与已知的规范 Apple ID 或 Google 帐户相关联——但我如何阻止用户伪造这些？设备是否带有我可以获得权威公钥的证书（在这种情况下，每个设备只能获得与其公钥绑定的一行）？我在这里实施身份验证的最佳方式是什么？

4

2 回答 2

4

可以在此处找到针对 android 的问题的解决方案。简而言之，可以概括为

您使用可通过 Google Play 服务获得的 GoogleAuthUtil 类来检索称为“ID 令牌”的字符串。您将令牌发送到您的后端，您的后端可以使用它来快速、廉价地验证哪个应用程序发送了它以及谁在使用该应用程序。

于 2013-05-08T05:26:26.547 回答
1

这里有很多好问题。:)

让我试着把它分解。

一般想法

  • 我认为在这里混合 Android 和 iOS 并不是一个好主意。高级推送通知架构在它们之间是相似的，但仅此而已。

  • 令牌很长（我记得 iOS 令牌是 uuid）。所以，没有办法通过随机尝试不同的值来猜测它。所以，我会说?delete=<token>案例不存在。

  • 的情况?create=<token>比较现实。首先，有人可以让你的服务器瘫痪，注册数百万个令牌。此外，如果您通过推送通知发送一些敏感信息，您可能不希望非授权应用用户收到这些信息。

安卓解决方案

对于 Android，它更容易。

一旦您在服务器上获得令牌，只需发送带有一些随机生成的字符串的推送消息（将其存储在数据库中）。您在设备上的应用程序将获取此字符串并将其与令牌一起发送到服务器（通过第二个网络调用）。并且您的服务器确保只有在经过身份验证后才会向该令牌发送任何内容。

这样，您就可以依靠 GCM 将消息传递给正确的客户端的能力，以确保将身份验证信息（随机字符串）传递给您的应用程序。

iOS 解决方案

iOS 的问题在于，如果应用程序被挂起或在后台，推送通知不会自动触发代码执行。

因此，如果您尝试做同样的事情并且用户不小心退出了您的应用程序，而推送通知正在传递，那么您的应用程序将永远看不到它。

您可以执行以下操作（这个想法与 Android 基本相同，不同之处在于我们可能需要用户交互）

  • 带有消息“请运行我的应用程序并输入 X”的推送通知（其中 X 是一些随机字符串）
  • 这样，如果您的应用程序在后台，用户将单击此消息，输入 X，您的应用程序将通过服务器身份验证。
  • 在这种情况下，如果应用程序在前台，它将获得推送有效负载并可以直接进行身份验证。
于 2013-05-06T20:19:45.347 回答