四十二、支付逻辑漏洞

通过该实验了解支付逻辑漏洞,掌握常见的支付漏洞原理以及漏洞检测利用和漏洞防护。
预备知识

      随着网民越来越习惯于网上购物,出现了越来越多的电商网站,在线交易平台等。其中肯定要涉及在线支付的流程,而这里面也有很多购物支付的逻辑。由于这里涉及到金钱,如果网站逻辑设计不当,很有可能造成低价或者0元购买商品等很严重的漏洞。

支付逻辑漏洞分类:

#1支付过程中可直接修改数据包中的支付金额

     这种漏洞应该是支付漏洞中最常见的,主要针对支付宝等需要第三方支付的案例。开发人员往往会为了方便,直接在支付的关键步骤数据包中直接传递需要支付的金额。而这种金额后端没有做校验,传递过程中也没有做签名,导致可以随意篡改金额提交。

      只需要在支付过程中用抓包工具抓包发现有金额的参数修改成任意即可。

      案例:12308订单支付时的总价未验证漏洞(支付逻辑漏洞)

#2没有对购买数量进行限制

      这种案例也比较常见,产生的原因是开发人员没有对购买商品的数量参数进行严格的限制。这种同样是数量的参数没有做签名,在抓包后导致可随意修改数量,经典的修改方式就是改成负数。

     当购买的数量是一个负数时,总额的算法仍然是"购买数量x单价=总价"。所以这样就会导致有一个负数的需支付金额。若支付成功,则可能导致购买到了一个负数数量的产品,也有可能购物网站会返还相应的积分/金币到你的账户上。

     但是,这种情况不可能发生在通过支付宝支付的订单中,因为显然支付宝是不支持一个负数金额的订单,所以这种情况多数发生在一个有站内虚拟货币的网站。

      我们来看一个案例:国美网上商城支付漏洞1元订购Iphone 4S!

#3购买商品编号篡改

     例如商品积分兑换处,100个积分只能换商品编号为001的低价格商品,1000个积分能换商品编号005的高价格商品,在用100积分换商品的时候抓包把换商品的编号从001修改为005,用低积分换区高积分商品。

     案例:联想某积分商城支付漏洞再绕过

#4支付逻辑顺序执行缺陷

     部分网站的支付逻辑可能是先A过程后B过程然后C过程最后D过程用户控制着他们给应用程序发送的每一个请求,因此能够按照任何顺序进行访问。但是,如果用户直接从B直接进入了D过程,就绕过了C过程。如果C是支付过程,那么用户就绕过了支付过程而买到了一件商品。如果C是验证过程,就会绕过验证直接进入网站程序了。

     案例:万达某分站逻辑错误可绕过支付直接获得取票密码

#5请求重放

     购买商品成功后,重放购买成功的http请求,可以使购买的商品一直增加。购买成功后,会有一个从银行向商户网站跳转的过程,如果这个过程反复的重放,有可能导致商品的反复购买和增加,但是用户不需要支付更多的金钱。

      案例:豆丁网购买豆元后可以将豆元倍增

#6程序的异常处理

     程序的异常处理比较少见,不过也是有案例的。程序的异常处理,就是指支付的数据包异常的程序的错误处理。这种异常可以是数据与KEY不符,支付的金额有错误,购买的数量不正确等等。程序的异常处理出现的原因主要是开发人员对出现异常后的处理不当造成的。

     案例:115网盘存在支付绕过

 

      当然支付逻辑漏洞不止上面列举的这些类型,但最常见的支付漏洞为直接修改金额,修改购买商品数量以及窜改商品编号这三种,下面就来实践下这三种支付逻辑漏洞。

实验目的

  通过该实验了解支付逻辑漏洞,掌握常见的支付漏洞原理以及漏洞检测利用和漏洞防护。

实验环境

                 

Win7

IP地址:10.1.1.23

工具路径:C:/tools

实验步骤一

