WEB攻防-通用漏洞&购买支付逻辑&数据篡改&请求重放&接口替换
目录
WEB攻防-通用漏洞&购买支付逻辑&数据篡改&请求重放&接口替换
#知识点：
1、商品购买-数量&价格&编号等
编号的相关问题就是，比如600的商品编号为a，300的商品编号为b。那么能不能抓包i通过修改编号，然后购买300的商品变成最后买到的是600的商品。
2、支付模式-状态&接口&负数等
这个负数就是价格，买东西五百元就是正五百，抓包改成负五百是不是可以商家倒贴钱。
3、折扣处理-优惠券&积分&重放等
优惠券有点只能领一次，但可不可以修改数据包达到一直领，重放就是能不能把购买数据包一直重发能不能达到一直购买的目的。
#详细点：
1、熟悉常见支付流程
选择商品和数量-选择支付及配送方式-生成订单编号-订单支付选择-完成支付
2、熟悉那些数据篡改
商品编号ID，购买价格，购买数量，支付方式，订单号，支付状态等
3、熟悉那些修改方式
替换支付，重复支付，最小额支付，负数支付，溢出支付，优惠券支付等
溢出支付就是商品只能买99次，你直接买完看接下来出现什么。
#章节内容：
1、权限相关-越权&访问控制&未授权访问等
2、购买支付-数据篡改&支付模式&其他折扣等
3、下节课
4、下节课
案例演示
数据篡改-价格&数量&产品
1、修改数量达到价格变动
2、修改单价达到价格变动
3、修改产品达到低价购买
4、修改接口达到成功购买
首先在本地搭建好网站，名字为damicms，然后直接来到产品展示这里，先点第一个大米测试产品进去。
我们可以看到价格为六千，接着我们抓包，然后修改数据包的内容。
可以看到这里购买的数量和价格以及类型等等都可以更改，这里把价格改成零。
订单列表的价格就变成了0，把数量改成0的话，总价也是零。这就是因为他没有把这些参数固定死，导致出现的安全问题。
还有一个就是修改产品，我们先把购买大米测试产品的数据包参数复制下来。然后把大米手机cms的也复制下来。接下来我们购买大米手机cms，他的价格是6000，我们把抓到的数据包除单价和数量，其他的都改成大米测试产品的，然后放包。
这里会发现我们花了5400就购买到了要花6000的大米测试产品。这就是低价产品去买高价，这是当我们不能对数量和价格做修改的时候的另一种做法。
修改接口就是说修改支付接口，我们平常买东西都是微信支付宝或则网银之类的，也就是付款方式。
这里我们就选择这个支付宝这个支付接口，点击提交订单。抓包可以看到这一系列参数就是代表的支付宝接口，如果说你把这个改成你自己的支付接口的话，就像行当与你把钱付给自己。然后支付状态也没问题的话，对方就会认为成功支付了。但是这个支付接口是比较难申请的，因为关联一些洗钱相关的黑色产业，所以抓的比较紧，并且也是违法行为。这里不做演示，知道有这个东西就好。
这是一个攻击点，但防御也很简单，就是对方不认你这个接口，它直接在源码中写清楚只接受自己的接口，所以就算你改成功了，并且也付款成功了。对方那里就会显示购买失败。
修改方式-订单号&数量&优惠券
1、修改数量达到价格变动
2、修改订单达到底价购买
3、优惠券重放使用&重领使用
首先我们在本地搭建好网站(niushop_b2c_release)，搭建好之后先在后台创建商品分类，接着创建商品，并且创建一个优惠券。还要再设置里面把物流配置一下。
然后抓包点击领取优惠券，可以看到有一个参数coupon_type_id=1，
然后我们开启抓包，点击购买之后，看一下使用优惠券和不使用优惠券数据包中参数的区别。
可以看到就是参数coupon_type的不同，使用的为1，不使用就是零。
而这个方面的安全知识就是只能领取一次和重复使用，接下来的操作由于每个人在设置优惠券时的不用，所以结果也是不一样的。我和小迪的不太一样。因为后台设置的不同，建议自己多尝试一下就会发现一些端倪。
首先这里只能领取一次优惠券这个问题是看对方设置的，就算这里我把参数coupon_type的值改成20，也是不行的。但小迪可以，因为小迪在演示之前领取了很多优惠券(个人猜测)，然后演示的时候可以是因为参数的值写对了，如果参数的值不对的话，也就是数据库中没有这个值的话也是不行的。就比如下图，这个图是数据库中优惠券的表，可以看到这个coupon_type的值就只到10，这是因为我领取了十次，倘若对方在后台设置只能领取一次的话，那么就不会有这么多事。
但这个是有重复使用的问题，优惠券一般是储存再数据库中，如果优惠券在使用之后，数据库没有执行删除优惠券的操作的话就会出现重复使用的结果。
紧接着说关于这个只能领取一次这个东西，还是跟编号有关，商家可以通过把编号的值复杂化或则进行编码加密，让你不这么好伪造即可杜绝这种隐患。
然后就是修改订单的相关问题，这个跟刚才讲的修改修改产品达到低价买高价类似，就是说把商品创建订单的数据包记录下来，结算100000订单的时候把编号改成1000的编号，如果说这个东西没做防护的话是可行的，但是这里做防护的，这里是有个id值的，id为71对应1000的订单，id为72对应100000的订单，这里他是把id作为评判每个订单的标准，但同时也对id和订单金额做了绑定，如果说你把id换成72，也就是100000的订单，然后编号改成1000订单的编号，会直接提示报错。因为这里是有检测的，如果没有检测的话，或则只对订单校验的话，那这里就可能有漏洞。
某实例-演示站交易支付逻辑安全
直接搜索下面的链接打开即可，然后自己注册个账号。
随便点击一个抓包
本来是6000块钱，但这数据包中数量和金额都可以修改，这就是典型的支付漏洞。
但这个好像被修复了，因为我改了之后，它的金额没有变，应该是有人提交漏洞了。
#代码审计-业务支付逻辑&安全修复
1、金额以数据库定义为准
2、购买数量限制为正整数
3、优惠券固定使用后删除
4、订单生成后检测对应值
以上四点就是对刚才学的这么多漏洞隐患的修复方案，代码审计呢就是说首先这个网站要有这个功能，然后再找这方面的漏洞，通过看数据包中请求的地址去找到相应的文件，然后进行代码追踪以及审计。
第一点：金额以数据库定义为准。这个从这两个源码可以看出区别，第一个damicms虽然金额也储存在数据库中，但是最后计算总金额的时候不拿这个数据库的金额去计算，而是拿数据包中的金额去计算，所以才会有此漏洞。而niushop这个源码就是说只能修改数量，价格不能修改，然后单价储存在数据库中，并且计算总金额的时候，也是取这个数据库中的单价去计算的。而刚才那个qilecms的实例之所以不行，我估计就是因为它虽然接受价格这个参数，但是还是以数据库的为主。
第二点：购买数量限制为正整数 这个没什么好说的，就是不让它的数量为负数或则零或则带小数点。
第三点：优惠券固定使用后删除 这个刚才说过了，使用后删除就可以防止重复使用，还有一个就是对数据包中优惠券的参数复杂化或则加密来防止对方可以伪造优惠券。
第四点：订单生成后检测对应值 这个就是刚才那个修改订单的相关知识，生成订单后还会对id值去校验，防止用1000买100000的商品。
一般这类问题就是把该固定的值固定好，比如这个订单编号，订单在生成之后，就会生成一个订单编号和id值，并且储存到数据库中，还有价格和数量也会写道数据库中。它如果说只认id值，并且id值也是固定好的，你就算把订单编号修改了也不行。如果说以某个值为准并且这个值没有固定好，那么就可能存在安全问题。也就是说这个支付功能想要实现它有几种方式，可能以数据库为准也可能以数据包中的值为准，那数据包中的值我们能够修改，如果以这个为准那肯定是不安全的。数据库则会相应的安全，但是你要能取得数据库权限并且登录进去那就另说。
8837
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
