Apple 提供了一个端点来验证收据:
https://buy.itunes.apple.com/verifyReceipt 并警告不要从应用程序调用端点
It is not possible to build a trusted connection between a user’s device and the App Store directly because you don’t control either end of that connection, and therefore can be susceptible to a man-in-the-middle attack.
据说，安全的方法是先将收据发送到“我自己的”服务器，然后从自己的服务器与Apple端点通信。
老实说，我不明白它如何帮助提高安全级别。是的，我不控制
/verifyReceipt 端点，但 Apple 希望能做到。为什么手机 <-> 我的服务器 <-> 苹果服务器 比 手机 <-> 苹果服务器 好？
您能否从黑客(或中间人)的角度详细说明这一点？在后一种情况下，他将如何篡改收据/回复，而在前一种情况下，是什么让他感到困难？
最佳答案
更改应用程序二进制文件以更改应用程序内的字符串相对容易。如果您的二进制文件包含字符串“https://buy.itunes.apple.com/verifyReceipt ”，那么攻击者可以将字符串更改为“https://example.com/verifyReceipt ”(受他们控制的服务器)，并让服务器返回收据 JSON，从而使购买看起来像是成功的。这是一种易于自动化的攻击，因此您只需通过脚本运行二进制文件，该脚本将 Apple URL 的所有实例替换为另一个 URL。
当您使用自己的服务器与 Apple 通信时，您可以(相对)确定该连接是安全的。还有一些方法可以保护应用程序和您的服务器之间的通信，例如应用程序二进制文件中的证书带有公钥，即您服务器上的私钥。 (我不是这方面的专家，因此有关 key 的详细信息可能不是 100% 正确的)。
话虽如此，攻击者还可以通过其他方式使其看起来像是购买。他们可以在您的应用程序二进制文件中搜索常见的收据解析库并翻转已知的 bool 值(例如 userCompletedPurchase bool 标志)。这些攻击很容易编写脚本。
确保您的应用程序不受攻击的最佳方法是删除容易实现的目标，并使常见脚本不会打开您的应用程序进行攻击变得更加困难。一种方法是不直接与 Apple 验证收据。
关于ios - 为什么不应该直接调用收据验证端点，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/57988130/