为什么使用应用内结算设置开发人员有效负载很重要？

Question

我正在使用应用内结算API的第3版.我有一个单独的,管理的,非消耗品.我还没有在我的应用程序中发布此功能,所以我想在购买之前决定购买有效负载内容.

来自"安全最佳实践":

在发出购买请求时设置开发者有效负载字符串

使用应用内结算版本3 API,您可以在向Google Play发送购买请求时添加"开发人员有效负载"字符串令牌.通常,这用于传递唯一标识此购买请求的字符串标记.如果您指定字符串值,Google Play会将此字符串与购买回复一起返回.随后,当您对此次购买进行查询时,Google Play会将此字符串与购买详细信息一起返回.

您应该传入一个字符串令牌,以帮助您的应用程序识别进行购买的用户,以便您以后可以验证这是该用户的合法购买.对于消耗品,您可以使用随机生成的字符串,但对于非消耗品,您应使用唯一标识用户的字符串.

当您从Google Play获得回复时,请确保验证开发人员有效内容字符串是否与之前使用购买请求发送的令牌相匹配.作为进一步的安全预防措施,您应该在自己的安全服务器上执行验证.

无论是对还是错,我决定不采取"进一步的安全预防措施"来设置服务器来执行购买验证.而且我没有存储我自己的购买记录 - 我总是称之为计费API.那么我真的有理由进行有效负载验证吗？验证API本身肯定会在报告购买项目之前验证用户的身份,如果攻击者已经破坏了设备(应用程序或Google Play API),我认为没有任何额外检查的好处用户在设备上识别可以轻易绕过的地方.或者有没有理由这样做,我没想到？

Answer 1

如果您没有保留记录,则无法验证您获得的是您发送的内容.因此,如果您向开发人员有效负载添加内容,您可以信任它是合法的(如果签名验证,这是一个合理的假设),或者不完全信任它并且仅将其用作引用,而不是用于验证许可证状态等例如,如果您存储用户电子邮件,则可以使用该值而不是要求他们再次输入该值,这稍微用户友好,但如果不存在,您的应用程序将不会中断.

就个人而言,我认为这整个"最佳实践"部分令人困惑,并且正在努力让您做到API应该真正做的工作.由于购买与Google帐户相关联,Play商店显然会保存此信息,因此他们应该在购买详细信息中向您提供此信息.获取正确的用户ID需要额外的权限,您不需要添加这些权限只是为了弥补IAB API的不足.

因此,简而言之,除非您拥有自己的服务器和特殊的附加逻辑,否则不要使用开发人员有效负载.你应该没问题,只要IAB v3 API能够工作(不幸的是,在这一点上非常大'如果').

Answer 2

您应该传入一个字符串标记,以帮助您的应用程序识别进行购买的用户...

如果您的应用程序提供了自己的用户登录名和身份,这与手机连接的Google帐户不同,那么您需要使用开发人员有效负载将购买附加到您购买的某个帐户.否则,有人可以在您的应用中切换帐户,并获得购买的东西的好处.

例如

假设我们的应用程序已登录userA和userB.手机的Android谷歌帐户是X.

1. userA,登录我们的应用程序并购买终身会员资格.购买详细信息存储在Google帐户X下.
2. userA注销,userB登录到我们的应用程序.现在,userB也获得了终身会员的好处,因为Android谷歌帐户仍然是X.

为避免此类滥用,我们会将购买与帐户绑定.在上面的示例中,我们将在userA进行购买时将开发人员有效负载设置为"userA".因此,当userB登录时,有效负载将与登录用户(userB)不匹配,我们将忽略购买.因此,userB无法获得userA完成购买的好处.

Answer 3

开发人员有效负载处理还有另一种方法.正如Nikolay Elenkov所说,要求用户ID并为用户配置文件设置其他权限是太多的开销,所以这不是一个好方法.因此,让我们看看谷歌在In-App Billing v3样本的最新版TrivialDrive示例应用程序中所说的内容:

