一、业务数据安全测试
1、商品支付金额篡改
案例1
靶场链接地址：Dashboard | Web Security Academy - PortSwigger。
使用提供的用户名和密码进行登录
wiener:peter
登录后查看我们的余额现在是100元
然后回到主页选择夹克进行购买
将夹克先添加到购物车中
然后到购物车中直接支付发现余额不足
这里直接使用bp抓取数据包，这里抓取的是添加购物车时的数据包。
修改商品金额后点击放包。
这样就可以完成购买了。
2、商品数量篡改
选择夹克添加购物车，但是这里在添加购物车的时候抓取数据包，然后将商品的数量修改为一个负数。
这个时候回到购物车查看，商品的总金额变成了一个负数。
然后我们添加一些别的商品，使得总金额回到一个我们可以支付的价格。
这里我添加了14个99.79元的商品
购买成功！
3、前端js限制绕过测试
1）测试原理和方法
·很多商品在限制用户购买数量时，服务器仅在页面通过JS脚本限制，未在服务器端校验用户提交的数量，通过抓取客户端发送的请求包修改JS端生成处理的交易数据，如将请求中的商品数量改为大于最大数限制的值，查看能否以非正常业务交易数据完成业务流程。
2）测试过程
观察发现客户端在前端浏览器使用JavaScript做了购买限制，尝试绕过限制提交购买请求，可以通过bp抓包修改数量字段，改为 100 个后成功提交，突破了前端限制
4、请求重放测试
1)测试原理和方法
请求重放漏洞是电商平台业务逻辑漏洞中一种常见的由设计缺陷所引发的漏洞，通常情况下所引发的安全问题表现在商品首次购买成功后，参照订购商品的正常流程请求，进行完全模拟正常订购业务流程的重放操作，可以实现“一次购买多次收货”等违背正常业务逻辑的结果。
2)测试过程
该项测试主要针对电商平台订购兑换业务流程中对每笔交易请求的唯一性判断缺乏有效机制的业务逻辑问题，通过该项测试可以验证交易流程中随机数、时间戳等生成机制是否正常
步骤一：在生成订单流程时抓取订购请求，
步骤二：观察每次订购相同商品的请求是否存在不同的随机Token、可变参数等，若有则检查这些随机数的变化情况和失效情况，是否在当前订购流程中唯一有效，
步骤三：尝试重放之前已经完成流程的订购请求，观察服务器端是否做出正确响应，若订购再次生效，订单再次生成则表明服务器存在脆弱性，
5、业务上限测试
1）测试原理和方法
业务上限测试主要是针对一些电商类应用程序在进行业务办理流程中，服务端没有对用户提交的查询范围、订单数量、金额等数据进行严格校验而引发的一些业务逻辑漏洞。通常情况下，在业务流程中通过向服务端提交高于或低于预期的数据以校验服务端是否对所提交的数据做预期强校验。存在此类脆弱性的应用程序，通常表现为查询到超出预期的信息、订购或兑换超出预期范围的商品等。
2）测试过程
该项测试主要判断应用程序是否对业务预期范围外的业务请求做出正确回应
案例：
步骤一：在业务查询-受理记录查询中，应用程序只允许登录用户查询6个月内的受理
记录，但是通过抓包分析出查询请求中存在明文字段month
步骤二：将month 设置的查询范围调高到6 个月以上并提交，应用程序返回了超过6个月的受理记录，表明服务器端并没有限制用户的查询时间，
步骤三：成功查询到大于 6 个月的办理记录，表明该功能不符合业务要求，
