服务器收据验证或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遭到入侵之前不会很长时间。）
• 您必须在应用中嵌入收据验证密码（搜索＆＃34;密码＆＃34;＆＃34; ITC_CONTENT_PROVIDER_SHARED_SECRET＆＃34;），这可以在越狱手机上提取。我不确定攻击者可以使用它做什么坏事，但肯定的秘密点是它的秘密！
• 以前见过的交易＆＃34;＆＃34;被视为无效，但它将交易标记为＆＃34;看到＆＃34;在联系收据验证服务器之前！这意味着如果收据验证连接失败，您永远不会到达//Validation suceeded. Unlock content here.，这可能很容易通过糟糕的3G连接发生。这可能不是非消耗性交易的问题（我认为恢复的交易获得新的交易ID），但意味着消耗品永远丢失。您可以推迟呼叫-[SKPaymentQueue finishTransaction:]，直到收据验证成功，但这会在队列中留下未完成的交易 - 希望它们最终到期而不向用户收费。
• 它信任NSUserDefaults的内容。这是应用备份的一部分，可以轻松编辑。
• 它假定-connection:didReceiveData:返回所有响应数据。这可能适用于服务器和NSURLConnection的实现细节，但依赖于此是不明智的。