Google IAP 返回短购令牌以供验证

问题描述

限时删除！！

我已经实现了服务器端验证 Google IAP 购买令牌.我的移动应用程序将这个令牌发送给我，因为它是从 Google 获取的.

一个普通的令牌看起来像

minodojglppganfbiedlabed.AO-J1OyNtpooSraUdtKlZ_9gYs0o20ZF_0ryTNACmvaaaG5EwPX0hPruUdGbE3XejoXYCYzJA2xjjAxrDLFhmu9WC4fvTDNL-RDXCWjlHKpzLOigxCr1QhScXR8uXtX8R94iV6MM

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

korpimulxmslxissnschtkdb

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

问题出在哪里?这个短token有没有可能代表真实的交易?

解决方案

我一直在我们的应用程序中收到这些相同的无效令牌，但不知道是什么原因.令牌有多种格式，包括 24 个字母字符(例如 glvnqnpjqslcagyimgxeuybk)、15 个数字(例如 781871156762279、查看这个问题)，甚至是适当长度的令牌，其格式与有效令牌略有不同(例如.xdavcuvdnniwwrhwemleqjdz.rSQozm... 看到这个问题).

这些是我从 应用内结算 API 收到的错误消息一次或多次使用各种令牌:

• "code": 404, "message": "未找到购买令牌."
• "code": 400, "message": "无效值"
• "code": 400, "message": "您的请求对该订阅购买无效."

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

进行欺诈性购买

我在有根设备上测试了两个声称可以破解应用内购买的应用:Freedom 和 Lucky Patcher.前者不起作用:虽然它检测到我们的应用程序可以进行购买，但当我尝试制作一个假的时，它告诉我这个应用程序的购买不能被伪造".然而，后一个 确实 在经过一番摆弄之后工作，并生成了一个与问题完全相同的短期购买令牌.当我尝试通过 in-app billing API 验证令牌时，我收到了完全相同的像以前一样的无效令牌"消息.

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

攻击

我相信攻击的工作原理如下.对此有更多了解的朋友请多多指教！

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

缓解

• 完全依赖应用内计费服务的应用易受攻击！purchase 和 purchase validation 请求都被同一个欺诈应用拦截.没有防御.
• 依赖服务器后端的应用应将购买令牌发送到后端，以通过发布者 API 进行验证.这些应用不得在后端验证用户购买并向应用返回肯定结果之前将其归功于用户.后端可能应该遵循 安全建议 for In-应用计费.尽管这些应用会产生大量无效购买，但这些应用可能会更安全地防止欺诈性购买.
• 我认为依靠令牌的长度或格式、订单 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 返回短购令牌以供验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！

1403页，肝出来的..