业务逻辑漏洞探索之活动类漏洞

本文中提供的例子均来自网络已公开测试的例子，仅供参考。

很多平台都会通过参与活动类赢取奖励的功能的方式来吸引用户或是使用资金、虚拟货币、积分等进行交易，然而如果这些功能没有设计好，很容易造成重大的利益损失。例如年初拼多多被爆100元无门槛优惠券漏洞就使拼多多遭受一定量的损失。

我们测试的时候可以分为以下几种测试场景进行测试：

一.重放攻击

重放攻击是指攻击者发送一个目的主机已接收过的包，来达到欺骗系统的目的。在交易活动类功能里，除了进行简单的重放攻击进行获利外，对于大量的请求同时发起时，如果没有进行很好的处理，那就可额能存在条件竞争漏洞。

1.  无限获利

举个栗子：

a) . 某地方运营商举办让红包飞活动，中奖后可活动使用码兑换奖品。

b). 还未兑换前的流量。

b). 还未兑换前的流量。

d). 可成功兑换流量。

e) .抓取兑换流量的数据包进行重放可无限次兑换流量。

2. 条件竞争

举个栗子

a). 某App 推出了新人领红包活动，新号可以免费领一次红包，使用抓包工具进行抓取领红包的数据包。

b) .然后同时并发多个数据包。

c). 由于没有做好大量并发请求的处理，可同时领到多个红包。

二. 数据篡改

在交易活动类功能中，经常会涉及买卖、转账或者是兑换涉及资金、虚拟币、积分等，需要注意防范通过参数篡改进行非法获利。常见的两种篡改方式分别为金额篡改和数量篡改。在测试过程要注意交易、兑换过程中的商品单价、商品总价是否可以突破极限改为0、1、负数，尝试对金额进行篡改；在兑换过程中也要注意对数量参数的测试，尝试是否可免费或较低金额兑换大量积分、虚拟币等。

1.  金额篡改

举个栗子：

a) . 某旅游网站的机票购买功能存在任意金额购买漏洞。

b). 搜索国际航班。

c). 选择一班机票进行购买，此时可看见金额至少为1778。

d). 提交购买订单。

e).  使用抓包工具进行抓包，可发现数据包中的totalPrice是机票价格。

f) . 将机票价格修改为0.01，发现可以用0.01的价格购买任意机票。

2.  数量篡改
(1)将数量改大。
a). 某APP可进行签到抽奖获得阅币（50阅币相当于1块钱）
b). 首先得到自己手机签到和抽奖时候的链接，下次可以直接用浏览器访问链接签到、抽奖。抽奖时候的连接类似这样的（XXX是替代字符）：
http://xxx.xxx/zyb*k/u/p/user.p ... 27XXXX74&p2=108
c). 抽奖过程是由js控制的，结果已经设定好了是6，就是会抽到6个阅币，是由count这个变量定义的。只要用浏览器打开，修改这个变量即可。

d). 这个变量应该是在上一步的时候生成的链接定义的，从链接中的变量传递过来，所以可以直接访问链接：
http://xxx.xxxx/zybook/u/p/user. ... 5&p1=1307271227

e). 注意，里面的price=5100表示这一次将抽到5100阅币，设置多少得多少，目前测试7位数可行。

(2)将数量改为负数。

举个栗子：

a). 使用某购物网站进行购物，选取商品后进行抓包。

b). 修改数量为-1。

c). 网站里出现未支付订单，发现金额显示-299。

d). 直接点击付款，发现可以付款成功。

e). 可发现余额增多。

三. 流程绕过

客户端测试活动业务是否存在漏洞，能否在未满足活动参与条件的情况下参与活动或获得收益常见的客户端验证方法。常见的活动限制绕过有两种，一种是次数限制绕过，一种是时间限制绕过。
1. 次数限制绕过
举个栗子：
a). 登入活动页面输入兑换码就可以兑换省内100M流量，当第二次输入同一个兑换码的时候会显示已兑换。

b). 查看历史找到了兑换的网页可以跳过限制直接再次兑换
地址:http://xxx.xxx/xxxx/web/info2.jsp?coupon=2&PrizeID=兑换码

c). 又发现兑换码只是个摆设，可以直接输入利用上面地址。输入11位数或英文大写字母就又可以兑换。

d). 后来继续查看那个地址发现info2.jsp是二等奖的页面，改成info1.jsp，就是一等奖的领奖页面。

2. 时间限制绕过
a). 某站举办活动，有个摇奖机，摇一次之后需要在下一个小时才能摇奖。

b). 发现抽奖的验证放在前端，只是通过禁用抽奖按钮控制抽奖。将抽奖的方法搬到“查看中奖名单”的onclick下，每次点击“查看中间名单”就可以触发摇奖机摇奖。

四. 修复建议

以上就是对活动类漏洞的归类啦，如果你也有别的归纳也可以和一起探讨探讨哦，以下就是对于交易活动类漏洞修复的一点建议：
1. 交易类业务应充分考虑业务风险，应充分考虑流程和数据的防泄密、防篡改、防重放等安全问题。
2. 交易类业务的关键参数，如单价、金额等关键参数必须在服务端生成或进行二次校验，不得直接使用用户可控数据。
3. 活动类功能所有验证及限制都应在服务端，不应相信客

户端提交的信息。
好啦，到这篇为止业务逻辑漏洞的归纳就告一段落啦也会继续学习，你们如果对于业务逻辑漏洞也有研究的话，快快来告诉我们一起学习学习。

本文始发于微信公众号（疯猫网络）：业务逻辑漏洞探索之活动类漏洞