用途
本技能面向授权安全评估场景，帮助测试人员发现和验证 JWT（JSON Web Token）实现中的密码学失效问题。JWT 由 header、payload、signature 三段 base64url 组成，签名是防止篡改载荷的唯一屏障。当验证器可被欺骗接受伪造令牌时，攻击者可能冒充其他用户或管理员，风险等级为高/严重。
主要能力
技能涵盖以下技术方向：
-
侦察：识别应用是否使用 JWT，例如登录响应中的 token 字段、Set-Cookie、Authorization: Bearer 头、JWKS 端点（/.well-known/jwks.json 等）。解码头部第一段判断算法，"alg":"RS256" 时尝试密钥混淆，任何算法都优先尝试 alg:none。
-
令牌伪造：
- alg:none：将头部改为 {"alg":"none","typ":"JWT"}，删除签名（保留末尾点），编辑载荷（如 role:"admin" 或他人 id/email）。部分验证器拒绝小写 none，可尝试 None/NONE/nOnE 变体。
- RS256 → HS256 密钥混淆：获取服务器 RSA 公钥 PEM（来自 JWKS 端点、JS 包或从两个捕获令牌恢复），用该 PEM 作为 HMAC 密钥以 HS256 重签编辑后的载荷。jwt_tool 命令：
jwt_tool <token> -X k -pk public.pem。 - kid 头注入：验证器从 kid 指定的文件加载 HMAC 密钥时，可设置 kid 为路径遍历（如 ../../../../../../../dev/null），用空密钥签名 HS256。kid 也可能携带 SQLi、命令注入或 SSRF。
- jku/x5u 头注入（RS256）：在验证器可访问的服务器上托管自己的 JWKS，将令牌 jku 或 x5u 头设为该 URL，用自己私钥签名。若存在主机白名单，可尝试结合开放重定向或 SSRF 路径。
- jwk 头自签名密钥注入（RS256）：在头部嵌入攻击者控制的公钥（{"alg":"RS256","jwk":{...}}），用匹配私钥签名。当验证器不校验密钥来源或白名单时有效。
-
时间声明操纵：删除 exp 声明，或将 nbf 设为过去、exp 设为远未来（如 2099 年），绕过时间验证。
-
跨租户声明注入：识别 org_id、tenant、account_id、workspace_id、customer_id 等租户声明，修改为其他租户的值。需注意修改声明会破坏正确验证的签名，此技术应在确定修改后令牌可被接受或获得授权测试签发者后作为授权测试进行。
-
离线弱 HMAC 密钥破解：对 HS256 令牌使用 Hashcat（模式 16500）或 jwt_tool 内置字典破解，成功后用该密钥伪造任意令牌。
-
自动化攻击：使用 jwt_tool 自动尝试多种伪造模式（
jwt_tool <token> -X a），或 Nuclei 扫描 JWT 漏洞（nuclei -u <target_url> -t jwt/ -timeout 10s）。
使用方式
技能强制要求确认门：在运行任何探测、利用、更改、持久化、数据提取或凭据访问命令前，必须让用户明确陈述目标 URL/IP/账户/资源，确认书面授权和允许范围，展示确切命令并解释预期效果，等待当前对话中的明确确认。未确认时保持只读，仅提供防御性指导。建议在沙箱、一次性虚拟机或受控实验室中操作。
伪造令牌时应使用专用工具（jwt_tool、Burp JWT Editor 扩展或 PyJWT），不要手动编码 base64。载荷形状应匹配应用真实令牌，保留声明名称，仅改身份/角色。
适用场景
适用于获得明确书面授权的漏洞赏金或渗透测试任务，且任务匹配该漏洞类别或技术。用于验证 JWT 密码学失效是否可导致身份或权限提升。
限制
- 仅限授权范围，确认门为强制步骤。
- 仅导入文档，上游辅助脚本、命令、引擎和研究资产未捆绑，需要时从源仓库重新安装工具。
- 所有发现需在报告前验证（参见 triage-validation），并通过 report-writing 报告。
- 应使用最小侵入性证明：两个受控测试身份/租户和只读金丝雀资源，区分签名伪造成功与实际授权绕过。不得删除用户、更改角色、枚举无关账户或暴露真实邮箱。
- 报告中应编辑掉 bearer 令牌、密钥和个人数据，不得发布可复用的伪造令牌。遇到意外访问真实用户数据时应停止并通过约定渠道报告。
- alg:none 被拒（401）仅表示该缺陷已修补，应继续尝试密钥混淆后再下结论。