在 SRC 漏洞挖掘中，很多人会把 Fuzz 等同于无脑暴力测试，觉得对着接口乱试参数效率极低，但实际上定向的参数 Fuzz 是挖掘边界逻辑漏洞的高效手段。不少高危漏洞都不需要复杂的利用链，恰恰藏在开发者容易忽略的参数命名、接口规范细节里，一个简单的参数枚举就能突破站点的权限防线。本文分享一个典型的实战案例，看看如何通过小范围的参数 Fuzz，快速突破未公开注册接口的限制。
一、前期信息收集：定位接口异常
测试目标是一个带登录入口的后台系统，页面为常规的账号密码 + 图形验证码登录表单。
首先对登录功能进行常规抓包分析，确认登录请求的账号参数名为username，整体请求逻辑无明显异常。继续梳理前端 JS 资源时，发现系统存在未在前端页面暴露的/register注册接口，属于可未授权访问的隐藏功能点。
正常逻辑下，注册接口与登录接口的账号参数名通常保持一致，于是直接参照登录接口的参数构造注册请求，向/register接口提交包含username、密码等字段的请求。但接口持续返回 “账号不能为空” 的报错，调整请求方法、传参格式、编码方式后，报错依然存在。
此时可以排除传参格式错误的问题，核心原因基本可以确定：注册接口的账号参数名，与登录接口的命名不一致，而前端没有暴露注册功能，无法通过页面获取正确的参数名。
二、核心突破：定向参数 Fuzz
既然前端和 JS 资源里都找不到注册接口的参数定义，盲目猜解效率太低，这时就可以用定向 Fuzz 的思路解决问题。
1. 构造针对性字典
这类账号类参数的命名有很强的行业共性，不需要全量暴力枚举，只需要覆盖开发常用的命名习惯即可。整理常见的用户账号参数变体，包括不同大小写、驼峰命名、业务场景的写法：
- 基础命名：
name、Name - 通用用户命名：
username、Username、UserName - 简写命名：
user、User - 账号类命名：
account、Account - 登录场景命名：
loginname、loginName
整个字典仅十余条参数，属于极小范围的定向枚举，不会对站点造成压力，且命中率远高于全量 fuzz。
2. Fuzz 验证结果
将字典中的参数名逐一替换注册请求的账号字段，遍历测试后，成功匹配到注册接口的正确账号参数名。提交请求后不再报错，账号注册成功。
三、漏洞利用与收益
使用注册成功的账号登录系统，进入后台后发现普通注册账号可直接访问大量系统内部业务数据，存在明显的权限管控缺失问题，属于敏感信息泄露风险。
按照 SRC 漏洞评级规则提交漏洞后，最终获得 1200 元的漏洞赏金。
四、案例复盘与挖洞技巧
1. 漏洞的本质成因
这个漏洞看似简单，实际是多个开发疏漏叠加的结果：
- 接口规范不统一：登录与注册接口大概率由不同开发人员维护，没有统一的参数命名标准，导致同个业务的两个接口参数名不一致。
- 接口权限缺失：注册接口未做访问限制，可被未授权用户直接调用，同时没有配置请求频次限制、人机校验，给参数枚举留下了空间。
- 权限分级失效：普通注册账号没有做权限隔离，可直接访问后台敏感数据，放大了漏洞的危害等级。
2. 参数 Fuzz 的适用场景
不是所有场景都适合用 Fuzz，这类小范围参数枚举，尤其适合以下几种情况：
- 发现隐藏接口，但无法从前端获取参数名；
- 同系统不同接口命名风格混乱，大概率存在参数名差异；
- 老系统、多团队迭代的项目，开发规范不统一的站点。
3. 高效 Fuzz 的实用技巧
- 优先测试大小写、驼峰、下划线的常见变体，80% 的命名差异都在这类基础变体里；
- 结合业务场景构造字典，用户类、订单类、管理类接口各有常用的参数命名，定向小字典的效率远高于全量暴力枚举；
- Fuzz 前先排除传参格式、请求方法、编码方式的问题，避免做无用功。
很多 SRC 漏洞都不需要高深的技术，往往藏在开发者的思维盲区里。参数 Fuzz 看似简单，却是快速挖掘边界漏洞的实用技巧，核心从来不是 “暴力测试”，而是找到正确的测试方向，用最小的成本命中开发的逻辑疏漏。
