SRC 实战技巧：通过参数名 Fuzz 突破注册接口，斩获千元赏金

在 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 看似简单，却是快速挖掘边界漏洞的实用技巧，核心从来不是 “暴力测试”，而是找到正确的测试方向，用最小的成本命中开发的逻辑疏漏。