文章总结： 本文揭示了一种高危访问控制绕过漏洞，因权限校验与数据查询对同名参数解析不一致。攻击者通过构造重复参数或嵌套对象，利用校验读自身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辅助挖漏洞

#

如何在移动端抓包-下

#

如何绕过签名校验

#

一款bp神器

挖掘有回显ssrf的隐藏payload

ssrf绕过新思路

一个辅助测试ssrf的工具

dom-xss精选文章

年度精选文章

Nuclei权威指南-如何躺赚

漏洞赏金猎人系列-如何测试设置功能IV

漏洞赏金猎人系列-如何测试注册功能以及相关Tips‍

参考

@z-wink

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：迪哥讲事 z-wink z-wink《一种获取高危的访问控制绕过思路》