在线支付漏洞

1. 修改单价、总价：改小、四舍五入支付、负数、金额上限溢出为0(名称：商品、快递费、其他费用) (场景：订购、确认信息、付款处)
   修复建议：商品信息，如金额、折扣等原始数据的校验应来自于服务器端，不应接受客户端传递过来的值
2. 修改数量：负数、多数(以一买多、俩商品一正一负)
   
   
   修复建议：服务端应当考虑交易风险控制，对产生异常情况的交易行为（如用户积分数额为负值、兑换库存数量为 0 的商品等）应当直接予以限制、阻断，而非继续完成整个交易流
   程
3. 修改支付对应的商品/同款不同颜色：替换商品id (以低买高)
4. 修改附属的优惠、领取优惠：修改领取优惠券额度；修改使用高优惠券的ID、优惠券额度；重复使用优惠券
   
5. 修改支付的状态：未付款修改成已付款等
   修复建议：建议对敏感信息如身份 ID、账号密码、订单号、金额等进行加密处 理，并在服务端对其进行二次比对
6. 替换订单号支付：低价格订单替换高价格订单
7. 覆盖订单号：用已支付订的单替号换未支付的
8. 竞争条件：同时创建多起订单，一起支付。(首月超低优惠、退款、余额支付)
9. 测试数据包未删除：商城下架但后端未删除、商城测试的商品(id等参数)
10. 修改支付接口：改成一个不存在支付接口(type)
11. 数据重放：订单无限制生成(价格有可能为0)
    修复建议：用户每次订单 Token 不应该能重复提交，避免产生重放订购请求的情况。在服务器订单生成关键环节，应该对订单 Token 对应的订购信息内容、用户身份、用户可用积分等进行强校验

案例

1、优惠券获梨
思路： 使用优惠券购买卡片获得卡片码，兑换卡片码获取马尼，这个兑换整体是获梨的。重复这套操作

先获取优惠券：SIGNUP30

使用优惠券后 7购买礼品卡，礼品卡可以换取 10，这样就多出来 3


需要做的就是重复这套流程，使余额不断增加
在burp的项目选项 → 会话(session)模块，选择添加会话处理，添加宏

范围scop，网址范围选择所有网址

添加宏

选择要重复操作的数据包，按购买逻辑调整顺序


提取gift-card参数值，放到下一个数据包的请求参数中


测试下宏，看下是否为预期结果。如果不是说明设置存在问题，查找原因，重新设置一遍

然后随便找个数据包放到Intruder进行重放即可

这里用的是查看余额的数据包，可以看到每次请求多了3。是预期效果