5

我在这里查看了 Apple 的应用内购买验证控制器补丁：https ://developer.apple.com/library/ios/#releasenotes/StoreKit/IAP_ReceiptValidation/_index.html

我正计划实施服务器验证，但不需要立即响应。

他们的新代码的异步部分是绝对必要的吗？与幼稚的服务器端验证相比，它有什么优势吗？

如果我可以使用即时解析和检查并获得好处，那就太好了。

谢谢！

编辑：没有一些代码，这个问题感觉有点空：

我专门谈论将主要的 verifyPurchase 函数更改为仅包含：

- (BOOL)verifyPurchase:(SKPaymentTransaction *)transaction;
{
    return [self isTransactionAndItsReceiptValid:transaction];
}

...并摆脱客户端-> 服务器帖子。我是否仍然容易受到最近的黑客攻击？

4

1 回答 1

3

查看代码后，您的问题更有意义。

有问题的攻击是有人出示了其他人的有效收据。收据数据中似乎没有任何内容将其与设备/购买者联系起来。您可以通过检查购买日期在一定程度上缓解这种情况（但前提是设备有准确的时间，这在用户的控制之下）。

（如果客户端生成必须与收据匹配的 256 位随机随机数，则此攻击将不起作用。攻击者显然可以破解二进制/PRNG，但在任何一种情况下，您都已经丢失了。）

顺便说一句，代码有很多问题：

  • 服务器证书的唯一检查是它是 EV 证书。这应该很容易伪造，因为攻击者完全控制了 CA。
  • 在网络检查完成之前，交易 ID 会永久添加到“已看到”交易列表中-isTransactionAndItsReceiptValid:，但内容只有在网络返回后才会解锁。如果连接失败，收据将永远无法重新验证，因此用户的钱实际上会进入一个黑洞。
  • 它期望事务发生在验证它的同一设备上。
  • 它期望 ITC_CONTENT_PROVIDER_SHARED_SECRET 嵌入到可执行文件中（用越狱设备解密很简单）。
  • 它假定-connection:didReceiveData:返回完整的收据数据（由于碎片可能不是这种情况，但由于 Apple 控制服务器实现，因此可能可以保证）。
于 2012-07-25T13:17:25.323 回答