支付过程中可直接修改数据包中的支付金额

      访问http://10.1.1.23/demo/

      用账号tom密码123456 登录进入系统

      

      进入系统后,发现当前余额只有5元,尝试购买1本书籍1和1本书籍2,发现购买不成功,余额不足。

      

      重新登录进入系统,打开burpsuite工具,浏览器设置本地8080端口代理,购买的数量同样输入1本书籍1和1本书籍2,在点击购买的时候抓取到数据包,分析数据包可以直接看到传输的商品金额分别为10和20,尝试直接将金额都修改为0.1然后点击forward继续发包,可以看到最后成功的使用0.2元购买到2本书籍。

      

     

     查看购买页面网页源代码可以发现,漏洞产生的原因就是由于直接在前端定义了商品价格,并且传输到buy.php页面处理时,并没有对价格数值进行验证,总价=单价*数量,从而可以导致用户可以进行更改商品价格,防御的方法就是在数据库中存储商品的价格并且在订单支付时对商品的价格进行验证。

      

     

实验步骤二

没有对购买商品数量进行限制的支付逻辑漏洞

     首先打开http://10.1.1.23/destoon/,点击网站右上角免费注册进行个人会员注册,然后注册成功自动登陆,点击网站右上角站内信查看收件箱中名为充值卡的信件。

      

      使用信件中的充值卡号和密码进行充值,点击上方的交易管理->充值记录->充值卡充值,填入对应的卡号和密码进行充值,充值成功后点击资金流水看到当前账户的余额为100元。

      

      充值成功后,直接访问首页http://10.1.1.23/destoon/,点击团购,看到正在进行促销的苹果6,点击参团->购买,来到订单确认页面,购买一个苹果6手机价格66.66元,填写收货手机号码。

      

      打开抓包工具Burp,并设置好相关代理,点击提交订单,观察burp抓到的数据包。如下图所示,抓到的数据包中没有看到有关金额的值,但是有个number字段等于1,可以推测这个nubmer字段的值可能就为购买的商品数量,尝试将其修改为-1并点击forward发送数据包。

      

     发送过后可以看到网页提示订单生成成功,随后跳转到个人中心,团购订单页面发现订单已经变为已付款状态,同时查看资金流水也发现,个人账户多了66.66元,余额为166.66元。

      

      

      这就是由于网站没对用户购买的商品数量进行检验,从而导致网站返还金钱到用户账户,查看对应的处理商品购买的页面代码位于 C:\phpStudy\WWW\destoon\module\group\buy.inc.php

      可以发现网站只对传入进来的number值带入intval函数进行是否是整数的判断,随后就直接带入$amout=$number*$item[‘price’],那么如果用户传入的数量为一个负数则就会导致一个负数的支付总额,从而导致网站返还金额给用户。

      

      那么防御的方法也很简单,把上图中被注释掉的代码取消注释,增加对number值进行一个是否小于1的判断,也就是判断用户购买的商品数量是否小于1。

实验步骤三

支付过程中对购买商品编号进行篡改

      打开浏览器访问http://10.1.1.23/yershop/ 进行注册登录

      首先点击首页1F位置的苹果,价格为299元,观察商品详情页的url链接,链接中有id/42的字样,推测可能为商品的id编号http://10.1.1.23/yershop/index.php?s=/Home/Article/detail/id/42.html

      

      再回到首页点击2F位置的魅族手机页面,价格为2268元,同时观察url链接中的商品id编号为68

      

     回到苹果商品详情页面,打开burp,设置好相关代理,点击加入购物车。在Burp界面可以看到截取的信息,同样可以发现POST的第一个参数id是商品的标示信息,这里为苹果的42,在购物车显示的商品名就是通过这个参数传递在数据库查询出来的。

      

      修改此商品的id参数值为魅族手机的id号68,当继续发包时,传递的id参数,在数据库查询为魅族手机的商品名,而传递的price价格参数为苹果的价格。导致加入到购物车后显示的业务信息不一致。

      到网站购物车查看,发现只需要苹果的价格299元就可以购买到价格2268元的魅族手机,并且最后可以成功下单。

      

      修复方案:

     1.对于传递重要的参数信息应当加密隐藏

     2.传递多个参数之间应当检测数据的一致性

 

转载:http://www.hetianlab.com/expc.do?ce=7961742b-15c3-4900-a409-4d6ff730bc0c

posted @ 2020-03-09 11:02  the苍穹  阅读(1240)  评论(0编辑  收藏  举报