针对iOS应用内购买的攻击保护

苹果的iOS应用程序内购买系统过去曾遭到过一些人的攻击，这些人欺骗应用程序免费提供内容。此后，他们改进了相关系统，试图限制此类事件

我已经阅读了苹果提供的StoreKit参考文档，对工作流程和需要进行的检查等有了大致的了解。但是，可能有一些我不知道的安全问题

---

是否有人可以提供一份针对应用内购买机制的盗窃攻击的完整列表，开发人员可能会如何错误地允许这些攻击，以及预防这些攻击的最佳做法是什么？

这些是我所知道的、过去和现在的攻击：

假应用商店

这一攻击因这位俄罗斯程序员而出名，它只影响直接通过应用商店验证购买收据的应用程序。通过修改设备的DNS设置并安装伪造的安全证书，验证请求将发送到伪造的App Store服务器，该服务器将自动返回购买有效。毫无戒心的应用程序将接受这些验证呼叫并将内容交付给用户

评论

该漏洞在2012年7月被公开后，苹果向开发者发布了更新的文档和建议，以确保此类攻击不会继续发生。Borodin在多篇网络文章中被引用称，根据苹果最新的API和最佳实践指南，“游戏结束了”

预防

苹果公司有一份完整的文件专门针对这个漏洞。（编辑：链接已关闭，如果您愿意的话……尽管文档涵盖了iOS 5.1和更早版本。）他们提出的最大问题是让您的应用程序将收据发送到您拥有的外部服务器，然后让您的服务器与苹果验证收据。但是，如果您确实直接从应用程序向应用程序商店发送收据，他们建议您进行以下检查：

• 检查用于连接到App Store服务器的SSL证书是否为EV证书
• 检查验证返回的信息是否与SKPayment对象中的信息匹配
• 检查收据是否有有效的签名
• 检查新事务是否具有唯一的事务ID

假验证服务器

如果应用程序将交易凭证发送到服务器，然后服务器将其转发到应用商店，则攻击者可以选择伪造验证服务器。通过某种方法（更改DNS表、更改URL等），将收据发送到备用位置，并返回“成功验证”。这样一来，收据永远不会到达您的服务器，您也永远没有机会向应用商店查询收据

评论

显然，Cydia商店中有各种各样的应用程序，它们可以在后台运行，监视收货流量，并为此目的重定向收货流量。资料来源：

预防

如果您在收到验证后立即交付内容，则没有已知的方法可以防止此类攻击。但是，以这种情况为例：您有一个在自己的服务器上管理的用户帐户系统。如果应用程序内购买的目的是通知您的服务器某个特定用户帐户已购买某个项目，并且应用程序从您的服务器下载该项目，则您不会受到攻击。将回执重定向到另一台服务器对攻击者来说将一事无成，因为您的服务器永远不会将用户帐户标记为拥有某个项目，因为它永远不会看到回执

假收据

攻击者可以伪造购买过程，然后向验证服务器发送伪造收据。与之前的攻击不同，收据的出站位置没有更改，但被冒名顶替者替换。事实上，此伪造收据是来自上一个应用商店交易的有效收据，应用商店将对此进行验证。通过伪造购买流程，然后向服务器发送伪造的收据，这些内容永远不会得到实际支付

评论

显然，有很多Cydia应用程序都可以做这种事情。你可以发现假收据，因为它们的

产品id

与你在应用程序中使用的任何东西都完全不同。显然，最著名的伪造id是

com.zeptolab.ctrbonus.superpower1

。来源：

预防

在我发现此攻击的链接中，博主建议您在验证服务器（base64_decode）上打开收据，并在将收据发送到应用商店之前检查

product_id

。然而，苹果公司建议您首先将收据发送到应用商店，然后读取返回的信息，以确保收据有效

（另外，如果我错了，请纠正我的错误，但即使您没有验证服务器，苹果推荐的技术也可以用来防止此类攻击。如果您的应用程序将收据直接发送到应用程序商店，它可以检查JSON响应的内容以确保其有效。但这与苹果推荐的最佳做法背道而驰这是使用外部验证服务器的最佳选择，因此我不主张这样做。）

收盘时

---

这些是我知道的攻击，如果我在任何一点上出错，请随时纠正我，或者提出其他攻击和修复

值得注意的是，有这样一个网站：该网站声称允许在iOS 5或越狱的iOS 6设备上免费进行应用内购买，并于2013年7月5日开始运行。虽然我不能100%确定他们是如何做到的，但它显然似乎涉及DNS重新路由和伪造安全证书，这意味着伪造应用商店或伪造验证证书ion Server，这还意味着仍然有一些应用程序不受th的保护