🧠 前提
有些黑客攻击不需要零日漏洞、漏洞链或精英工具。
有时，您所需要的只是一个写得很差的auth.js、面向公众的 JavaScript 包，以及一点点好奇心。
这是一个关于前端 JavaScript 中暴露的 JWT 签名秘密如何让我获得实时生产系统的完全管理员访问权限的故事 — — 以及如何通过一行代码来避免这种情况.env。
🧭 第一阶段：典型的侦察，意外的宝藏
目标应用程序具有：
- 基于 JWT 的身份验证
- React 前端和 Node.js 后端
- 基本登录/注册、用户仪表板、管理面板（如果未授权则返回 403）
我像往常一样开始侦察——没有XSS，没有IDOR，也没有SSRF。于是我打开DevTools，开始梳理已加载的JS包。
curl https://target.com/static/js/main.ab13c7.js -o bundle.js
然后我搜索了关键词：secret，，，，token。jwtkeysign
就是这样：
// utils/auth.js const secret = "JWT_SUPER_SECRET_12345" ; // TODO：将其移动到 .env
🎯 这是真正的 HS256 签名密钥——公开、硬编码且可用。
🧬 第二阶段：代币解码与锻造
LocalStorage我以普通用户身份登录并通过 DevTools获取 JWT 令牌。
解码有效载荷：
"user":"testuser",
"role":"user"
}
现在，掌握了公开的秘密后，我使用 Node.js 伪造了一个新的令牌：
const jwt = require ( "jsonwebtoken" ); const token = jwt.sign ( { user : " admin" , role : "admin" }, "JWT_SUPER_SECRET_12345" , { algorithm : "HS256" } ); console.log (token) ;
将 LocalStorage 中现有的 JWT 替换为伪造的 JWT，刷新/admin...
💥 完全管理员权限。就是这样。
💣 第三阶段：升级以及我能接触到的东西
在管理面板内：
- 用户管理（重置密码、更改角色）
- PII 转储（电子邮件、联系信息、访问日志）
- 调试控制台（运行有限的内部查询）
- 审核工具（创建通知、触发 webhook）
- 通过所见即所得编辑器存储XSS注入点
无 IP 封锁。无 CAPTCHA。无服务器端声明验证。
JWT 令牌 = 访问。就是这样。
🎯 为什么会发生这种情况（而且经常发生）
- 开发人员误解 JWT 是灵丹妙药，认为只要签名了，就是安全的
- HS256（对称密钥）被广泛使用——但如果密钥泄露，游戏就结束了
- 前端代码通常会被最小化，但从未真正隐藏
- 团队忘记安全地从测试→生产→CI/CD 迁移机密
- 除了签名之外，后端几乎没有令牌验证
🛠️ 开发人员修复清单
如果你是一名正在阅读本文的开发人员，那么以下方法可以帮助你避免成为下一篇 Medium 文章：
- 🔒 永远不要在前端 JS 中硬编码机密
- 📦 使用
.env文件dotenv并保护 CI/CD 处理 - 🔁 定期轮换你的 JWT 机密
- 🔐 使用 RS256（非对称）签名代替 HS256
- ✅ 始终在后端验证声明（
role，user_id， ）scope - ⏱️ 设置到期时间并实现令牌撤销逻辑
🧠 最后的想法
这不是一份赏金报告，也不是一份实时渗透测试合同。
这仅仅是阅读大多数人忽略的内容的结果——并且相信最危险的漏洞往往隐藏在显而易见的地方。
JWT 就像签名的许可单。但是，当老师用 Sharpie 在黑板上签名后，每个人都能得到 A+。
原文始发于微信公众号（安全狗的自我修养）：JavaScript、JWT 和不应该存在的密钥
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论