挖掘网站支付漏洞中突然想到的一个骚思路
对一个产商做渗透测试已经三天了,大大小小的传统、逻辑漏洞已经挖掘的差不多了,抱着最后在试一试的心态,于是认真把整个购物的流程仔细分析了一次,就有了下面这个案例。
截图比较模糊,师傅们将就着看看哈
目标是一个购物网站,直接挑选4件商品下购物车,(129一件、256一件、299两件),总金额是983块钱。
陈结算的时候截获流量-修改299商品的参数为负2,平台等于欠我两件商品钱。
放开数据服务器响应后,价格就会变成-598块
这里由于修改了参数,价格变成了负213块,提交订单的时候会提示无法下单,
无法下单意味着前面修改的参数无效,如果点击"我知道了",肯定会回退到没修改过参数的购物车商品那里。这下可犯难了。。
停留在错误的提示页面思考了十几分钟,那如果,我不点击错误提示,而是点返回呢?会不会有啥变化。试一试,发现点击浏览器坐上角的返回键后,
不会重新刷新购物车,而是执行了我修改负2的操作,发现那件商品的数量那里渲染颜色加深了,变成不可操作。但是此时的金额变成负数了,如果这个时候我提交订单的话肯定是不会执行成功的,前面说了有校验。
于是我试着在这个页面增加另外一个商品的数量,让新加的商品来还欠我的两件商品的钱,这么一来,订单就成正数了。
然后再一次提交订单的时候,由于订单是正数,所以提交成功
然后就跳到支付页面去了,不过我这里没有支付,在账户里看下订单就知道有没有成功。
其实这个金额还可以算的更低些,不过当时只是为了证明,就没有去细算。当然,厂商也很快确认并修复了这个问题。
截图比较模糊,师傅们将就着看看哈

目标是一个购物网站,直接挑选4件商品下购物车,(129一件、256一件、299两件),总金额是983块钱。
陈结算的时候截获流量-修改299商品的参数为负2,平台等于欠我两件商品钱。
放开数据服务器响应后,价格就会变成-598块
这里由于修改了参数,价格变成了负213块,提交订单的时候会提示无法下单,
无法下单意味着前面修改的参数无效,如果点击"我知道了",肯定会回退到没修改过参数的购物车商品那里。这下可犯难了。。
停留在错误的提示页面思考了十几分钟,那如果,我不点击错误提示,而是点返回呢?会不会有啥变化。试一试,发现点击浏览器坐上角的返回键后,
不会重新刷新购物车,而是执行了我修改负2的操作,发现那件商品的数量那里渲染颜色加深了,变成不可操作。但是此时的金额变成负数了,如果这个时候我提交订单的话肯定是不会执行成功的,前面说了有校验。
于是我试着在这个页面增加另外一个商品的数量,让新加的商品来还欠我的两件商品的钱,这么一来,订单就成正数了。
然后再一次提交订单的时候,由于订单是正数,所以提交成功
然后就跳到支付页面去了,不过我这里没有支付,在账户里看下订单就知道有没有成功。
其实这个金额还可以算的更低些,不过当时只是为了证明,就没有去细算。当然,厂商也很快确认并修复了这个问题。
评论157次
每次挖交易逻辑漏洞,都是付了钱,花了钱,却没挖到漏洞。
每次挖交易逻辑漏洞,都是付了钱,花了钱,却没挖到漏洞。
一正一负 负负得正
很常规的思路
我每次碰到的都是改了就失败了,改金额,改数量,改正负,提交就校验失败
楼主这思路可以
很常见的漏洞,负负得正。
我记得清清楚楚 上次为了挖一个保险漏洞 花了500快买了一个保险 挖到了一个逻辑漏洞 结果 给我20快
那我就在想,如果按照这个流程下去,后台是如何显示你的订单呢..
逻辑漏洞就是胡改乱闯
点浏览器的返回这个思路是个亮点。
挖支付的就是给了钱自己却没找到漏洞
果然是细节处见功夫啊,佩服楼主的思路
这种漏洞的程序员刚入门的吧,一点意识都没有
请把这个程序员杀了祭天,这种涉及金钱的,都要后端进行校验的。前台只做显示用。
兄嘚 多看乌云 多看书 你就会发现这种基本操作 老早就有了......
后台逻辑校验问题,在最后下单时,没有再判断订单金额和支付金额。。。。。。
有些时候买的套装那种,一个商品里面好几个,每个都配有单价,也可以试试这种方法
大佬思维确实缜密,一般我要是搞了几天就直接不看了,懒得想。
这个逻辑只判断了。租后总金额为正,并没有严格验证商品数量必须为正
厂商觉得校验了负数就OK了哈哈哈,老哥想法很骚,学xi了
现在逻辑漏洞不好找了,难搞呦
说到底也就是说xi统是对总价格是否为负数做了校验