基于Burpsuite的安全测试十三：业务数据安全测试
情景1：商品支付金额篡改测试
- 在支付页面抓包并篡改支付金额，继续跳转到支付平台完成支付，可以实现用低价买入高价商品。
系统修复方案：
商品信息、如金额、折扣等原始数据的校验应来自服务器端，不应该相信客户端传来的内容。
情景2：商品订购数量篡改测试
- 在购物车抓包并将商品数量更改为非预期数额或者负数进行提交，如果后台对这些异常订单做了处理则未能支付成功，如未作处理则支付成功。
系统修复方案：
对应异常情景的交易，如用户金额为负数、用户购买库存为0的商品、用户购买的商品数量为负数等，服务器应该做阻断、限制等操作。
情景3：前端JS限制绕过测试
- 如果用户购买的商品数量只在前端的JS脚本上做限制，未在服务器端校验用户提交的数量，则可以通过抓取客户端发送的请求包修改JS端生成处理的交易数据，将商品数量改为异常值，完成交易。
系统修复方案：
商品信息、如金额、折扣、数量等原始数据的校验应来自服务器端，步应该相信客户端传来的内容。如果跨平台支付，涉及平台之间接口调用，对参数的完整性校验一定要做好，确保业务重要数据再平台间传输一致。
情景4：请求重放测试
- 如果对每笔交易缺乏唯一性判断的有效机制，就会导致一次购买多次收货等异常逻辑结构。
- 生成订购请求页面抓包，可以观察每次订购相同的商品请求是否存在不同的随机token、可变参数，若有则检查这写参数的变化情况和失效文化课，是否在当前订购流程中唯一。
- 支付完成订单，重放之前已经完成流程的订购请求，如果能再次订购额说明服务器存在脆弱性。
系统修复方案：
- 一个订单对应唯一一个token，不能复用token，避免重放订单请求。
- 服务器端要对订购信息、用户身份、用户金额等进行强校验。
情景5：业务上限测试
- 在业务流程中通过向服务器提交高于或低于预期的数据以校验服务器端是否对所提交的数据做预期强校验。
- 如业务规定只能查看最近三个月的转账记录，通关抓包更改查询时间，可以查询到六个月的记录。
系统修复方案：
- 在服务器端应该对订单token对应的订购信息内容、用户身份、用户账户余额做强校验。
- 对于异常交易行为，服务器应该做阻断、限制等操作。