对于需要推送通知的iOS应用程序,它必须首先请求用户允许这样做。之后,生成设备令牌,通过此令牌,远程服务器可以通过此令牌与用户通信。
我已经阅读了类似的问题here,我认为这还不够。下图是可信证书,它允许我查看此设备上发生的所有流量。
使用Fiddler2以及CertMaker,我可以嗅探HTTPS流量,这意味着客户端可能知道他们发送的数据以及发送到何处。
我的问题是,知道SSL无法保护我的客户端看不到我发送到远程服务器的内容,我是否应该只使用我的应用程序中找到的密钥进行解密?
如encrypt("device_token","secretkey_a0a0a0a")
(假装这是Objective-C)?
有人不能在我的应用程序中找到该密钥吗?我还阅读了this个问题,似乎可以取回密钥。
我的计划是这样的:
activate
。active
和我的密钥解密有效令牌。这可以防止人们随机输入令牌,但是,secretkey_a0a0a0
是一个字符串文字。它很可能在应用程序二进制文件中得到它。
我的问题是,如何保护这个密钥?答案也可以是,如何防止人们向我的服务器发送无效令牌。
我听说过加密,但这不仅适用于资源文件吗?
我该如何处理?
答案 0 :(得分:3)
如果您担心中间的人可以窃取您的令牌并向您的应用程序的用户发送假推送通知,请确保此消息无法发生。由于对apple apn服务器的请求必须使用pem文件进行签名,因此主要关注的是如何保证证书文件的安全性,而不是apn令牌。如果要防止在数据库中写入无效令牌,则应实现一些CRC或奇/偶位机制。
答案 1 :(得分:3)
如果您执行SSL-Pinning(AFNetworking
已实现此功能),如果您没有私有服务器,您将无法(在合理的时间范围内)嗅探客户端和服务器之间的https流量键。
答案 2 :(得分:2)
您可能需要查看Push Notifications Guide中的安全部分,特别是标题为“令牌生成和分散”的部分。
设备令牌由通过Apple的APNS连接的设备生成。我的猜测(他们没有在文档中说明)是它对于给定的应用程序标识符是唯一的。
然后,APNS可能会将这些标识符与您用来与之通信的pem
证书进行匹配,从而验证推送通知实际上是来自您的应用。
在这种情况下,加密设备令牌似乎有点过分了。
答案 3 :(得分:0)
为防止有人用令牌恶意向您的服务器发送垃圾邮件,我会在密钥生成时对令牌进行哈希处理,并将令牌和哈希值都发送给服务器。然后,您可以使用私钥在服务器上再次对令牌进行哈希处理,并检查请求是否有效。