渗透测试业务逻辑之业务数据安全

0x00：前言

上周做渗透，有一个 sql 注入，负责安全审核的人给开发说你们的程序既然还有 sql 注入，我一年也看不见几个。这句话让我又再次深刻的认识到，渗透测试常规的一些注入跨站漏洞不如以前那么盛了，有点经验的开发写东西都会去考虑到了，再加上修复方法也在逐渐的完善，逻辑类的东西也应该并重的去测。

0x01：分类

我把逻辑类的问题大概总结了一下，大概可以分为十个模块，分别是登录认证模块测试、业务办理模块测试、业务授权访问模块测试、输入 / 输出模块测试、回退模块测试、验证码机制测试、业务数据安全测试、业务流程乱序测试、密码找回模块测试、业务接口调用模块测试。

这次记录的是第七个模块业务数据安全测试。

0x02：业务数据安全测试

1，商品支付金额篡改测试

测试方法：在一些电商系统或是支付购买商品功能处，生成订单后去支付时，拦截其请求，看支付金额是否可以修改，修改后提交至服务区器，如果成功返回，且存在此问题。

修复方法：对于一些支付类的信息，不能在前端控制，其校验信息应该由后端来完成。

2，商品订购数据篡改测试

测试方法：这个和商品支付金额负数，提交后弱服务器成功返回，则存在此问题。

修复方法：后端应该对其风险进行控制，对异常的交易行为进行限制和阻断，其异常行为例如积分为负、交易商品数量为负、交易商品数量和金额不符，商品数量为 0 等。

3，前端 js 绕过测试

测试方法：例如一个促销活动购买商品的功能，其商品有购买数量限制，比如没人限购 1 份，这时输入 1 发送请求，拦截数据包修改其值，修改为多份时，如果成功提交，则存在此问题。

修复方法：对于类似的功能，其关键的数据信息校验应该由服务端完成，而不能只以前端来做判断。例如，商品的金额，商品的折扣，商品的数量和限购等。

思路拓展：昨天没事，随便翻了一个网站，有一个提现余额功能，提现时前端会有 js 判断，其金额必须大于 50，修改前端 js 和禁用 js 出了些问题没有利用成功，这时候前端 js 绕不过去，于是就看 js 代码，如果余额大于 50 则请求的连接是什么，然后伪造了一个其请求的数据包发送给服务器，其中提现金额是明文的，输入 100 后台返回余额不足的信息，猜想后台是把余额减去提现金额来做的功能，这时后输入提现金额为 - 100，服务器返回成功，返回个人中心看时，余额变成了 100。

这个属于典型的后台校验不足，修复也很简单，后台判断其提现的金额即可，例如必须大于 50 且不为负数，或接收其类型时强制转换为 int 型。

4，请求重放测试

测试方法：例如一些商品订购功能，生成订单时抓取其请求，然后发送到 repeater，不断的 go，如果一个请求可以多次成功，生成多个订单，则存在此问题。其危害在于一次购买多次收货。

经验之谈：除了订购下单等功能外，可以多次请求的功能都可以做相关测试，例如添加管理员，添加一些信息等功能，其危害在于恶意攻击者获取此请求后，便可操作程序。

修复方法：可以添加随机的 token 作为验证，一次请求后即失效。在服务器端生成订单的时候，要对订单 token 对应的订购信息内容、用户身份、用户积分等一些信息进行强制校验。

5，业务上限测试

测试方法：说是业务上限测试，也可使说是对前几条的总结或结合，例如一个查询订单功能，只能查最近 6 个月的订单，请求后抓包，修改其值为 12 则可以查看一年的订单，则存在此问题。

经验之谈：上面说的几条也可以算作业务上限问题，总结下就是在请求订单的过程中，只要超过系统的预定值，且请求成功的，都可以算作业务上限问题，只不过在记录报告时，需要具体的写明哪个参数可改，这样最好。

修复方法：修复方法：可以添加随机的 token 作为验证，一次请求后即失效。在服务器端生成订单的时候，要对订单 token 对应的订购信息内容、用户身份、用户积分等一些信息进行强制校验。

0x03：总结

这次记录了业务数据安全的一些测试方法和要点，后续会继续记录其他模块。

                                                                        公众号推荐：aFa攻防实验室

                         分享关于信息搜集、Web安全、内网安全、代码审计、红蓝对抗、Java、Python等方面的东西。

最后

以上就是无情银耳汤为你收集整理的渗透测试业务逻辑之业务数据安全的全部内容，希望文章能够帮你解决渗透测试业务逻辑之业务数据安全所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。