我在这里查看 Apple 的应用程序内购买验证 Controller 补丁:https://developer.apple.com/library/ios/#releasenotes/StoreKit/IAP_ReceiptValidation/_index.html
我正计划实现服务器验证,但不需要立即响应。
他们新代码的异步部分是绝对必要的吗?与简单的服务器端验证相比,它有什么优势吗?
如果我可以使用即时解析和检查并从中受益,那就太好了。
谢谢!
编辑:如果没有一些代码,这个问题感觉有点空洞:
我正在专门讨论将主要的 verifyPurchase 函数更改为仅包含:
- (BOOL)verifyPurchase:(SKPaymentTransaction *)transaction;
{
return [self isTransactionAndItsReceiptValid:transaction];
}
...并摆脱客户端 -> 服务器帖子。我是否仍然容易受到最近的黑客攻击?
最佳答案
看了代码后你的问题就更有意义了。
有问题的攻击是某人出示了其他人否则有效的收据。收据数据中似乎没有任何内容将其与设备/购买者联系起来。您可以通过检查购买日期在一定程度上缓解这种情况(但仅设备具有准确的时间,这在用户的控制之下)。
(如果客户端生成一个必须与收据匹配的 256 位随机数,则此攻击将不起作用。攻击者显然可以破解二进制文件/PRNG,但无论哪种情况,您都已经丢失了。)
顺便说一句,代码有一堆问题:
- 服务器证书的唯一检查是它是一个 EV 证书。这应该很容易伪造,因为攻击者可以完全控制 CA。
- 在网络检查完成之前,交易ID被永久添加到
-isTransactionAndItsReceiptValid:
中的“已看到”交易列表中,但内容只有在网络返回后才能解锁。如果连接失败,收据将永远无法重新验证,因此用户的钱实际上已经进入了黑洞。 - 它希望交易发生在验证它的同一台设备上。
- 它期望 ITC_CONTENT_PROVIDER_SHARED_SECRET 嵌入到可执行文件中(使用越狱设备解密很简单)。
- 它假设
-connection:didReceiveData:
返回完整的收据数据(由于碎片可能不是这种情况,但由于 Apple 控制服务器实现,因此可以保证)。<
关于iphone - 苹果新验证 Controller 的异步部分是必须的吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/11635961/