dami5.4 商城支付逻辑漏洞

业务数据安全

商品⽀付⾦额篡改

    电商类⽹站在业务流程整个环节,需要对业务数据的完整性和⼀致性进⾏保护,特别是确保在⽤户客户       端与服务、业务系统接⼝之间的数据传输的⼀致性,通常在订购类交易流程中,容易出现服务器端未对⽤户提交的业务数据进⾏强制校验,过度信赖客户端提交的业务数据⽽导致的商品⾦额篡改漏洞。商品

    ⾦额篡改测试,通过抓包修改业务流程中的交易⾦额等字段,例如在⽀付⻚⾯抓取请求中商品的⾦额字       段,修改成任意数额的⾦额并提交,查看能否以修改后的⾦额数据完成业务流程。

      该项测试主要针对订单⽣成的过程中存在商品⽀付⾦额校验不完整⽽产⽣业务安全⻛险点,通常导致攻       击者⽤实际⽀付远低于  订单⽀付的⾦额订购商品的业务逻辑漏洞。

 

前端JS 限制绕过验证

     很多商品在限制⽤户购买数量时,服务器仅在⻚⾯通过JS脚本限制,未在服务器端校验⽤户提交的数量,通过抓取客户端发送的请求包修改JS端⽣成处理的交易数据,如将请求中的商品数量改为⼤于最⼤     数限制的值,查看能否以⾮正常业务交易数据完成业务流程。

     该项测试主要针对电商平台由于交易限制机制不严谨、不完善⽽导致的⼀些业务逻辑问题。例如,在促       销活动中限制商品购买数量,却未对数量进⾏前、后端严格校验,往往被攻击者所利⽤,购买多个促销       商品,造成商家的损失。

购买多个促销商品。

请求重放测试

     请求重放漏洞是电商平台业务逻辑漏洞中⼀种常⻅的由设计缺陷所引发的漏洞,通常情况下所引发的安       全问题表现在商品⾸次购买成功后,参照订购商品的正常流程请求,进⾏完全模拟正常订购业务流程的       重放操作,可以实现⼀次购买多次收货等违背正常业务逻辑的结果。

     该项测试主要针对电商平台订购兑换业务流程中对每笔交易请求的唯⼀性判断缺乏有效机制的业务逻辑       问题,通过该项测试可以验证交易流程中随机数、时间戳等⽣成机制是否正常。

⼀次购买多次收货

 

业务上限测试

     业务上限测试主要是针对⼀些电商类应⽤程序在进⾏业务办理流程中,服务端没有对⽤户提交的查询范     围、订单数量、⾦额等数据进⾏严格校验⽽引发的⼀些业务逻辑漏洞。     通常情况下,在业务流程中通过向服务端提交⾼于或低于预期的数据以校验服务端是否对所提交的数据做预期强校验。存在此类脆弱性     的应⽤程序,通常表现为查询到超出预期的信息、订购或兑换超出预期范围的商品等。

     该项测试主要判断应⽤程序是否对业务预期范围外的业务请求做出正确回应。    历史订单查询。

?id=6

?id=12

商城支付漏洞案例

启动BP  浏览器挂代理  开始抓包

之后我们查看余额看是否有回扣

 

  • 1
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 8
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 8
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值