• 警告:在开始购买时本地生成随机字符串并在此处进行验证似乎是一种好方法,但如果用户在一台设备上购买商品然后在其他设备上使用您的应用,则会失败,因为在您无法访问其他设备最初生成的随机字符串.

因此,如果您要在另一台设备上验证购买的商品,随机字符串不是一个好主意,但他们仍然没有说这不是验证购买响应的好主意.我会说 - 仅使用开发人员有效负载通过发送随机唯一字符串来验证购买,将其保存在首选项/数据库中,并在购买响应中检查此开发人员有效负载.至于在Activity start上查询库存(应用程序内购买) - 不要费心检查开发者有效负载,因为这可能发生在你没有存储随机唯一字符串的另一台设备上.这就是我看到它的方式.

Answer 4

这取决于你如何验证developerPayload.有两种情况:远程验证(使用服务器)和本地(在设备上).

服务器

如果您使用服务器进行developerPayload验证,它可以是任意字符串,可以在设备和服务器上轻松计算.您应该能够识别执行请求的用户.假设每个用户都有相应的accountId,developerPayload可以计算为与purchaseId(SKU名称)的组合,如下所示:

MD5(purchaseId + accountId)

设备

developerPayload 不应该是用户电子邮件.不应将电子邮件用作有效负载的一个很好的示例是Google for Work服务.用户可以更改与该帐户关联的电子邮件.唯一不变的是accountId.在大多数情况下,电子邮件都可以(例如,Gmail地址目前是不可变的),但请记住为将来设计.

多个用户可能使用同一设备,因此您必须能够区分谁是该项目的所有者.对于设备验证,developerPayload是一个唯一标识用户的字符串,例如:

MD5(purchaseId + accountId)

结论

一般developerPayload情况下,两种情况都可能只是accountId.对我来说,通过默默无闻看起来像安全.MD5(或其他散列算法)purchaseId只是一种使有效负载更加随机的方法,而无需明确显示我们正在使用帐户的ID.攻击者必须反编译应用程序以检查其计算方式.如果应用程序被混淆得更好.

有效负载不提供任何安全性.它可以通过"设备"方法轻松欺骗,并且无需在"服务器"检查中查找.请务必使用Google发布商帐户控制台中提供的公钥实施签名检查.

*关于使用帐户ID而不是电子邮件的必读博客文章.

Answer 5

在关于IAB v3的谷歌IO视频中,由琐碎的驱动器样本的作者自己给出,这是在视频结束时简要说明的.这是为了防止重放攻击,例如攻击者嗅探流量,窃取包含成功购买的数据包,然后尝试在自己的设备上重播数据包.如果您的应用在发布优质内容(最好是来自您的服务器)之前未通过dev有效负载(最好是在您的服务器上)检查买方的身份,则攻击者将成功.由于数据包完好无损,签名验证无法检测到此情况.

在我看来,这种保护似乎非常适合具有在线帐户连接的应用程序,如部落冲突(有效载荷自然而然,因为你必须识别用户),特别是在黑客入侵多人游戏玩法时,除了简单的本地化盗版案例.相比之下,如果apk上的客户端黑客已经解锁了高级内容,那么这种保护就不是很有用了.

(如果攻击者试图欺骗有效载荷,则签名验证应该失败).

Answer 6

2018 年末更新：官方 Google Play 计费库故意不公开developerPayload. 从这里：

字段 developerPayload 是一个遗留字段，保持与旧实现的兼容性，但如购买应用内计费产品页面（https://developer.android.com/training/in-app-billing/purchase-iab）所述-products.html )，在完成与应用内结算相关的任务时，此字段并不总是可用。由于该库旨在代表最新的开发模型，我们决定在我们的实现中不支持 developerPayload，我们也没有计划将此字段包含到库中。

如果您依赖 developerPayload 上的应用内计费逻辑的任何重要实现，我们建议您更改此方法，因为此字段将在某个时候（或很快）被弃用。推荐的方法是使用您自己的后端来验证和跟踪有关您的订单的重要详细信息。有关更多详细信息，请查看安全和设计页面 ( https://developer.android.com/google/play/billing/billing_best_practices.html )。