Google IAP会返回简短的购买令牌以进行验证

时间:2015-07-14 09:17:00

标签: android in-app-purchase google-play in-app-billing

我已经实施了服务器端验证Google IAP购买代币。我的移动应用程序将此令牌发送给我,因为它来自Google。

常规令牌看起来像

minodojglppganfbiedlabed.AO-J1OyNtpooSraUdtKlZ_9gYs0o20ZF_0ryTNACmvaaaG5EwPX0hPruUdGbE3XejoXYCYzJA2xjjAxrDLFhmu9WC4fvTDNL-RDXCWjlHKpzLOigxCr1QhScXR8uXtX8R94iV6MmMHqD

但有时我会得到一个像这样的短标记

korpimulxmslxissnschtkdb

当我通过Google Play Developer API验证此令牌时:https://www.googleapis.com/androidpublisher/v2/applications/packageName/purchases/subscriptions/subscriptionId/tokens/token,对于短令牌,我收到404错误。

问题出在哪里?这个短令牌可能代表真实交易吗?

3 个答案:

答案 0 :(得分:38)

我一直在我们的应用程序中收到这些相同的无效令牌而不知道原因。令牌有各种格式,包括24个字母字符(例如glvnqnpjqslcagyimgxeuybk),15个数字(例如781871156762279see this question),甚至还有适当长度的令牌与有效格式不同的格式(例如xdavcuvdnniwwrhwemleqjdz.rSQozm... see this question)。

这些是我从in-app billing API收到的关于这些不同令牌的错误消息:

  • "code": 404, "message": "The purchase token was not found."
  • "code": 400, "message": "Invalid Value"
  • "code": 400, "message": "Your request is invalid for this subscription purchase."
Marc Greenstock给出的The answer给了我一个尝试重现这个问题的想法。

进行欺诈性购买

我在根设备上测试了两款声称可以破解应用内购买的应用:自由 Lucky Patcher 。前者不起作用:虽然它发现我们的应用程序可以购买,当我试图制作一个假的时,它告诉我“这个应用程序的购买不能伪造”。然而,后一个在一些摆弄之后工作,并且生成了与问题完全相同的简短购买令牌。当我尝试通过in-app billing API验证令牌时,我收到了与以前完全相同的“无效令牌”消息。

我还开始使用this method记录生成无效令牌的设备的根状态。虽然这不是任何事情的证据,但几乎所有无效令牌都源于有根设备这一事实让我怀疑犯规行为。

攻击

我认为攻击的工作原理如下。任何了解此事的人都请加入!

  • 用户安装其中一个声称可以在根设备上进行免费应用内购买的黑客应用
  • 黑客应用可以在设备上修补合法的应用内结算服务,也可以模拟它
  • 在购买流程中,黑客应用程序拦截了用于合法服务的purchase Intent
  • 黑客应用处理购买请求并以与合法服务相同的方式生成响应,但购买请求永远不会到达Google的服务器
  • 依赖于本地令牌验证的应用将从应用内结算服务请求购买。该请求也被黑客应用拦截,该应用宣称购买有效
  • 依赖于服务器令牌验证的应用程序将购买令牌发送到服务器,该服务器调用从未见过令牌的in-app billing API,因此返回“无效令牌“回复

缓解措施

  • 纯粹依赖于应用内结算服务的应用易受攻击购买购买验证请求均被相同的欺诈性应用拦截。没有防御。
  • 依赖服务器后端的应用应将购买令牌发送到后端,以通过发布商API进行验证。这些应用必须向购买者提供信用,直到后端验证并向应用返回肯定结果。后端应该遵循应用程序结算的security recommendations。这些应用程序可能比欺诈性购买更安全,但它们会产生大量无效购买。
  • 我认为依靠令牌,订单ID或其他数据的长度或格式来确定购买的有效性并不安全。这些令牌可能只是格式错误,因为它们模仿以前的格式。据推测,黑客应用程序的作者最终会发布一个版本来模仿Google关心设计的任何格式。唯一安全的方法是通过您控制的设备上的应用内结算API验证购买,即。服务器。

答案 1 :(得分:3)

你最终解决了这个问题吗?

我可以建议的唯一原因是该令牌是由应用内购买破解程序生成的,例如"自由应用内购买Android和#34;可以在root设备上安装的应用程序。

我有兴趣看看您是否收到过您自己进行的任何测试购买的简短令牌。

令牌是假的另一个迹象是您在应用程序上购买后获得的orderId的格式。

如果它没有遵循Administering In-app Billing文档中指明的格式,那么它很可能是欺诈性购买。

答案 2 :(得分:0)

我发现部分缓解适用于某些假IAP提供商:手动重新检查数字签名。无论IAP模拟器做什么,他们都没有Google私有RSA密钥的副本。我推出了自己的签名支票,它至少捕获了一些虚假交易。

https://stackoverflow.com/a/32494079/2264534