浅析电商优惠券中的漏洞点

前言

简单记录一下个人近期状况,近两三个月都在忙活秋招的事情,基础方面是查缺补漏了不少,内网这块也学到了不少理论知识。但个人在新奇的思路并没有扩宽多少,骚姿势也没领悟多少。
在暑期实习时做的是SRC渗透测试的活,每天都是对着网站一把梭,感觉即使是逻辑漏洞也都是机械性的工作,内心对此排斥了好久,几乎两个多月没碰过。前不久跟大佬聊天,被教导了一遍,他又跟我说了很多骚姿势,现在就想从中结合自己的理解,与网上的资料,写一份记录。
优惠券最主要的功能是以发放优惠的形式进行营销,但商家需要把握“优惠”的度,不然容易被买家赚便宜。此消彼长,就是商家亏了,直接牵扯到金钱利益,一般这种漏洞都能评高中危。
优惠券安全涉及到太多方面了,而且很多从代码层面难以发现,身边的老师傅们总能一眼看出是否存在漏洞,而我这个小菜鸡只能看大佬表演,顺便偷点师维持一下生活。

优惠券的设计模型

从开发者角度分析一下优惠券中的设计理念与属性。

首先是优惠券类型:
– 无门槛优惠券
– 满减优惠券
– 折扣优惠券
– 会员专属折扣卡

优惠券状态:
– 未领取
– 待使用/待回滚
– 已过期
– 锁定(下单中状态)
– 已使用

优惠券使用范围:
– 跨店/门店专属/参与活动商家
– 全商品/优惠商品不可用
– 专属平台,如app
– 指定时间段使用

优惠券数据库设计:
– 优惠券id
– 用户id
– 优惠券model
– 失效时间
– 起始时间
– 使用规则
– 优惠力度
– 使用范围

某电商cms优惠券数据库属性建模

某电商cms优惠券后台处理相关方法

高并发/重复请求利用

漏洞简述:一张优惠券可多次使用。

假设场景:在商城选择任意物品“使用优惠券”,在付款页面取消支付,一般该订单状态将自动成为“待支付”,同时该优惠券将被“锁定”,只有在取消该订单的情况下才会释放该优惠券。

检测方法:利用fiddler将“提交订单”步骤的请求包截获,设置好高并发请求,要是能生成多笔使用优惠券的“待支付订单”,则一张优惠券可多用。

整体流程图

后端处理逻辑图

漏洞分析:攻击者利用后端“更新优惠券状态”的时间差,利用高并发请求进行条件竞争,生成多笔使用了优惠券的订单。或后端无校验,只在前端有限制。

优惠券冒用

漏洞简述:可使用“未获得”的优惠券。

假设场景:在商城选择任意物品“使用优惠券”,使用burpsuite抓包,查看其中含coupon_id等优惠券参数,删除该参数将生成无优惠订单,或随意修改将报错。

检测方法:首先需要测试一下是否能越权使用优惠券,如注册两个账号,尝试在A账号使用B账号的优惠券,即修改参数中的coupon_id等字眼,若后端没有对优惠券与用户的对应关系进行校验,可能导致冒用。若优惠券ID的生成规则过于简单,有迹可循,如xxx系列优惠券的ID码均在某个范围内,可尝试批量跑爆破冒用优惠券。

整体流程图

后端处理逻辑图

漏洞分析:对比上一个漏洞,缺少了对“优惠券与用户绑定关系”的校验,从而与一般的越权漏洞无异。但此时还要靠猜测他人的优惠券ID才能进行利用,略显鸡肋。可以尝试破解优惠券ID的生成算法,有可能是简单的递归。

新旧/跨平台同步差

这种漏洞是老师傅告诉我的,我还没试过(想过)。

漏洞简述:优惠券在不同平台上的coupon_id不一致,导致同一张优惠券可使用多次。

假设场景:某电商提供app、web、小程序页面,账户信息均同步,如在app端领取了优惠券可在web端使用。

检测方法:逆向app,找到缓存在本地的信息,如安卓手机中优惠券ID等信息一般会缓存在本地。在web端下单,抓包对比二者ID是否一致。若二者不一致,由于还是同一张优惠券,可分别构造表单提交测试。若能成功下单,则存在优惠券复用漏洞。

整体流程图

后端处理逻辑图

漏洞分析:首先不同平台使用的是不同的系统,数据库不是同一个,同步可能有时间差(A平台使用后B同步“已使用”状态),且初始化优惠券可能参数不一样,导致生成的优惠券ID也不一样。

大佬跟我说,不同平台系统极有可能不是同一套系统,而且很有可能还是不同开发组在管理,所以很多信息不太可能完全一致。新旧平台是数据库迁移过于困难的问题,如果旧平台未关闭且信息“同步”,也大概率会出现这漏洞。但我还没遇上这种情况,只能说太小白了,也不知道细节是否是这样。(此环节纯靠聊天脑补)

薅羊毛之满减

漏洞简述:使用优惠券,购买其他页面的商品,使商品满减至极低价格。

假设场景:某店铺发送大额优惠券,如“满30-25”。存在主店铺A,旗下商品页面Aa,Ab等。

检测方法:店铺页面A发放满减优惠券,页面有多款产品,价格比较高,使用了优惠券后价格合理。但我们往上爬,如该店铺除了A页面商品,还发布B页面商品,该页面商品价格比较低,使用A页面的优惠券能成功下单。

整体流程图

后端处理逻辑图

漏洞分析:大佬跟我说这是一个“作用范围”的问题,很多情况下可概括为商家设置了一批参与活动与另一批不参与活动的商品,但错误设置了优惠券根据商家来判断该订单是否可用。所以把未参与活动的商品与优惠券一起提交,后台只检验该商品所属店铺与优惠券的关系,导致订单成立。

可能出现漏洞的场景:
– 页面活动结束后商品下调价格,但优惠券未过期
– 商品在旧页面上架,而不是另起新页面

极限满减

该情况与上一个漏洞有很多共同点,检测方法也类似。

漏洞简述:对于已经打折的商品使用优惠券。

假设场景:店铺设置了两种商品,一种高价可参与各种活动,另一种价格较优惠但无其他优惠活动。

检测方法:这类商品一般不会在同一个商家售卖页面里找到,找主体相同但店铺,如A店铺和B店铺都是XXX创立的,在某些优惠券里是通用的。通过对低价无活动商品使用优惠券,查看是否生成订单。

整体流程图和后端处理逻辑图与上基本相同,只简单判断了优惠券在该商铺是否可用。

漏洞分析:商品设置了“原价”,“活动价/实际支付价”等属性,在“该笔订单价格是否符合优惠券使用条件”时使用的是商品原价进行计算,而在计算实际支付价时,用了商品的活动价。

结尾

本人见识短浅,感觉在本文中的几个漏洞也没有完全领悟其中的原理。但通过不断地搜集与交流,也算略知一二,总结起来就是“以开发者的思维推测”,如怎么设置优惠券这问题,是一个一个商品的添加(较安全,相对而言几乎无漏洞)还是直接页面商品添加(页面重用)甚至整个店铺所有商品(优惠券混用)都添加到可使用范围内,商家又会不会误操作等。

希望能挖到一个真实案例,不再纸上谈兵。

发表评论

电子邮件地址不会被公开。 必填项已用*标注