2

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

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

4

1 回答 1

3

这比它第一次出现的要棘手，所以我可能会稍微弄错，但这里是：

最初的攻击依赖于 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”），这在越狱手机上提取是微不足道的。我不确定攻击者可以用它来做什么坏事，但秘密的意义在于它是秘密！
  • 它“以前见过”的交易被认为是无效的，但它在联系收据验证服务器之前将交易标记为“见过”！这意味着//Validation suceeded. Unlock content here.如果收据验证连接失败，您将永远无法到达，这很容易在较差的 3G 连接上发生。这对于非消耗性交易可能不是问题（我认为恢复的交易会获得新的交易 ID），但意味着消耗品会永远丢失。您可以推迟调用-[SKPaymentQueue finishTransaction:]直到收据验证成功，但这会在队列中留下不完整的交易——希望它们最终到期而不向用户收费。
  • 它信任 NSUserDefaults 的内容。这是应用程序备份的一部分，可轻松编辑。
  • 它假定-connection:didReceiveData:返回所有响应数据。这对于服务器和 NSURLConnection 的实现细节可能是正确的，但依赖它是不明智的。
于 2013-01-18T22:24:11.000 回答