ios - 服务器收据验证还是Apple的VerificationController.m？

Question

如果我实现Apple的VerificationController.m示例，是否还需要进行服务器端收据验证？另外，如果您在服务器端进行操作，那么似乎没有理由实现 VerificationController.m，因为您没有从设备联系 Apple 的服务器。

最好的情况是，我宁愿只实现 VerificationController.m，因为我没有很好的方法来运行我自己的 https 服务器。够了吗？该应用程序在 iOS 5+ 上运行

Answer 1

这比第一次出现时要棘手，所以我可能会犯这个微妙的错误，但这里是:

原始攻击依赖于 iOS ≤ 5.x 中的两个弱点:

• 无法检查 App Store 服务器是否真实(允许用户/攻击者安装 CA 证书，从而绕过 SSL 证书检查)。
• 无法检查该设备的收据是否有效。

这允许用户/攻击者冒充 App Store 服务器并出示其他人购买的有效收据。

VerificationController 无法修复第一个弱点(它无法改变 StoreKit 与 Apple 对话的方式)；它主要只是修复第二个。它似乎还检查了比应该需要的更多的东西(但我在这里可能完全错误)，包括 StoreKit 可能已经检查的一堆东西。

客户端验证不能防止有人黑客攻击客户端，这在越狱的手机上非常容易。如果所购买的东西同样容易被黑客入侵(例如游戏弹药/关闭广告)，那么这并不是真正的问题。

当服务器提供所购买的东西(例如 DLC/Skype 积分/FarmCoins)时，服务器端验证是可取的。

• 对于消耗品，服务器需要确保交易仅应用于一个账户；检查设备 ID 有点多余——攻击者需要在购买者之前提交交易收据，这要么涉及购买者交出收据(不是真正的攻击)，要么攻击者通过 SSL 攻击窃取收据(这意味着要担心的事情要大得多)。
• 对于非消耗品(例如 DLC)，您还需要验证设备 ID。这可以像客户端将其设备 ID 发送到服务器一样简单 - 这不能防止客户端被黑客攻击，但攻击者可以伪造设备 ID 或盗版 DLC。

一般来说，在将收据转换为购买的商品时进行验证。

但是 VerificationController 存在一些问题:

• 它检查收据验证服务器是否正在使用 EV 证书，但不执行任何其他 SSL 层检查。我不知道用户是否可以安装支持 EV 的 CA 证书(并且用不了多久 EV CA 就会被泄露)。
• 您必须将收据验证密码嵌入到应用中(搜索“password”和“ITC_CONTENT_PROVIDER_SHARED_SECRET”)，在越狱的手机上提取该密码很简单。我不确定攻击者可以用它来做什么坏事，但 secret 的意义在于它是 secret !
• “之前见过”的交易被视为无效，但它会在联系收据验证服务器之前将交易标记为“已见过”!这意味着您永远不会达到 //Validation suceeded。在此处解锁内容。如果收据验证连接失败，这种情况很容易在较差的 3G 连接上发生。对于非消耗性事务来说，这可能不是问题(我认为恢复的事务会获得新的事务 ID)，但意味着消耗性事务会永远丢失。您可以推迟调用 -[SKPaymentQueue finishTransaction:] 直到收据验证成功，但这会在队列中留下不完整的交易 - 希望它们最终会过期而不向用户收费。
• 它信任 NSUserDefaults 的内容。这是应用备份的一部分，可以轻松编辑。
• 假设-connection:didReceiveData:返回所有响应数据。对于服务器和 NSURLConnection 的实现细节来说，这可能是正确的，但依赖于此是不明智的。