业务逻辑漏洞挖掘由于程序逻辑不严格或逻辑过于复杂，导致某些逻辑分支处理不成功或错误得到处理。 统称为业务逻辑漏洞
JSRC安全小教室第125期，邀请月神担任讲师，与大家分享如何用技术手段挖掘业务逻辑漏洞。 感谢伙伴们精彩的讨论。
京安小妹：业务逻辑漏洞经常发生在哪里？
月神：
细说起来，哪里都可以在发生位置。
每种类型的APP都有自己的常见漏洞位置。
例如购买、销售、各合同的重要参数。
京安小妹：业务逻辑漏洞分类？
月神：
本文中的特定值是指存储在系统中的数据为int整数类型时。 最大值/单价1是特定值。 如果数量超过特定值，则从0开始计算
另一方面，饮料售货机在更换订单ID、制作订单时，在支付画面上，在此制作订单交换订单ID (高价交换低价) ) )。
创建无限新用户优惠订单、重复优惠订单
交换卷ID (未达到条件的使用) ) ) ) ) ) )。
如果单个案例的订单数为1.99，则客户端只支付了1元，实际上服务器认为支付了2元。
在收到商品的同时(实际情况) )。
二.直播快速出入房间爆破室
好耶无限发送协议
修改礼物的数量、0、小数、负值和特定值(一般为1073741824 )。
修改礼物ID，看看有没有隐藏ID。
赠送礼物，抽签
初次折扣订单无限期制作。 部分初次折扣订单为特殊pid，直接更换此pid进行支付。 有些是相同的ID，在创建这样的预订单，并记录多个订单编号以顺序修改订单支付。
刷屏：发言有刷屏、共享、点赞等提示的地方用刷屏
在房间里可以申请的地方进行申请取消操作，看看能否炸毁房间。
踢人、增加管理员、关闭房间等操作。
的表情能否纵横修正(实际情况)。
三、购物app购买数量： 0、小数、负、正负(a为-1，b为2，总值为1 ) )。
金卷：平行收、横移收，重复使用同一个金卷，不符合条件使用金卷
越权：登录，操作他人订单，修改资料
四、外卖商品数量、0、负、小数、特定值、正负(a为-1，b为2，合计值为1 ) ) ) ) ) )。
送货员的评价修正、星级、奖金额(小数、负) ) )。
商品评价、星级、评论字数、上传的图片是否可以定制格式、
订单超过了送货地点
强行货到付款，取消订单，退款
操作别人的订单登录
优惠购买会员(再利用优惠购买) ) ) )。
五、交易平台钱包同时取现，取负现金
使用钱包支付时同时支付多个订单(支付金额是否大于余额) ) ) ) ) ) ) ) ) )。
转账负数，同时转账
陈列商品突破数量、字数等限制。
交换订单，制作订单编号。 如果订单状态可以修改，请进入支付界面，将订单修改为更大的金额，并支付给预先输入的支付界面
数量修正
六、社会强制举报(如读取上传当地信息) )。
强制添加朋友(通常是尝试重新发送朋友协议) )。
自由修改号码(靓太) ) ) ) ) )。
组管理无限禁言
禁止越权，代人打黑
会员修改金额、数量。 无限制的折扣购买
非会员使用会员功能
七.漫画
奖金金额为负、小数、特定值(溢出)
删除评论并登录
修改充值金额
收费漫画免费阅读
评论图片的数量过多会导致客户端加载卡死亡
八、音乐歌曲类软件修改上传分数等参数
付费下载尝试替换下载ID
修改付费下载金额
确认是否有F12首歌的地址
九、网络订车无限叫车，反复发送协议扰乱市场
修正评价分数
修改限时甩卖称为车关键参数
更换优惠卷
越权操作其他订单
京安小妹：挖掘业务逻辑漏洞的构想？
月神：
你可能会想到奇怪的逻辑，杀死很多APP。 (我用简单的支付逻辑在四个SRC的每个大厅里掩盖了高危。 )所以，逻辑漏洞看起来很简单，但如果奇怪的话就可以杀了。 我的挖掘思路是拿到包后，先随便测量，通过登录、资料回顾等简单功能，挖到低危险是没问题的，挖是对自己有信心，不会白挖。
然后，在完成一次简单的功能后，开始细化各功能。 例如，先看看容易出现像支付这样的高危重症的地方，试着通过自己积累的想法，比如先充值一些钱，然后提取现金。 或者充值5元后，5元同时支付多个5元订单，这比其他支付漏洞的出现率还多。 最重要的是考虑别人想不到的事情。 如果是fzdmp，请学习常见的想法，自己找网站来
测试，我给的建议就是别学太多，入门就行，剩下的自己在实践中悟，这样就不会被常识束缚住。不然挖逻辑漏洞时太容易就被已经掌握的常识所束缚了。没去尝试过的东西永远别说不可能，上学的时候微X刚出，资料只能改30个字，那时候我刚教我朋友使用手机上的内存修改器，我们平时没事就找些网游刷一下，那天朋友突然和我说微X资料可以改内存把长度提升到100字。我第一反应是不可能，改了肯定没用，是不是你刚学不会改看错了。结果还真是能改。
从那以后我就告诉自己，别说不可能，没啥不可能的，出问题了第一反应不是否认，而是站在对方的角度去想，怎么复现这个漏洞。以前在第三方平台做游戏防外挂，由于游戏是代理的，很多时候看不到玩家的数据。玩家出现作弊后，开发通知到我这边，我这边只能猜测漏洞如何出现，大多数都是用目前已经掌握的知识就能猜的八九不离十了。但是只有一次我印象最深，那时候刚出了一款游戏，XX农药刷符文，大家都在玩，于是我也跟风玩了起来，然后在破解群出现了商人，代刷符文，听到刷符文，第一反应就是负数溢出了，但是如何尝试负溢出都不行（那个时候思路不是特别多，溢出只知道修改负数）机缘巧合下，那天我接触到了正数溢出，在游戏里面通常最大数值就是2147483647，那么正溢出就是假如商品单价为2，那么我要做到的就是2*数量>2147483647，假如买1073741825个*2就是2147483650，在游戏中由于超出了最大值，总价格就会变成了3（超出后从0开始计算），于是去尝试了一下，果然是这样，经过计算后，成功刷到了符文箱。
所以一定要勇于尝试，丰富各种各样的奇葩思路
京安小妹:业务逻辑漏洞的案例分析
月神：
一、
先来讲一个某外卖平台订餐的软件吧，我和朋友说我把这个软件订餐的数量改了，改成了负数结果成功了，然后他表示他尝试过并没有成功。同样是负数为什么没有成功呢？我一开始的思路也是将其修改为负数，在点几个正数的保证达到送餐的数量。但是服务器有校验，单个金额和总体金额不能为负数，你们想一下，这样看起来就很完美了，于是我一直思考有没有什么逻辑是被我疏忽掉的呢。想了半小时终于想出来了。参数大概是这样的
{"total_price":"21.04","products":[{"cart_id":"0","product_id":"277976516634","product_quantity":1,"product_name":"芝麻糖饼","activity_num":1,"dish_activity":1,"cart_type":"cater"},{"cart_id":"0","product_id":"203689622554","product_quantity":2,"product_name":"鲜汁肉包(2个)"}]}我们来看一下，其中有商品ID，单价，数量，活动优惠数量，总价，数量价格总价对不上都不让下单，看起来环环相扣，于是我尝试了将商品ID都改为同样了，数量这里一个为正一个为负，也就是这样的：
{"total_price":"XXX","products":[{"cart_id":"0","product_id":"277976516634","product_quantity":-1,"product_name":"芝麻酱糖饼","activity_num":1,"dish_activity":1,"cart_type":"cater"},{"cart_id":"0","product_id":"277976516634","product_quantity":2,"product_name":"鲜汁肉包(2个)"}]}修改后用计算器来计算一下总体价格，公式大概是这样的：总价=物品*-1+物品+优惠物品价格
算下来后下单成功了。绕过了服务器校验的单个数量不可以为负数的逻辑。（商家收到的图）
二、
在测试某款金融软件时，看了很多功能，逻辑都很严谨，在处处碰壁即将要放弃的时候，寻思试一下钱包吧，虽然感觉不太可能，但是梦想得有，万一实现了呢。于是提现时候试了一下负数~结果真的成功了。将下面参数中amount":"1"改为amount":"-1"
从图片中可以看出，负负得正，于是提现后钱包就多了相应得金额，如果被非法分子利用的话就拿去买东西或者直接提现了~
reqData={"amount":"1","cardId":"5612912350382","withdrawFlag":"0"}&sid=4dacbde55cfe1bd8fff6a9f2cc72c9ew&source=app
四、
某社交平台刷会员，这个纯是靠操作就能实现的一个逻辑漏洞了。在以前没有工具（还不懂）的时候经常靠操作来测试逻辑漏洞，也可以说是卡BUG，大家都知道有些软件推出了会员签约功能，签约付费就能以低价购买会员，这个漏洞是这样的，我第一次测试时，使用支付宝打开签约界面，然后使用微信在打签约界面，在依次支付，支付后系统提示，无法重复签约。我想难到系统有检测，舍不得**套不到狼。于是申请个新号再次测试，还是支付宝和微信都打开了签约界面，这次先签约其中一个比如签约微信，支付成功后，去微信取消签约，然后在去支付宝点击签约，奇迹发生了，到账了2个月的会员，也就是说服务器校验了不能同时签约，但是没有校验解约后再次签约的情况。提交漏洞后，等待漏洞修复又想出个测试方法，还是购买会员选择微信到签约界面，但是不签约，这时候换手机，登陆这个APP，再次打开微信签约界面，如此重复，打开N个微信签约界面后。签约又成功了。因为都是微信可能属于同类型的签约没有校验。
五、
再来说一个某云服务器刷代金卷。这个逻辑就比较简单了，测试的时候我发现了这个网站正在搞活动，送代金卷，根据我玩游戏的经验，程序总是喜欢在后台做一些隐藏的道具或者测试道具，只是屏蔽了前端。这时候我去领取代金卷时，用工具burp对ID进行遍历。13000-14000，遍历后发现居然领到了大金额无门槛的代金卷
领到了很多张这种无门槛的代金卷，我一看过期了，但是使用时候却能选择，并且成功使用购买的产品，于是我猜测应该是内部测试时程序给配置的吧，由于疏忽忘记加白名单所以谁都可以领取到了。
下面这个act_ids就是代金卷的组合。可以只保留一个然后进行遍历操作。
action=getVoucher&data={"activity_id":11177,"preview":false,"act_ids":[12637,12638,12639]}
六、
最后讲一个被忽略的漏洞吧，为啥被忽略呢，在下口才实在不行，辩不过审核小姐姐，某外卖软件强行货到付款，在测试某外卖软件时，测试了很多点，发现还挺安全的，反正一些小的逻辑漏洞都没有，于是在下单时看到了一个关键参数，这里面就不列举了，不然就知道是哪个了，该参数的值为0，其他参数都是地址，坐标，名字，订单号等信息，都能看懂是啥意思，唯独这个0不知道是干嘛的，于是改成1下单试一下，下单后我还没有支付就显示了订单成功，然后商家已接单，这个商家根本不支持货到付款（为了不造成影响找朋友的门店来测试的）不一会儿，外卖小哥就来到了店里，然后告知小哥这个订单是测试订单。我这边下单后可以直接点击确认收货，然后进行恶意差评。如果同行竞争的话利用这个漏洞简直太可怕了。用网上虚假手机号来下单，会给竞争对手造成很大的损失。但是审核小姐姐说这样做就违法了。我也不知道该说什么了，就这样吧哈哈直到今天这个漏洞也没修复。。。
京安小妹:业务逻辑漏洞的防御手段
月神：
站在攻击者的角度看待问题，查找问题时先不去想如何防御，我是对破解的过程有特别的兴趣，所以拿到程序时我先大概看一下程序的主要功能都有什么，然后迅速在脑中构思出一个破解思路和过程，然后开始着手破解，不停的尝试，觉得差不多了就停止，等有了新思路在尝试，也可以找一些朋友来帮忙测试一下，看一下有没有漏掉的点，毕竟每个人的思路还是不同的，找到了所有点后整理个报告，在来想如何防御，漏洞修复后一定要尝试其他思路是否能继续绕过，我在某SRC提交刷会员的时候用了3种不同的思路来绕过了~
更多精彩实战文章关注微信公众号：None安全团队