当前位置: 首页 > news >正文

iOS内购欺诈漏洞

iOS内购欺诈漏洞

  • 1.iOS内购欺诈漏洞概述
  • 2.伪造的凭证
  • 3.漏洞修复方案

1.iOS内购欺诈漏洞概述

黑产别的App上低价充值(比如1元)换取苹果真实凭证,再在目标App上下单高价(648元)商品,传入该凭证,如果目标App服务端苹果凭证校验接口存在漏洞,只校验了凭证中商品和订单信息,未校验凭证中App来源(bundleID),则会验证通过,进而发货

对黑产来说,黑产实际只支付了1元,就能买到目标App的648元商品;对于目标App来说,他连这1元都没得到(因为是在别的App上充的),完全被白嫖648元商品。可谓伤害极大

还原盗刷步骤:

  • 黑产通过破解(比如抓网络请求)目标App客户端,获得648元商品的苹果商品id(product_id)值。
  • 黑产自己上架一款App,在苹果后台添加一款1元的内购商品,设置苹果商品id(product_id)值和目标App一致。
  • 黑产在自己的App里真实付款1元商品,拿到苹果返回的真实凭据(receipt)和苹果交易id(transaction_id)。
  • 黑产破解目标App客户端后,直接调目标App的苹果凭证校验接口,把上面获得的凭据(receipt)和苹果交易id(transaction_id)作为参数传进去。
  • 目标App服务端拿着凭据去苹果后台校验,由于凭据是真实的,苹果验证通过。目标App服务端解析凭证,校验凭证内参数,核对product_id正确、核对transaction_id唯一性通过,全部校验通过,发货。

漏洞的主要原因:

  • 苹果后台,苹果商品id(不同开发者账号下)可以重复;
  • 目标App服务端凭证校验接口,未校验凭证中App来源(bundleID)。

2.伪造的凭证

下面是被攻击App服务端提供的一段日志,记录了“伪造的”凭证样式

  • 最外层的bundle_id,并不是目标App的包名,而是一个不认识的App包名。这个就是黑产真实充值的App。
  • in_app数组里面product_id,却是目标App里有效的苹果商品id,正是648元商品的product_id。
  • 再看transaction_id。这里的transaction_id实际上是黑产App内充值产生的,并不是目标App内产生的。因为transaction_id只有在苹果内购付款成功后才会生成,且只能由客户端传给服务端,所以服务端是没法校验transaction_id是否来源于自己的App。服务端能做的就是判断transaction_id是否重复,防止重放攻击。因为黑产每次充值都会真实的充一笔,所以transaction_id并不会重复,这也是目标App服务器验证transaction_id通过的原因。
{"receipt_type": "Production","adam_id": 6441231333,"app_item_id": 6441231333,"bundle_id": "com.apps.slanCaizhuang", //这并不是目标App的bundleID,而是黑产自己的的App"application_version": "3","download_id": 502222222222222222,"version_external_identifier": 855304439,"receipt_creation_date": "2023-04-12 16:59:25 Etc/GMT","receipt_creation_date_ms": "1681318765000","receipt_creation_date_pst": "2023-04-12 09:59:25 America/Los_Angeles","request_date": "2023-04-12 17:16:54 Etc/GMT","request_date_ms": "1681319814498","request_date_pst": "2023-04-12 10:16:54 America/Los_Angeles","original_purchase_date": "2023-03-11 05:00:05 Etc/GMT","original_purchase_date_ms": "1678510805000","original_purchase_date_pst": "2023-03-10 21:00:05 America/Los_Angeles","original_application_version": "3","in_app": [{"quantity": "1","product_id": "com.xiaomi.haha123", //这里却是目标App的product_id"transaction_id": "210000000000000",//黑产自己App上支付产生的transaction_id"original_transaction_id": "210000000000000","purchase_date": "2023-04-12 16:59:25 Etc/GMT","purchase_date_ms": "1681318765000","purchase_date_pst": "2023-04-12 09:59:25 America/Los_Angeles","original_purchase_date": "2023-04-12 16:59:25 Etc/GMT","original_purchase_date_ms": "1681318765000","original_purchase_date_pst": "2023-04-12 09:59:25 America/Los_Angeles","is_trial_period": "false","in_app_ownership_type": "PURCHASED"}],"environment": "Production","status": 0
}

3.漏洞修复方案

1、服务端凭证校验时,加上bundleID的校验即可

即服务端去苹果那边校验通过后,还需核对凭证内以下参数:

  • bundle_id,是否为你们自己的App(防止跨App充值);
  • product_id,是否为下单时对应的商品id(防止App内部以小博大);
  • transaction_id,是否已经发过货(防止重放攻击)

2、共享密钥(推荐)

服务端请求苹果凭证校验接口时,除了传receipt-data字段,再额外传一个password参数(苹果后台生成的共享密钥)。这样苹果那边核对凭证时,除了验证凭证是否有效,还会核对凭证和密钥是否匹配。如果不匹配苹果会返回错误信息

官方文档地址:https://developer.apple.com/documentation/appstorereceipts/requestbody?language=objc

http://www.lryc.cn/news/355605.html

相关文章:

  • 【网络服务】正向代理和反向代理到底是什么意思
  • 【算法】记忆化搜索
  • 博客系统多模块开发
  • pdf阅读器哪个好用?五款PDF阅读器大比拼
  • C#实现Queue的加锁和解锁
  • 北京邮电大学人工智能考数据结构,均分370!北京邮电大学计算机考研考情分析!
  • 1. lambda初体验
  • C#之显示转换
  • 汇编原理(三)编程
  • [MySQL数据库] Java的JDBC编程(MySQL数据库基础操作完结)
  • 绿色瓶装水“暗战”竞争越发激烈,华润饮料谋上市同时多地扩产能
  • C语言之指针详解(4)
  • 0基础学习小红书博主IP特训营,37天 教你从小白到KOL(13节)
  • 【openlayers系统学习】3.1-3.2彩色GeoTIFF图像渲染
  • 前端自动将 HTTP 请求升级为 HTTPS 请求
  • 辅助驾驶ADAS功能算法介绍
  • Docker 安装kingbase V8r6
  • Python 应用打包成 APK【全流程】
  • jmeter之MD5加密接口请求教程
  • R18 NTN中的RACH-less HO
  • QT使用gsoap获取手机归属地
  • 抖音本地生活服务商入驻指南分享!
  • 【量算分析工具-水平距离】GeoServer改造Springboot番外系列四
  • vs2019 c++20 规范的 STL 库的智能指针 shared、unique 、weak 及 make_** 函数的源码注释汇总,和几个结论
  • 【大模型】 基于AI和全球化进程的权衡:开源大模型与闭源大模型
  • 强化学习——学习笔记
  • NAT简介
  • 联想凌拓 NetApp AFF C250 全闪存存储助力丰田合成打造数据新“引擎”
  • 红队技巧:仿冒Windows登录
  • 821. 字符的最短距离 - 力扣