文章总结： 本文分享了一次获两万三千美元赏金的漏洞挖掘过程。研究者通过篡改JWT令牌中的realm字段实现管理后台认证绕过，并利用服务端对Authorization头Bearer关键字校验不严的缺陷绕过API鉴权。最终结合文件上传接口触发AmazonS3与CloudFront的任意文件覆写漏洞，可篡改前端JS或EXE文件实施攻击。建议严格校验JWT声明、规范化认证头解析并限制S3文件覆写权限。 综合评分： 87 文章分类： SRC活动,实战经验,漏洞分析,WEB安全,云安全

得到$23000赏金的挖漏洞过程

原创

杜明 杜明

黑白之道

2026年7月8日 08:38 韩国

在小说阅读器读本章

去阅读

导语：本文分享了一起通过JWT认证机制缺陷配合文件上传功能，最终实现任意文件覆写的完整攻击链。该漏洞为研究者带来了总计23000美元的赏金，其中任意文件覆写单项获得20000美元。

一、背景

目标站点使用 JSON Web Token（JWT） 作为认证机制。用户登录主站后会获得一个普通用户的JWT令牌。

通过对目标进行详细侦察（包括JavaScript文件分析、Burp Suite抓包、 Wayback Machine历史端点收集以及子域名枚举），我发现了一个管理后台子域名 admin.test.com。

阅读后台的 app.js 文件（约20万行代码）后，确认其使用JWT认证，并发现了一个名为 test-dashboard 的realm（认证域）。

二、认证绕过（JWT Realm篡改）

2.1 原理

在 jwt.io 解码普通用户令牌后，发现其中包含 realm=test-user 字段。由于服务端仅验证JWT签名是否有效，未对realm进行严格校验，我尝试将realm值修改为 test-dashboard。

2.2 利用步骤

1. 登录主站 test.com 获取普通用户JWT
2. 拦截登录API请求 /api/v1/login，修改请求体中的realm值

构造请求：

POST /api/v1/login HTTP/1.1
Host: accounts.test.com
Content-Type: application/json

{"email":"[email protected]","password":"<password>","realm":"test-dashboard"}

解码修改后的JWT，可见realm已被成功篡改为 test-dashboard：

使用篡改后的JWT令牌，成功登录管理后台。但厂商认为管理后台仅为前端React应用，实际API有独立认证，因此将漏洞等级从严重降至中危：

三、授权头绕过（Bearer关键字删除）

3.1 Fuzzing发现

为提升漏洞严重程度，我继续深入分析。由于已能控制JWT中的realm，需找到能操作API的方式。

对管理后台 /upload 接口进行 fuzzing 测试。默认情况下ffuf使用GET方法，切换为POST后发现了该上传接口。

3.2 关键发现

在Fuzzing Authorization: Bearer  时，删除 Bearer 关键字后收到200响应。

构造请求（删除Bearer）：

POST /upload HTTP/1.1
Host: admin.test.com
Authorization: <JWT>
Content-Type: multipart/form-data; boundary=----WebKitFormBoundarypxxxxxx

------WebKitFormBoundarypxxxxxx
Content-Disposition: form-data; name="destination"gallery/
------WebKitFormBoundarypxxxxxx
Content-Disposition: form-data; name="file"; filename="poc.txt"
Content-Type: Text/plainh4x0r-dz POC
------WebKitFormBoundarypxxxxxx--

成功获得上传响应：

四、文件路径发现

上传成功后面临新问题：如何找到文件存储路径？

通过分析Burp Suite历史记录和响应头，发现返回的href指向：https://xxxxxxxx.cloudfront.net/gallery/xxxxxxxxx

其中 gallery 与上传请求中 destination 参数值相同。访问 https://XXXXXXXXX.cloudfront.net/gallery/poc.txt 确认文件可被访问。

由于上传功能托管于Amazon CloudFront CDN，无法直接上传WebShell，单独报告此漏洞严重程度较低。

五、任意文件覆写（Arbitrary File Overwrite）

5.1 漏洞原理

Amazon S3在默认配置下存在任意文件覆写风险。当S3桶允许上传已有文件名时，攻击者可覆盖关键文件。

分析发现 xxxxxxxx.cloudfront.net 用于托管主站的JavaScript、HTML、Windows软件及PDF文件。这意味着我可以修改这些文件内容。

5.2 攻击利用

主站通过CloudFront CDN加载资源文件。攻击者可利用任意文件覆写：

• 修改JavaScript文件，插入恶意代码实现存储型XSS
• 篡改可执行文件（.exe）或PDF，植入木马控制用户主机

初始POC文件内容：

通过以下请求覆写 poc.txt 内容为 “Arbitrary File Overwrite”：

POST /upload HTTP/1.1
Host: admin.test.com
Authorization: <JWT>
Content-Type: multipart/form-data; boundary=----WebKitFormBoundarypxxxxxx

------WebKitFormBoundarypxxxxxx
Content-Disposition: form-data; name="destination"gallery/
------WebKitFormBoundarypxxxxxx
Content-Disposition: form-data; name="file"; filename="poc.txt"
Content-Type: Text/plainArbitrary File Overwrite
------WebKitFormBoundarypxxxxxx--

命令行验证确认文件内容已被成功覆写：

六、漏洞总结与赏金

| 漏洞类型 | 赏金金额 | | — | — | | 管理后台UI访问（JWT realm篡改） | $3,000 | | 任意文件覆写 | $20,000 | | 总计 | $23,000 |

七、关键发现

• JWT realm字段可被篡改：部分应用仅验证JWT签名，不校验claim值的合法性
• Authorization头Bearer关键字可省略：部分服务端对认证头格式校验不严格
• S3/CloudFront默认配置存在文件覆写风险：即使无法上传WebShell，通过覆写现有资源文件同样可造成严重危害
• Fuzzing是挖掘此类漏洞的关键手段：本文中删除”Bearer”关键字的发现即源于系统化fuzzing测试

版权声明：本文由华盟网原创发布，保留所有权利。配图由华盟网授权使用。

👇 点击阅读原文，访问我的网站

免责声明：

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

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

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

本文转载自：黑白之道 杜明 杜明《得到$23000赏金的挖漏洞过程》