文章总结： 本文揭示了一种高危访问控制绕过漏洞，因权限校验与数据查询对同名参数解析不一致。攻击者通过构造重复参数或嵌套对象，利用校验读自身ID放行、查询读目标ID的逻辑差，实现越权获取敏感数据。建议统一参数处理逻辑，避免混用自动映射与手写解析。
综合评分： 86
文章分类： 漏洞分析,WEB安全,渗透测试
一种获取高危的访问控制绕过思路
原创
z-wink
z-wink
迪哥讲事
2026年2月5日 09:01
四川
一种获取高危的访问控制绕过思路
正文
服务器先用第一个参数做权限检查，再用第二个参数做数据库查询。
攻击者只要插入第二个同名参数，就能越权读取别人的数据。
正常请求：
{
"customerId": "123456"
}
服务器逻辑：
1.检查 customerId=123456 是否属于当前登录用户 → 通过
2.查询 customerId=123456 → 返回自己的数据
攻击请求（插入第二个同名参数）
{
"customerId": "123456",
"customerId": "654321"
}
服务器实际处理流程（错误实现）：
1.访问控制模块读取第一个 customerId=123456 → 判断“你有权限” → 放行
2.数据库查询模块读取第二个 customerId=654321 → 返回 654321 这个用户的数据
结果：
攻击者用自己的 customerId 通过权限检查，却拿到了别人的数据。
这就是 访问控制绕过导致的用户数据泄露。
不同后端框架对 JSON 解析方式不同，可能产生不同效果：
1）数组型参数
"customerId": ["123456", "654321"]
~
某些后端会：
权限模块取第一个值
查询模块取最后一个值
2）对象嵌套型
"customerId": {
"customerId": "123456"
}
~
有些序列化库会自动展开或取内部值，引发逻辑错位。
这种错误一般人可能不太理解,我这里举个例子:
权限校验用的是外层 customerId → “123456”
数据查询用的是内层 customerId → “654321”
场景 ：查看他人账户信息
攻击请求：
POST /api/customer/profile
Authorization: Bearer user123token
{
"customerId": {
"customerId": "654321"
}
}
服务器执行：
1.权限检查模块：
外层 customerId → “123456” (当前用户自己的) → 校验通过
查询模块：
内层 customerId → “654321” → 返回 654321 的个人信息
攻击者直接看到：
他人姓名
电话
地址
身份证号
PII 泄露，高危漏洞。
为什么真实环境中会出现
使用自动 JSON → DTO 映射（Jackson / Gson / Newtonsoft JSON）
同时又存在手写 JSON 解析
权限校验与业务处理由不同微服务 / 不同团队实现
容错式编程造成 fallback 逻辑
这类组合在大型企业系统非常常见。
为什么这种漏洞危险
不需要爆破
不需要猜 Token
不需要高权限
只靠构造 JSON 即可越权
属于高危 Broken Access Control
如果你是一个长期主义者，欢迎加入我的知识星球，本星球日日更新,包含号主大量一线实战,全网独一无二，微信识别二维码付费即可加入，如不满意，72 小时内可在 App 内无条件自助退款
往期回顾
#
如何利用ai辅助挖漏洞
#
如何在移动端抓包-下
#
如何绕过签名校验
#
参考
@z-wink
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：迪哥讲事 z-wink
z-wink《一种获取高危的访问控制绕过思路》