ios - 服务器回执验证还是苹果的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 就会遭到破坏)。
• 您必须在应用程序中嵌入您的收据验证密码(搜索“密码”和“ITC_CONTENT_PROVIDER_SHARED_SECRET”)，这在越狱手机上很容易提取。我不确定攻击者可以利用它做什么坏事，但可以肯定的是， secret 的意义在于它是 secret 的!
• 它“以前见过”的交易被认为是无效的，但它会在联系收据验证服务器之前将交易标记为“已见过”!这意味着您永远不会到达 //Validation suceeded。在此处解锁内容。 如果收据验证连接失败，这很容易在 3G 连接不良时发生。这对于非消耗性交易来说可能不是问题(我认为恢复的交易会得到一个新的交易 ID)，但这意味着消耗性交易会永远丢失。您可以推迟调用 -[SKPaymentQueue finishTransaction:] 直到收据验证成功，但这会在队列中留下不完整的交易——希望它们最终过期而不向用户收费。
• 它信任 NSUserDefaults 的内容。这是应用备份的一部分，可轻松编辑。
• 假设-connection:didReceiveData: 返回所有响应数据。这可能适用于服务器和 NSURLConnection 的实现细节，但依赖它是不明智的。