Google IAP返回短期购买令牌进行验证 [英] Google IAP returns short purchase token for verification

问题描述

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

问题在哪里？是否有可能这个短的标记代表真正的交易？ 解决方案

我在我们的应用程序中收到了这些相同的无效标记，一段时间的原因。这些令牌有各种格式，包括24个字母字符（例如 glvnqnpjqslcagyimgxeuybk ），15个数字（例如 781871156762279 ，看到这个问题），甚至适当长度的标记与有效标记格式略有不同（例如 xdavcuvdnniwwrhwemleqjdz.rSQozm ... 查看此问题）。

这些是我从应用内结算API 为这些不同的令牌提供一次或另一次：

• 代码：404，message：购买令牌未找到。


• code：400， ：无效值


• code：400，message：您的请求对此订阅无效。

由Marc Greenstock给出的答案给了我一个尝试重现问题的想法。

进行欺诈性购买

我测试了两款声称破解应用内购买的应用： Freedom 和 Lucky Patcher 。前者无效：虽然它发现我们的应用程序可以进行购买，但当我试图制作一个虚假的应用程序时，它告诉我该应用程序的购买行为不能被伪造。然而，后一个确实 工作正常，并且与问题中一样产生了一个短的购买标记。当我尝试通过应用内结算API 验证令牌时，我收到了同样的确切信息无效令牌消息像以前一样。 我还开始使用此方法记录生成无效令牌的设备的根状态。虽然这并不能证明任何事情，但几乎所有的无效令牌都来自根源设备，这让我怀疑是犯规。

攻击

我相信这次攻击的效果如下。任何知道更多此类信息的人都可以参加！

• 用户安装了一个声称可以免费购买应用程序的黑客应用程序黑客应用程序或者在设备上修补合法的应用内结算服务或者模拟它


• 在购买流程中，黑客应用拦截购买 Intent

• 黑客应用程序处理购买请求，并以与合法服务相同的方式生成响应，但购买请求从未达到Google的服务器


• 依赖本地令牌验证的应用程序将请求从应用内结算服务处购买产品。此请求也被黑客应用拦截，该应用宣称该购买有效


• 依靠 server 标记验证的应用将购买令牌发送给服务器，它致电应用内结算API ，该表单从未见过该令牌，并因此返回无效令牌响应

缓解

• 纯粹依靠应用内结算服务的应用易受攻击！ 购买和购买验证请求都被同一欺诈性应用拦截。没有防御。


• 依赖服务器后端的应用程序应将购买令牌发送到后端，以通过发布者API进行验证。这些应用程序必须不向用户购买，直到后端验证并向应用程序返回肯定结果为止。后端应该遵循安全建议，应用帐单。这些应用程序可能从欺诈购买中更安全，但它们会产生大量无效购买。


• 我不认为依靠令牌的长度或格式是安全的， ID或用于确定购买的有效性的其他数据。这些令牌可能只是格式错误，因为它们正在模拟以前的格式。据推测，黑客应用程序的作者最终将发布一个版本来模仿谷歌关心的任何格式。唯一安全的方法是通过您控制的设备上的应用内结算API来验证购买，即。一台服务器。

I have implemented server-side verification Google IAP purchase tokens. My mobile app send me this token as get it from Google.

A regular token looks like

minodojglppganfbiedlabed.AO-J1OyNtpooSraUdtKlZ_9gYs0o20ZF_0ryTNACmvaaaG5EwPX0hPruUdGbE3XejoXYCYzJA2xjjAxrDLFhmu9WC4fvTDNL-RDXCWjlHKpzLOigxCr1QhScXR8uXtX8R94iV6MmMHqD

but sometimes I get a short token like this

korpimulxmslxissnschtkdb

When I verify this token via Google Play Developer API: https://www.googleapis.com/androidpublisher/v2/applications/packageName/purchases/subscriptions/subscriptionId/tokens/token, for the short token I get a 404 error.

Where is the problem? Is it possible that this short token represents real transactions?

解决方案

I have been receiving these same invalid tokens in our app with no idea of the reason for a while. The tokens have come in various formats, including 24 alpha characters (eg. glvnqnpjqslcagyimgxeuybk), 15 digits (eg. 781871156762279, see this question), and even tokens of proper length that have a slightly different format from valid ones (eg. xdavcuvdnniwwrhwemleqjdz.rSQozm... see this question).

These are the error messages I have received from the in-app billing API for these various tokens at one time or another:

• "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."

The answer given by Marc Greenstock gave me an idea to try to reproduce the issue.

Making a fraudulent purchase

I tested two apps that claim to hack in-app purchases: Freedom, and Lucky Patcher, on a rooted device. The former did not work: though it detected that our app can make purchases, when I tried to make a fake one it told me that "this app's purchases cannot be faked". The latter one did work after some fiddling, however, and generated a short purchase token exactly as in the question. When I tried to verify the token via the in-app billing API, I received the same exact "invalid token" message as before.

I also started logging the root status of devices generating invalid tokens using this method. While this is not proof of anything, the fact that nearly all invalid tokens originated from rooted devices made me suspect foul play.

The attack

I believe the attack works as follows. Anyone who knows more about this please chime in!

• User installs one of the hacking apps that claims to make free in-app purchases onto a rooted device
• The hacking app either patches the legitimate In-App Billing Service on the device, or emulates it
• During a purchase flow the hacking app intercepts the purchase Intent which is meant for the legitimate service
• The hacking app processes the purchase request and generates a response the same way the legitimate service would, but the purchase request never reaches Google's servers
• An app that relies on local token validation will request purchases from the In-App Billing Service. This request is also intercepted by the hacking app, which claims that the purchase is valid
• An app that relies on server token validation sends the purchase token to a server, which makes a call to the in-app billing API, which has never seen the token, and therefore returns an "invalid token" response

Mitigation

• Apps that rely purely on the In-App Billing Service are vulnerable! The purchase and the purchase validation requests are both intercepted by the same fraudulent app. There is no defense.
• Apps that rely on a server backend should send the purchase token to the backend to be verified through the publisher API. These apps must not credit the user with the purchase until the backend verifies it and returns a positive result to the app. The backend should probably follow the security recommendations for In-App Billing. These apps are probably safer from fraudulent purchases, though they generate a lot of invalid purchases.
• I don't think that it is safe to rely on the length or format of the token, order id, or other data for determining validity of the purchase. These tokens are probably only malformed because they were emulating a previous format. Presumably the authors of the hacking app will eventually release a version to emulate any format that Google cares to devise. The only safe means is to verify the purchase via the in-app billing API on a device that you control, ie. a server.

这篇关于Google IAP返回短期购买令牌进行验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！