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

cer*_*kjn 32 android in-app-purchase in-app-billing google-play

我已经实施了服务器端验证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错误.

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

sav*_*nto 43

我一直在我们的应用程序中收到这些相同的无效令牌,不知道原因有一段时间.令牌有各种格式,包括24个字母字符(例如glvnqnpjqslcagyimgxeuybk),15个数字(例如781871156762279,看到这个问题),甚至是适当长度的标记,其格式与有效格式略有不同(例如,xdavcuvdnniwwrhwemleqjdz.rSQozm... 请参阅此问题) .

以下是我从应用内结算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给出的答案给了我一个想法,试图重现这个问题.

进行欺诈性购买

我测试了两个声称在应用程序内购买的应用程序:FreedomLucky Patcher,在root设备上.前者不起作用:虽然它发现我们的应用程序可以购买,当我试图制作一个假的时,它告诉我"这个应用程序的购买不能伪造".然而,后者在一些摆弄之后确实起作用,并且产生了与问题完全相同的短购买令牌.当我尝试通过应用内结算API验证令牌时,我收到了与以前完全相同的"无效令牌"消息.

我还开始使用此方法记录生成无效令牌的设备的根状态.虽然这不是任何事情的证据,但几乎所有无效令牌都来自有根设备的事实让我怀疑犯规.

攻击

我相信攻击的工作原理如下.任何了解此事的人都请加入!

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

减轻

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