文章总结： 本文探讨API安全中的大规模赋值漏洞，分析其原理及危害。作者提出高效的挖掘方法：利用BurpSuite扩展提取参数构建词表，结合ParamMiner进行模糊测试。通过两个实战案例展示技术效果，包括利用隐藏参数将拒绝访问端点转化为PII泄露，以及绕过OAuth限制实现HTML注入。文章为安全测试提供了极具操作性的隐藏参数挖掘思路。 综合评分： 82 文章分类： 渗透测试,实战经验,SRC活动,WEB安全,漏洞分析

0140.隐藏的武器：我如何将批量任务转化为赏金

原创

@0xuserm9 @0xuserm9

Rsec

2026年3月24日 09:13 贵州

本文章仅用网络安全研究学习，请勿使用相关技术进行违法犯罪活动。

声明：本文搬运自互联网，如你是原作者，请联系我们！

类型：隐藏参数

各位，希望你们一切都好。

在现代漏洞赏金领域，“唾手可得”的漏洞早已成为过去。攻击面已经发生了变化。我们不再仅仅关注基本的反射型 XSS 或简单的 SQL 注入；真正的战场深藏在复杂的 API 内部。要找到关键漏洞，你必须停止关注前端 UI 所允许的内容，转而开始研究开发者从未打算让你看到的后端业务逻辑。

今天，我们要讨论的是大规模赋值漏洞。 这种漏洞非常普遍且危害巨大，一直稳居 OWASP API 安全 Top 10 榜首（目前归类于 API3：对象属性级授权缺陷）。它就像一把隐藏的武器，可以将看似安全的端点变成严重级别的漏洞。我将详细解释它的原理，分享我专门针对此漏洞的查找方法，并展示两个实际案例，说明这种方法如何发挥了巨大作用。

#

📖 什么是批量分配？

#

在现代 Web 开发中，框架（如 Ruby on Rails、Spring 或 NodeJS）试图通过自动将传入的 HTTP 请求数据（如 JSON 或表单参数）直接绑定到内部数据库对象来简化开发人员的工作。

批量赋值是指开发者允许用户更新对象，而没有明确定义哪些字段可以更新。如果数据库表包含 role 或 is_admin 列，且开发者没有进行过滤，攻击者只需在 JSON 请求体中传递 “role”:”admin” ，框架就会盲目地将其赋值。

💻 开发者常犯的错误（一个简单的代码示例）

以下是开发人员可能在 Node.js/Express 中意外引入此漏洞的方式：

// ❌ 易受攻击代码：将整个请求体传递至数据库app.put('/api/users/current', async (req, res) => {    try {        // 开发者期望 req.body 只包含 {"email"： "[email protected]"} 这样的内容        // 但框架却盲目地接受并更新我们所发送的任何内容！        await User.update(req.body, { where: { id: req.user.id } });        res.send("Profile updated!");    } catch (err) {        res.status(500).send("Error");    }});

为了解决这个问题，开发者应该使用允许列表，明确规定只有特定字段（如 email 或 bio ）才能更新。

🕵️‍♂️我的模糊测试方法

要找到这些隐藏参数，你必须在应用程序没有提示你查看的地方寻找。以下是我用来寻找隐藏参数的具体方法：

1. 遍历所有内容：我打开目标应用，手动点击应用中的每一个函数、链接和设置。目标是尽可能多地在 Burp Suite 历史记录中添加端点和参数。
2. 构建自定义词表： 我使用 GAP-Burp-Extension 扩展程序 。在工具选项中，我将其配置为从请求和响应中提取所有 JSON 参数以及 URL 路径。这样就构建了一个高度上下文相关、 针对特定目标的词表 。

3.模糊测试端点： 有了自定义字典后，我选择一个端点（GET、POST、PUT 等）。然后我在 Burp 中启动 Param Miner 。

• 如果是 GET 请求，我使用“猜测查询参数”。
• 如果是 POST/PUT 请求，我使用“猜测请求体参数”。

• 我加载我的 GAP 单词列表并让它运行。

#

🔥 情景一：死胡同 IDOR 演变为百万用户个人身份信息泄露

在参与一个公开漏洞赏金计划时，我花了不少时间来分析目标。最终，我偶然发现了一个类似这样的 GET 请求：

GET /api/v2/managers/{managerId}

我的第一反应自然是测试是否存在不安全的直接对象引用 (IDOR)。我将 {managerId} 替换为另一个用户的 ID，完全期望能看到他们的数据。

拒绝访问。

这个端点并不受标准 IDOR 攻击的影响。许多安全猎手会就此放弃，认为它是安全的。但我决定深入挖掘。我将请求发送给 Param Miner，加载了我用 GAP 生成的自定义字典，并开始模糊测试以查找隐藏的查询参数。

突然，Param Miner 收到一条消息： userId 。

我修改了请求，添加了隐藏参数：

GET /api/v2/managers/12345?userId=[VICTIM_ID]

砰！ 服务器返回了一个巨大的 JSON 对象，泄露了受害者的个人身份信息 (PII)。由于这个隐藏的批量赋值参数，我可以访问平台上数百万用户的全名和电子邮件地址。

🔥 场景 2：将批量赋值链接到 HTML 注入

#

这个目标有点棘手。该应用只允许用户通过 OAuth （Google/Apple）登录。因此，你在应用中的个人资料名称与你的 OAuth 用户名完全绑定，无法在用户界面中更改。

该应用有一个 “邀请”功能，用户可以发送电子邮件和自定义消息来邀请好友。我测试了消息字段的 HTML 注入漏洞，希望能让 <a> 标签出现在受害者的电子邮件中。邮件内容已正确过滤。

我靠在椅背上想：如果我改个名字，然后把 HTML 代码注入进去呢？邮件发送时，会显示“[我的名字]邀请”，然后代码就会触发！

我进入 “设置/帐户”页面，拦截了后台请求。我发现了一个用于更新次要帐户设置的 PUT 请求：

PUT /api/users/current

由于没有用户界面选项可以更改我的名字，我只好采用之前的方法。我使用 Param Miner 和我的 GAP 字典对这个 PUT 请求的 JSON 主体进行了模糊测试。

Param Miner 标记了一个隐藏参数： name 。

我拦截了该请求并注入了我的有效载荷：

PUT&nbsp;/api/users/currentHost: exmple.comContent-Type: application/json{&nbsp;&nbsp;"name":&nbsp;"<a href=\"evil.com\">click here to join</a>",...&nbsp; other_setting}

令我惊讶的是，服务器竟然接受了！由于开发者未能过滤允许更新的字段，批量赋值功能让我得以覆盖我受 OAuth 保护的用户名。当我发送邀请邮件时， HTML 注入完美地在受害者的收件箱中执行完毕。

感谢阅读！

请在评论区分享您的反馈意见，如有任何疑问 ，请随时告诉我。

祝你狩猎愉快！🏹

• X（推特）：

  @MaroineYoucefi

• LinkedIn：

  Merouane Youcefi

免责声明：

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

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

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

本文转载自：Rsec @0xuserm9 @0xuserm9《0140.隐藏的武器：我如何将批量任务转化为赏金》