问题描述
Apple的iOS应用程序内购买系统过去遭到了欺骗应用程序免费提供内容的人的攻击。他们改进了所涉及的系统以试图限制这种事情。
Apple's iOS in-app purchase system has been attacked in the past by people who have tricked apps into giving them content for free. They have since improved the systems involved to try to limit this kind of thing.
我已经阅读了Apple提供的StoreKit参考文档，我对工作流程和需要完成的检查，等等。但是，可能存在我不知道的安全问题。
I've read through the StoreKit reference documents available from Apple and I have a general idea of the workflow and the checks that need to be done, and so on. However, there may be security issues that I'm not aware of.
任何人都可以提供针对应用内购买机制可以尝试的完整防盗攻击列表，开发人员如何错误地允许这些攻击，以及防止它们的最佳做法是什么？
Can anyone provide a full list of theft-attacks that can be attempted against In-App purchase mechanisms, how developers might mistakenly allow these attacks, and what are best practices for preventing them?
推荐答案
这些是我的攻击意识到，过去和现在：
These are the attacks that I am aware of, past and present:
假App Store
着名的俄罗斯程序员，此攻击仅影响直接通过App Store验证购买收据的应用。通过修改设备的DNS设置并安装伪造的安全证书，验证请求将发送到假的App Store服务器，该服务器会自动返回购买有效的信息。无意识的应用会接受这些验证通话并将内容传送给用户。
Made famous by the Russian programmer Alexey Borodin, this attack only affects apps that verify purchase receipts directly with the App Store. By modifying the DNS settings of the device, and installing forged security certificates, the verification requests are sent to a fake App Store server, which automatically returns that the purchase is valid. Unsuspecting apps will accept these verification calls and deliver the content to the user.
评论
在2012年7月公布此漏洞后，Apple为开发人员发布了更新的文档和建议，以确保此类攻击不会继续发生。根据Apple更新的API和最佳实践指南，Borodin在各种网络文章中引用了游戏已结束。
After this exploit was made known in July of 2012, Apple issued updated documentation and advice for developers to ensure this kind of attack would not continue to occur. Borodin has been quoted in various web articles as stating that the "game is over" based on Apple's updated APIs and best practices guidelines.
预防
Apple有一整个专门针对这个漏洞的文件。 （编辑：链接已关闭，如果你想......虽然该文件涵盖了iOS 5.1及更早版本。）他们提出的最重要的一点是让你的应用程序将收据发送给您拥有的外部服务器，然后让您的服务器验证Apple的收据。但是，如果您确实将收据直接从应用程序发送到App Store，他们建议您进行以下检查：
Apple has an entire document dedicated to this loophole here. ( Link is down, Wayback if you want...although the document covered iOS 5.1 and earlier.) The biggest point they bring up is having your app send the receipt to an external server that you own, and then having your server verify the receipt with Apple. However, if you do send the receipt directly from the app to the App Store, they recommend the following checks:
- 检查SSL证书用于连接到App Store服务器的是EV证书。
- 检查验证返回的信息是否与SKPayment对象中的信息匹配。
- 检查收据是否有有效签名。
- 检查新交易是否具有唯一的交易ID。
- Check that the SSL certificate used to connect to the App Store server is an EV certificate.
- Check that the information returned from validation matches the information in the SKPayment object.
- Check that the receipt has a valid signature.
- Check that new transactions have a unique transaction ID.
虚假验证服务器
如果您的应用将交易收据发送到您的服务器，然后将其转发到App Store，一个选项是攻击者伪造您的验证服务器。通过某种方法（改变DNS表，更改URL等），将收据发送到备用位置并返回成功验证。通过这种方式，收据永远不会到达您的服务器，您再也没有机会通过App Store进行检查。
If your app sends the transaction receipts to your server, which then forwards them to the App Store, one option is for the attacker to fake your verification server. By some method (altering the DNS table, changing the URL, etc.) the receipt is sent to an alternate location and a "successful verification" is returned. In this way the receipt never reaches your server and you never have a chance to check it with the App Store.
评论
显然，Cydia商店中有多种应用程序可以在后台运行，监控收据流量，并为此目的重定向。来源：
Apparently there are a variety of apps in the Cydia store that serve to run in the background, monitor receipt traffic, and redirect it for this purpose. Source: Hussulinux Blog
预防
如果您在收到验证后立即发送内容，则无法防止此类攻击。但是，请采用以下方案：您在自己的服务器上管理用户帐户系统。如果应用程序内购买的目的是通知您的服务器某个特定用户帐户已购买某个项目，并且该应用程序从您的服务器下载该项目，则您可以免受攻击。将收据重定向到另一台服务器将不会为攻击者做任何事情，因为您的服务器永远不会将用户帐户标记为拥有项目，因为它从未看到收据。
If you immediately deliver content as soon as a receipt is verified, there is no known way to prevent this kind of attack. However, take this scenario: you have a user account system managed on your own server. If the purpose of the In-App Purchase is to notify your server that a particular user account has purchased an item, and the app downloads that item from your server, you are immune to the attack. Redirecting the receipt to another server will accomplish nothing for the attacker, because your server will never mark the user account as owning an item, as it never sees the receipt.
假收据
攻击者可以伪造购买流程，然后将伪造的收据发送到您的验证服务器。与之前的攻击不同，收据的出站位置不会更改，但会被冒名顶替。事实上，这个欺骗性收据是来自先前App Store交易的有效收据，App Store将对其进行验证。通过伪造购买流程然后向您的服务器发送欺骗性收据，内容实际上从未支付过。
An attacker can fake the purchase process and then send a forged receipt to your verification server. Unlike the previous attack, the receipt's outbound location is not changed, but it is replaced with an imposter. This spoofed receipt is, in fact, a valid receipt from a previous App Store transaction, and the App Store will verify it as such. By faking the purchase process and then sending a spoofed receipt to your server, the content is never actually paid for.
评论
显然有各种各样的Cydia应用程序可以做这种事情。您可以发现假收据，因为他们的 product_id 与您在应用中使用的任何内容完全不同。显然，最着名的欺骗id是 com.zeptolab.ctrbonus.superpower1 。来源：。
Apparently there are a variety of Cydia apps that do this sort of thing. You can spot fake receipts because their product_id is totally different from anything you use in your app. Apparently the most famous spoofed id is com.zeptolab.ctrbonus.superpower1. Source: Hussulinux Blog.
预防
在我发现此攻击的链接中，博客建议您在收据验证服务器（base64_decode）上打开收据并检查 product_id ，然后再将收据发送到App Store。但是，在 Apple建议您先将收据发送到App Store，然后阅读返回的信息以确定收据有效。
In the link where I found this attack, the blogger recommended that you unpack the receipt at your verification server (base64_decode) and check the product_id before sending the receipt to the App Store. However, in this article Apple recommends that you first send the receipt to the App Store, and then read the returned information to be certain that the receipt is valid.
（另外，如果我错了，请纠正我，但即使您没有验证服务器，Apple的推荐技术也可用于防止此类攻击如果您的应用程序将收据直接发送到App Store，它可以检查JSON响应的内容以确保其有效。但这违反了Apple推荐的使用外部验证服务器的最佳做法，因此我不会提倡它。 ）
(Also, correct me if I'm wrong, but Apple's recommended technique could also be used to prevent this kind of attack even if you don't have a verification server. If your app sends the receipt directly to the App Store, it could examine the contents of the JSON response to ensure it's valid. But this goes against Apple's recommended best practices of using an external verification server, so I wouldn't advocate it.)
关闭
这些是我所知道的攻击如果我在任何方面出错或者提出额外的攻击和修复，请随时纠正我。
These are the attacks that I'm aware of, feel free to correct me if I'm wrong on any point or to put forth additional attacks and fixes.
作为一个说明，有这个网站：声称可以免费进行应用内购买iOS 5或使用越狱的iOS 6设备，并于2013年7月5日开始运行。虽然我不是100％确定他们是如何做到的，但它确定了迭代似乎涉及DNS重新路由和伪造的安全证书，这意味着假冒App Store或伪造验证服务器，这还意味着仍然存在那些没有抵御这些攻击的应用程序。
As a note, there's this website: http://www.in-appstore.com/ which claims to allow in-app purchases for free, either on iOS 5 or with a jailbroken iOS 6 device, and is active as of July 5th, 2013. While I'm not 100% sure how they are doing it, it definitely seems to involve DNS rerouting and faked security certificates, which would imply Fake App Store or Fake Verification Server, which would additionally imply that there are still apps out there that are not secured against these attacks.
资源
-
一些直接的要点：除非你想让一些青少年编辑，否则不要将你的玩家数据存储在一个简单的plist中。人们不必破解你的IAP系统，如果他们可以通过编辑磁盘上的文件给自己的金币或类似的东西。也许通过加密这些文件，你可以阻止特定部分的攻击者。
A couple of immediate takeaways: don't store your player's data in a simple plist unless you want it to be edited by some teenager. People don't have to hack your IAP system if they can just give themselves gold or something similar by editing the files on the disk. Perhaps by encrypting these files, you could discourage a certain segment of attackers.
基于se7ensins链接，似乎攻击者也可以撬开你的二进制和混乱用它来实现与编辑plist文件相同的目的，甚至更多，但这需要稍高的技能水平。也许设置越狱检测就足以阻止大多数人采取这种做法。
Based on the se7ensins link, it seems as though an attacker can also pry apart your binary and mess with it to achieve the same ends as editing a plist file, or even more, but this will require a slightly higher skill level. Perhaps setting up jailbreak detection would suffice to deter most people who would resort to this.
同样，这部分主要是猜测，但它可能对某人有所帮助。实际上，您拥有的保护级别取决于开发人员愿意走多远（沿着安全和加密的兔子洞）来保护他们的底线。
Again, this section is mostly speculation, but it may help someone. Really, the level of protection you have depends on how far a developer is willing to go (down the rabbit hole of security and encryption) to protect their bottom line.
这篇关于针对iOS应用内购买的攻击保护的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！