实战|记录对某网站漏洞挖掘

前言

记录一次对某网站漏洞挖掘，漏洞点为功能性漏洞，漏洞发生原因为逻辑判断问题，因涉及企业和个人信息，敏感信息将进行打码，后续漏洞将进行提交

漏洞过程

网站的主营业务为售卖服务，虚拟商品等，不同的种类，可以选择按数量购买或按时间购买，经过测试，此网站的某商品中，在选择数量时未进行上限判断，可进行科学计数法进行绕过，网站默认购买数量为1000

在输入正常值的时候，会正常显示账单价格

因输入结果后js会自动获取账单价格，此时我们在数量中输入科学计数法：1E，账单此时价格为0元

可以得知以下结论：开发者未对网站此功能点处做数据过滤，未设置数量上限

漏洞测试及分析

看到有两个支付接口，一个是ZFB支付，一个是余额支付，我们先进行ZFB支付看回显结果

经过以上图片可以看到，输入的数据确实按照1e即1亿去执行的，在将数据传递给zfb接口的时候，因数额太大则导致失败，此时抓包看一下数据

首先第一个包中GET数据中有三个参数，这个数据包主要是判断传递参数是否有问题，第一个参数为0，是判断的购买数量，购买为1000的时候值为1，2000的时候值为2，依次类推，至于为0则是因为传递的数值过大，无法进行处理，则为0，第二个参数是购买的商品类型，第三个参数是所购买的商品类型中的子类

此时将第一个数据包放出后通过检验，后台生成一个订单号，传递给ZFB的api

看ZFB付款页面中，参数中会携带对应的订单号，和官方的参数数据，如果支付成功，api响应success，失败或其他则返回fail或false

再看第二个支付通道，分析此数据包，还是一如既往的生成一个校验参数传递给后端

此时后端接收到校验数据后，根据自身条件判断没问题后，将生成一个订单号传递给余额，后续扣费

此时看到回显成功，并且前往个人中心查看订单已经生成成功，可用时间为5年，费用为0，默认数量也是为1000(因为判定条件中不存在0这个数量)

意外发现：通过回显的数据中，backendIP为内网IP，没做后渗透操作，就没在管

整改建议

对输入的数据类型做严格过滤，为购买的商品数量做上限限制，对核验时的参数值做严格核对，对回显中的内网IP做参数删除或更改为域名或外网IP响应

总结

此次漏洞挖掘，漏洞为支付时出现逻辑判断出错，在进行首次判断传递参数的时候，因为传递数值过大，无法进行处理，数量则为0，两个类型则是判断商品及子类是否存在，当三个条件满足时，将生成订单号交给后端，逻辑上的错误：系统无法处理造成数量为0则扣费余额也是0，造成和账户余额校验时为恒真，支付成功后可正常使用商品服务，影响较大，危害较大，此外在所有操作后，返回数据包中程序暴露出内网IP地址

此次测试漏洞将打包上传给官方，并给出修复建议

原文始发于微信公众号（迪哥讲事）：实战|记录对某网站漏洞挖掘