【业务安全02】业务数据安全

0 前言

业务中的数据安全不仅是存储在后台和数据库中的数据是否会被非法窃取或修改,还包括传输过程中的数据是否被非法窃取或修改。

1 商品支付金额篡改测试

  1. 概述:电商类网站在业务流程整个环节,需要对业务数据的完整性和一致性进行保护,特别是全包在用户客户端与服务、业务系统接口之间的数据传输的一致性,通常在订购类交易数据流程中,容易出现服务端为对用户提交的业务数据进行强制检验,过度信赖客户端提交的业务数据而导致的商品金额篡改漏洞。
  2. 手段:商品金额篡改测试,是通过抓包修改业务流程中的交易金额等字段,来检测是否存在金额篡改漏洞。
  3. 目的:该项测试主要针对订单生成的过程中存在商品支付金额校验不完整而产生的业务安全风险点,通常导致攻击者用实际支付远低于订单支付的金额订购商品的业务逻辑漏洞。
  4. 例子:在支付页面抓取请求中商品的金额字段,修改成任意数据的金额并提交,查看能否以修改后的金额数据完善业务流程。

2 前端JS限制绕过测试

  1. 概述:很多商品在促销活动中是限制用户购买数量的,如果服务器仅在页面通过JS脚本限制,没有在服务端校验用户提交的数量,则存在通过抓取客户端发送的请求包修改JS端生成处理的交易数据的业务漏洞。(其他一些查询业务可能会限制时间段,也可能存在类似的漏洞)
  2. 手段:将请求中的商品数量改为大于最大数显示的值,查看能否以非正常业务交易数据完成业务流程。
  3. 目的:该项测试主要针对电商平台由于交易限制机制不严谨、不完善而导致的一些业务逻辑问题。

3 请求重放测试

  1. 概述:请求重放漏洞时电商平台业务逻辑漏洞中一种常见的由设计缺陷所引发的漏洞,通常情况下所引发的安全问题表现为商品首次购买成功后,参照订购商品的正常流程请求,进行完全模拟正常订购业务流程的重放操作,可以实现“一次购买多次收货”等违背正常业务逻辑的结果。
  2. 目的:该项测试主要针对电商平台订购兑换业务流程中每一笔交易请求的唯一性判断缺乏有效机制的业务逻辑问题,通过该项测试可以验证交易流程中随机数、时间戳等数据的生成机制是否正常。

4 业务上限测试

  1. 概述:业务上限测试主要是针对一些电商类应用程序在进行业务办理流程中,服务端没有对用户提交的查询范围、订单数量、金额等数据进行严格校验而引发的一些业务逻辑漏洞。
  2. 手段:通常情况下,在业务流程中通过向服务端提交高于或低于预期数量的数据以校验服务器是否对所提交的数据做预期校验。存在此类脆弱性的应用程序,通常表现为查询到超出预期的信息、订购、或兑换超出预期范围的商品等。
  3. 目的:该项测试主要判断应用程序是否对业务预期范围外的业务请求做出正确回应。

5 商品订购数量篡改

  1. 概述:商品数量篡改测试是通过在业务流程中抓包修改订购商品数量等字段,以判断服务器是否存在商品订购数量篡改漏洞。
  2. 手段:将请求中的商品数量修改成任意非预期数额、负数等进行提交,查看业务系统能否以修改后的数量完成业务流程。
  3. 目的:该项测试主要针对商品订购的过程中,服务器对异常交易数据处理缺乏风控机制而导致相关业务逻辑漏洞。
  4. 例子:damiCMSV5.4网上商城为例。请参考文章《电子商城业务逻辑漏洞——篡改交易数据》。

6 总结

  1. 了解哪些位置或过程存在业务数据安全风险;
  2. 掌握不同风险点的测试方法。
  • 3
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值