JWT 认证机制下的越权漏洞分析与渗透测试实践
1. 背景介绍
在现代企业级应用架构中，单点登录（SSO）已成为主流的身份认证方案。用户通过统一的身份源进行登录，随后访问多个子系统时通常采用无状态令牌（如 JWT, JSON Web Token）进行会话管理。这种架构虽然提升了用户体验和系统解耦能力，但也引入了新的安全风险。
本文基于一次真实的渗透测试案例，深入分析在 SSO 集成场景下，由于 JWT 校验逻辑缺陷导致的越权访问漏洞。该案例涉及 Oracle WebCenter 作为统一认证入口，下游业务系统依赖 JWT 进行资源访问控制。通过对请求流程的抓包分析和签名验证逻辑的逆向推导，我们发现了 UID 与 Token 绑定不严格的问题，并实现了任意用户的权限提升。
2. JWT 基础理论
JSON Web Token (JWT) 是一种开放标准 (RFC 7519)，用于在各方之间安全地传输信息。JWT 由三部分组成，使用点号分隔：
- Header (头部)：包含令牌类型（typ）和签名算法（alg）。常见的算法包括 HMAC SHA256 (HS256)、RSA (RS256) 等。
- Payload (载荷)：包含声明（claims），如用户 ID、角色、过期时间等敏感信息。
- Signature (签名)：对前两部分进行加密生成的哈希值，用于防止数据篡改。
一个典型的 JWT 结构如下所示：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
2.1 常见攻击向量
在安全审计中，针对 JWT 的攻击主要集中在以下三个方面：
- 未校验签名：服务器配置错误，完全忽略签名验证步骤，直接解析 Payload 中的内容。攻击者可修改 Payload 中的任意字段（如
sub或role）并重放。 - 禁用 Hash (Alg: None)：利用某些 JWT 库实现的不规范行为，将 Header 中的
alg字段修改为none。如果服务端未强制校验签名算法，可能会接受空签名的 Token。 - 弱密钥爆破：如果签名使用的密钥（Secret Key）过于简单，攻击者可通过字典攻击或暴力破解获取密钥，从而伪造合法签名。
3. 漏洞场景复现
本次测试的目标系统采用 SSO + JWT 的混合架构。用户首先通过 Oracle WebCenter 进行身份认证，获取 Session 后，再调用内部 OAM 接口换取子系统的 JWT Token。整个流程分为以下几个关键步骤：
3.1 认证流程分析
- SSO 登录：用户在 WebCenter 输入凭证，通过后获得有效的 Session Cookie。
- Token 申请：前端携带 Session Cookie 请求 OAM 接口，后端验证 Session 有效性后，生成并返回 JWT Authorization Token。
- 资源访问：前端在后续请求的 Header 中携带该 JWT Token，后端验证 Token 合法性后返回用户数据。
3.2 漏洞发现
在分析第三个包的响应数据时，我们发现返回的 JSON 中包含 UID 字段，且该字段并未被包含在 JWT 的 Payload 中进行签名保护，或者服务端在验证时仅校验了 Token 格式而未校验 Token 内信息与当前请求参数的匹配度。
具体表现为：攻击者可以截获一个合法用户的 JWT Token，然后修改请求参数中的 UID 为其他用户的 ID。由于服务端未将 UID 与 Token 中的 sub 或自定义 Claim 进行强一致性校验，导致服务器接受了非法的 UID 映射，从而返回了非授权用户的数据。
3.3 越权验证
通过遍历不同的 UID 值，攻击者可以批量获取系统中所有用户的敏感信息，包括但不限于账户基本信息、未读消息、菜单权限及操作按钮等。这种水平越权漏洞使得低权限用户可以完全接管高权限账户的功能视图。
