JWT垂直越权漏洞实战：从原理到Polar靶场攻防演练

1. 项目概述与核心思路

最近在Polar靶场里折腾一个关于JWT垂直越权的实战场景，感觉挺有意思的。这个靶场模拟了一个典型的Web应用，核心目标是从一个普通用户（user）的权限，通过分析和篡改JWT令牌，最终拿到管理员（admin）的权限，从而访问后台获取Flag。整个过程就像一次精细的“权限升级手术”，考验的是对JWT机制的理解和漏洞利用的实操能力。如果你正在学习Web安全，尤其是身份认证和授权相关的漏洞，这个案例能帮你把JWT的原理、常见错误配置以及如何利用这些配置失误串起来，形成一个完整的攻击链。

简单来说，JWT（JSON Web Token）是现代Web应用里非常流行的一种无状态身份认证机制。它由三部分组成：头部（Header）、载荷（Payload）和签名（Signature）。服务端签发令牌后，客户端在后续请求中携带这个令牌，服务端通过验证签名来确认令牌的合法性和完整性。听起来很安全对吧？但问题往往出在实现细节上。在这个Polar靶场的案例里，漏洞的根源就在于服务端对JWT的验证存在缺陷，可能没有严格校验签名，或者签名密钥过于简单可被爆破，导致攻击者能够篡改载荷中的关键信息（比如用户角色标识），从而实现垂直越权。

这个实战过程会涉及几个关键步骤：首先是信息收集和初始访问，找到普通用户的登录凭证；然后是分析当前会话的JWT令牌结构；接着是识别漏洞点，可能是弱密钥、无签名验证或者算法混淆；最后是构造一个拥有管理员权限的新令牌并替换，完成越权访问。下面，我就结合Polar靶场的具体环境，把每一步的操作、背后的原理以及我踩过的坑，详细拆解一遍。

2. JWT垂直越权漏洞原理深度剖析

在动手之前，我们必须把JWT垂直越权的原理吃透，这样才能知道每一步操作在“打”什么，以及为什么能成功。很多人一上来就照着步骤做，做完还是云里雾里，遇到变种场景就又不会了。

2.1 JWT令牌的结构与安全基石

一个标准的JWT令牌看起来像这样：eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyIn0.xxx。它由三个用点号分隔的Base64Url编码字符串组成。

第一部分是头部（Header），通常包含令牌类型（typ: "JWT"）和签名算法（alg），比如HS256（HMAC SHA-256）。这个部分经过Base64Url编码，但本身没有加密，任何人都可以解码查看。在Polar靶场的例子里，解码后我们能看到{"alg":"HS256"}，这告诉我们服务端使用HS256算法来生成和验证签名。

第二部分是载荷（Payload），包含了所谓的“声明”（Claims）。声明有三种类型：

• 注册声明：预定义的一些标准字段，如iss（签发者）、exp（过期时间）、sub（主题，通常放用户名）。
• 公共声明：可以自定义，但为避免冲突应使用抗冲突的名字。
• 私有声明：开发者为了业务需要自定义的字段，比如这个靶场里的login_user_key，用来标识当前登录的用户。

载荷同样只是Base64Url编码，没有加密。这意味着，只要拿到令牌，任何人都能轻松解码并看到里面的内容。攻击者篡改权限，主要就是针对这个部分下手。

第三部分是签名（Signature）。这是JWT安全性的核心。签名的生成方式依赖于头部中声明的算法。对于HS256，签名是这样生成的：HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret_key)服务端用同样的密钥和算法对收到的Header和Payload重新计算一次签名，如果计算结果与令牌中的Signature部分一致，就证明令牌在传输过程中没有被篡改，并且确实是使用正确的密钥签发的。

2.2 漏洞产生的常见场景

垂直越权漏洞的产生，本质上是因为JWT的安全机制在某个环节被绕过或削弱了。结合Polar靶场和常见情况，主要有以下几种：

1. 签名验证缺失或逻辑错误：这是最致命的一种。服务端在验证JWT时，可能因为开发人员疏忽，只解码了Payload读取用户信息，却没有验证Signature，或者验证逻辑存在缺陷（比如验证失败后仍然信任Payload）。在这种情况下，攻击者可以直接修改Payload（如把sub: "user"改成sub: "admin"），然后重新组装一个令牌（因为签名不对，但服务端不检查），就能轻松实现越权。Polar靶场的情况更典型一些，属于下面第二种。

2. 弱密钥或密钥泄露：当使用HMAC（如HS256）这类对称加密算法时，签名和验证使用同一个密钥（secret_key）。如果这个密钥设置得过于简单（比如123456、secret、password），攻击者就可以通过暴力破解或字典攻击的方式猜解出来。一旦密钥泄露，攻击者就可以用正确的算法和密钥，为任何他想要的Payload生成合法的签名，从而签发一个完全受控的、服务端会认可的高权限令牌。Polar靶场最终就是爆破出了弱密钥。

3. 算法混淆攻击：JWT头部中的alg字段本应指定签名算法。但如果服务端代码存在缺陷，可能会信任客户端提供的alg值。攻击者可以将alg改为none（如果服务端配置允许“none”算法），或者从非对称算法（如RS256）改为对称算法（如HS256）。在后者的情况下，攻击者可以利用服务端用于验证RS256签名的公钥，作为HS256的密钥，来伪造一个有效的签名。这种攻击对代码逻辑的要求更高。

4. 敏感信息泄露与逻辑缺陷：Payload中的自定义字段如果包含了权限标识（如role: "admin",isAdmin: true），而服务端完全依赖这个字段做权限判断，那么一旦签名被绕过，这个字段就成了攻击的直接目标。此外，如果密钥硬编码在客户端代码中，也可能被逆向工程获取。

核心心法：JWT的安全完全建立在签名验证的可靠性上。任何导致签名验证失效或密钥可控的环节，都是潜在的突破口。我们的攻击思路，永远是围绕“如何让服务端接受一个我们篡改过Payload的令牌”来展开的。

3. Polar靶场实战：从普通用户到管理员的完整攻防链

理论清楚了，我们进入实战环节。我会模拟在Polar靶场中的完整攻击流程，并穿插讲解每个步骤的意图和可能遇到的变数。

3.1 环境探测与初始凭证获取

首先，我们访问靶场提供的Web应用地址。通常是一个登录界面。尝试使用常见的弱口令（admin/admin, user/user等）进行登录，大概率会失败，但这有助于我们了解登录接口的请求格式。

根据参考的实战记录，靶场可能存在一个默认用户user，但密码未知。这时，我们需要进行密码爆破。

1. 抓取登录请求包：在浏览器中打开开发者工具（F12），切换到Network（网络）标签页，勾选“Preserve log”（保留日志）。在登录框输入用户名user和一个任意密码（如test），点击登录。在网络请求列表中，找到向/login或类似路径发送的POST请求。

2. 分析请求结构：查看该请求的详情，通常请求体是JSON格式，如{"username":"user","password":"test"}。同时，注意观察响应。如果密码错误，响应可能是{"code": 400, "message": "密码错误"}；如果用户不存在，可能是{"code": 404, "message": "用户不存在"}。区分这两种响应，对于精准爆破至关重要。

3. 实施密码爆破：将捕获到的登录请求包发送到Burp Suite的Intruder模块。在Positions标签页，清除所有自动标记，只将password字段的值test标记为攻击载荷位置。在Payloads标签页，加载一个常用的弱口令字典（如rockyou.txt的简化版，或自定义的123456、password、123123等）。在Options标签页，根据之前观察的响应，设置Grep - Match规则来识别成功的登录。例如，如果成功登录的响应中包含"success": true或跳转到了/dashboard，就以此作为判断依据。

4. 获取有效凭证：启动攻击，Intruder会遍历字典尝试所有密码。很快，我们就会发现当密码为123456时，响应状态码或内容与其他尝试不同（例如返回了200 OK和一个JSON Web Token）。至此，我们获得了初始凭证：user / 123456。

实操心得：在实际测试中，登录失败和成功的响应差异可能很微妙。有时成功登录后服务端会设置一个Cookie（JWT），而失败不会。因此，在Burp Intruder的Grep - Extract功能中，可以尝试提取响应中Set-Cookie头部的值，如果提取到内容，则很可能代表登录成功。这是比单纯看HTTP状态码更可靠的方法。

3.2 JWT令牌捕获与结构分析

使用获取到的凭证user:123456成功登录系统。登录后，应用通常会跳转到用户主页。此时，我们再次打开开发者工具的Network标签页，刷新页面，查看任意一个后续请求（比如获取用户信息的API请求）。

关键的一步来了：找到身份凭证。在请求的Headers中，寻找Authorization头（其值通常为Bearer <token>）或者Cookie头。在这个Polar靶场案例中，身份令牌是放在Cookie里的。你会看到一个名为token、auth或类似名称的Cookie，其值就是一长串看起来像eyJ...的JWT字符串。把它复制出来。

接下来，我们需要解码并分析这个令牌。你可以使用在线工具（如 jwt.io ），但更推荐使用Burp Suite的扩展（如JWT Editor）或本地命令行工具，避免敏感信息外泄。

以在线工具jwt.io为例：

1. 将完整的JWT令牌粘贴到左侧的“Encoded”输入框。
2. 工具会自动在右侧的“Decoded”部分将其解析为Header和Payload。
3. 查看解析结果：
   • Header:{"alg": "HS256", "typ": "JWT"}。这确认了签名算法是HS256。
   • Payload:{"login_user_key": "user", "iat": 163xxxxxx, "exp": 163xxxxxx}。这里包含了关键信息：login_user_key字段的值为user，这很可能就是服务端用来识别当前用户的字段。此外还有令牌签发时间（iat）和过期时间（exp）。

这个结构清晰地告诉我们：只要我们能生成一个签名有效、且login_user_key字段值为admin的JWT，服务端就可能把我们当作管理员。现在的挑战是：如何生成一个有效的签名？

3.3 密钥爆破与令牌伪造

由于算法是HS256，我们需要知道签名密钥（secret）才能伪造签名。如果密钥强度足够（长度长、随机性强），爆破几乎不可能。但现实中，开发人员可能设置弱密钥。Polar靶场就模拟了这种情况。

我们有几种方法来尝试获取或破解这个密钥：

1. 使用专用工具爆破：这是最直接的方法。我们可以使用hashcat或john这类密码破解工具，配合强大的字典（如rockyou.txt）来爆破。命令示例：

   # 将JWT令牌保存到文件 jwt.txt echo "eyJhbGciOiJIUzI1NiJ9.eyJsb2dpbl91c2VyX2tleSI6InVzZXIifQ.IKiUadJl6hUuSCnD38CVuIsl-BnGEkSEEECoDpHtFpU" > jwt.txt # 使用hashcat，模式16500对应JWT hashcat -m 16500 jwt.txt /usr/share/wordlists/rockyou.txt

   如果密钥在字典中，hashcat会很快跑出来。

2. 利用Burp Suite扩展：安装Burp Suite的“JWT Editor”扩展。在Proxy -> HTTP history中找到携带JWT的请求，右键选择“JWT Editor” -> “Attack” -> “Brute-force secret”。扩展会使用内置的常见弱密钥列表进行爆破，速度很快。在Polar靶场中，用这个方法几乎瞬间就能爆出密钥是123456。

3. 基于已知信息的猜测：在CTF或一些简单的靶场中，密钥可能与应用名、公司名、secret、password、123456等相关。可以手动尝试几个。

一旦成功爆破出密钥（123456），我们就拥有了伪造令牌的全部条件。

伪造管理员令牌：

1. 在jwt.io或JWT Editor中，保持Header不变（{"alg": "HS256", "typ": "JWT"}）。
2. 修改Payload，将login_user_key的值从user改为admin。注意，不要修改iat和exp，除非你想模拟一个“新签发”的令牌（可能需要调整时间戳）。
3. 在“VERIFY SIGNATURE”区域，输入我们爆破得到的密钥123456。
4. 工具会自动使用这个密钥和HS256算法，为新的Header和Payload生成一个合法的签名。左侧的Encoded JWT会实时更新为一串新的令牌字符串。

现在，我们得到了一个“合法”的管理员令牌。它的Payload声明我们是admin，并且签名经得起服务端的验证。

3.4 权限提升与Flag获取

最后一步，就是用我们伪造的令牌去“欺骗”服务端。

1. 替换令牌：回到浏览器，打开开发者工具，进入Application（应用）或Storage（存储）标签页，找到Cookies。将当前站点的对应JWT Cookie的值，修改为我们刚刚生成的新令牌字符串。
2. 访问特权功能：刷新页面。如果漏洞存在，页面可能会发生明显变化：用户昵称变成了“admin”，侧边栏出现了原本不可见的“系统管理”、“用户管理”等管理员菜单。
3. 寻找Flag：根据提示（“Flag在管理员后台”或“在admin用户的备注里”），我们进入用户管理页面。在用户列表中找到admin用户，点击编辑或查看详情。在详情页的“备注”或“描述”字段中，就能找到最终的Flag，通常是一串由字母数字组成的字符串，格式如flag{xxxx-xxxx-xxxx}或polar{...}。

至此，一次完整的JWT垂直越权攻击就完成了。我们从信息收集开始，通过密码爆破获得低权限账户，分析其JWT令牌结构，爆破弱密钥，最终伪造高权限令牌，成功实现了从user到admin的权限跃迁。

4. 漏洞的深度利用与高级技巧

上面的流程是基础版本。在实际的安全测试或更复杂的靶场中，可能会遇到一些变种和加固场景。掌握以下技巧能让你更从容。

4.1 应对签名验证的几种情况

服务端对JWT的验证逻辑可能不同，我们需要灵活应对：

• 情况一：服务端完全不验证签名。这是最低级的错误。我们甚至不需要爆破密钥，直接修改Payload后，把签名部分删除或者改成任意字符串，服务端可能都会接受。在Burp Repeater中尝试发送修改后的令牌，如果依然返回成功，就证实了这一点。
• 情况二：服务端使用非对称算法（如RS256）。这时签名密钥（私钥）和验证密钥（公钥）是不同的。我们很难拿到私钥。但可以尝试“算法混淆攻击”：将Header中的alg改为HS256，然后尝试用已知的公钥（有时会暴露在/jwks.json端点）作为HMAC的密钥来伪造签名。这需要服务端存在相应的逻辑漏洞。
• 情况三：密钥不是固定值，而是动态的或与用户相关。有些设计会用用户的密码哈希的一部分作为JWT的密钥。这种情况下，即使你爆破出了user的密码并登录，也无法直接伪造admin的令牌，因为不知道admin的密码。这时可能需要结合其他漏洞，如SQL注入先获取管理员密码哈希。

4.2 工具链的熟练使用

工欲善其事，必先利其器。除了Burp Suite，以下工具能极大提升效率：

• jwt_tool：一个功能强大的命令行JWT测试工具。它可以解码、验证、伪造、爆破JWT，支持多种攻击方式（如CVE-2015-9235、CVE-2016-10555等）。

  # 解码令牌 python3 jwt_tool.py eyJhbGciOiJIUzI1NiJ9.eyJsb2dpbl91c2VyX2tleSI6InVzZXIifQ.IKiUadJl6hUuSCnD38CVuIsl-BnGEkSEEECoDpHtFpU # 爆破密钥 python3 jwt_tool.py eyJ... -C -d /path/to/wordlist.txt # 伪造令牌（如果已知密钥） python3 jwt_tool.py eyJ... -S hs256 -p "123456" -T

• Burp Suite JWT Editor扩展：如前所述，它集成在Burp中，方便在拦截的请求上直接进行解码、编辑、签名和攻击，无需在多个工具间切换。
• 浏览器插件：如JWT Debugger，可以方便地在浏览器中实时解码和编辑Cookie中的JWT，对于快速测试非常有用。

4.3 自动化攻击脚本编写

对于需要批量测试或集成到自动化扫描流程中的场景，可以编写简单的Python脚本。

import jwt import requests import base64 import json import sys def decode_jwt(token): """解码JWT，不验证签名""" try: # 分割令牌 parts = token.split('.') if len(parts) != 3: print("无效的JWT格式") return None, None # 解码头部和载荷 header = json.loads(base64.urlsafe_b64decode(parts[0] + '==').decode('utf-8')) payload = json.loads(base64.urlsafe_b64decode(parts[1] + '==').decode('utf-8')) return header, payload except Exception as e: print(f"解码失败: {e}") return None, None def brute_force_secret(token, wordlist_path): """暴力破解JWT密钥（HS256）""" header, payload = decode_jwt(token) if not header or header.get('alg') != 'HS256': print("非HS256算法或不支持的令牌") return None with open(wordlist_path, 'r', encoding='utf-8', errors='ignore') as f: for line in f: secret = line.strip() try: # 尝试用当前密钥验证签名 decoded = jwt.decode(token, secret, algorithms=['HS256']) print(f"[+] 密钥破解成功: {secret}") return secret except jwt.InvalidSignatureError: continue except Exception as e: # 其他错误（如过期），但签名验证通过了，也说明密钥正确 if "signature" in str(e).lower(): continue else: print(f"[*] 使用密钥 '{secret}' 时出现其他错误: {e}") return secret print("[-] 密钥破解失败") return None def forge_admin_token(original_token, secret, admin_username='admin'): """伪造管理员令牌""" header, payload = decode_jwt(original_token) if not header or not payload: return None # 修改载荷中的用户标识字段，这里假设字段名是'login_user_key'，根据实际情况修改 payload['login_user_key'] = admin_username # 可选：移除或更新过期时间，避免立即过期 # if 'exp' in payload: # payload['exp'] = int(time.time()) + 3600 # 设置为1小时后过期 try: new_token = jwt.encode(payload, secret, algorithm=header['alg'], headers=header) return new_token except Exception as e: print(f"令牌伪造失败: {e}") return None # 使用示例 if __name__ == "__main__": # 替换为你的靶场令牌和字典路径 target_token = "eyJhbGciOiJIUzI1NiJ9.eyJsb2dpbl91c2VyX2tleSI6InVzZXIifQ.IKiUadJl6hUuSCnD38CVuIsl-BnGEkSEEECoDpHtFpU" wordlist = "common_secrets.txt" print("[*] 开始破解密钥...") found_secret = brute_force_secret(target_token, wordlist) if found_secret: print(f"[*] 发现密钥: {found_secret}") print("[*] 尝试伪造管理员令牌...") admin_token = forge_admin_token(target_token, found_secret) if admin_token: print(f"[+] 伪造的管理员令牌:\n{admin_token}") # 这里可以添加自动替换Cookie并访问管理员页面的逻辑 # session = requests.Session() # session.cookies.set('auth_token', admin_token, domain='target.com') # resp = session.get('https://target.com/admin') # print(resp.text) else: print("[-] 令牌伪造失败") else: print("[-] 未找到有效密钥")

这个脚本提供了基本的解码、爆破和伪造功能。在实际使用中，需要根据靶场的具体JWT字段名（不一定是login_user_key）进行调整。

5. 防御方案与开发安全建议

作为攻击者，我们研究漏洞；作为开发者或安全人员，我们更要懂得如何防御。针对JWT垂直越权，以下是一些核心的防御措施：

1. 使用强密钥并安全存储：对于HS256等对称算法，密钥必须足够长（建议至少32字节）、随机且复杂。绝对禁止使用123456、secret等弱密钥。密钥应作为机密信息，存储在环境变量或安全的密钥管理服务中，绝不能硬编码在客户端代码或配置文件中。

2. 强制验证签名且逻辑严谨：在服务端验证JWT时，必须强制校验签名。任何签名无效或验证失败的令牌，必须立即拒绝，并返回401 Unauthorized。验证逻辑要放在所有业务逻辑之前。

3. 采用非对称算法（如RS256）：在生产环境中，优先使用RS256等非对称算法。私钥用于签发令牌，并严格保护在服务端；公钥用于验证令牌，可以安全地分发给需要验证的组件。这样即使公钥泄露，攻击者也无法伪造签名。

4. 避免在Payload中存放敏感权限信息：JWT的Payload是Base64编码，并非加密。不要将用户的角色（如role: "super_admin"）、权限列表等敏感信息直接放在Payload里。权限信息应在服务端数据库或缓存中关联用户ID进行查询。Payload中只存放最低必要信息，如用户ID（sub）和过期时间。

5. 设置合理的令牌有效期：使用exp（Expiration Time）声明为JWT设置一个较短的有效期（如15-30分钟）。结合Refresh Token机制来获取新的Access Token，减少令牌泄露后的风险窗口。

6. 实施令牌黑名单/白名单：对于关键操作或需要立即撤销权限的场景（如用户登出、密码修改），可以实现一个轻量级的令牌黑名单机制（存储已撤销但未过期的令牌IDjti），或者在验证时检查令牌是否在有效白名单中。

7. 对算法进行显式声明和限制：在验证JWT时，不要依赖客户端提供的alg头。代码中应显式指定期望的算法列表（如只允许RS256），防止算法混淆攻击。

8. 进行安全的代码审查和依赖管理：定期审查身份认证相关的代码。确保使用的JWT库是最新版本，避免使用存在已知漏洞的旧版本库。

6. 常见问题排查与实战避坑指南

在实际操作中，你可能会遇到一些意料之外的情况。这里记录了几个我踩过的坑和解决方法：

问题1：替换了伪造的JWT Cookie，但页面没变化，或者提示“登录已过期”。

• 可能原因A：Payload字段名不对。服务端可能不是通过login_user_key来识别用户，而是username、sub、user_id等其他字段。你需要仔细分析原始低权限用户的JWT Payload，找到那个唯一标识用户的字段名。
• 可能原因B：令牌过期。检查原始令牌的Payload，是否有exp字段。如果有，并且时间已经过期，那么即使签名正确，服务端也会拒绝。在伪造令牌时，需要将exp字段的值更新为一个未来的时间戳（Unix时间戳，单位秒）。
• 可能原因C：签名密钥错误。确认你爆破出的密钥确实是正确的。可以用这个密钥尝试重新为原始令牌（未修改的）计算签名，看是否能得到完全一样的原始签名。如果不能，说明密钥不对。
• 可能原因D：存在额外的验证。服务端可能不仅验证JWT，还会在数据库或会话中检查用户状态。仅仅修改JWT可能不够。

问题2：爆破密钥时，字典跑完了也没出结果。

• 对策：尝试更大的字典，如rockyou.txt。考虑密钥可能不是单词，而是与项目名、域名、公司名相关的字符串，或者是简单的数字序列。也可以尝试使用hashcat的掩码攻击模式，如果怀疑密钥是6位数字，可以用hashcat -m 16500 jwt.txt -a 3 ?d?d?d?d?d?d。

问题3：JWT被放在HTTP请求头的Authorization字段里，格式是Bearer <token>，如何方便地修改和测试？

• 对策：Burp Suite的Repeater模块可以完美处理。在Proxy拦截到请求后，发送到Repeater。在Repeater的请求框中，直接修改Authorization: Bearer eyJ...后面的令牌字符串即可。结合JWT Editor扩展，可以一键解码、编辑、重新编码并更新请求头。

问题4：在真实渗透测试中，如何高效地发现JWT漏洞点？

• 侦察阶段：登录应用后，检查所有Cookie和Authorization头，寻找eyJ开头的字符串。使用浏览器插件或Burp扩展快速解码，观察Payload结构。
• 测试阶段：
  1. 签名删除测试：将JWT的签名部分（第三个点号后的部分）删除，或者改成任意字符（如aaa），发送请求，看服务端是否接受。
  2. 算法置空测试：将Header中的alg改为none或None，同时清空签名部分，发送请求。
  3. 弱密钥测试：使用工具和常见弱密钥字典进行爆破。
  4. Payload篡改测试：在已知密钥或签名验证缺失的情况下，尝试修改Payload中的用户ID、角色字段。

最后想说的是，JWT本身是一个优秀的规范，绝大多数安全问题都源于不正确的实现和配置。这个Polar靶场的实战，就像一把钥匙，帮你打开了理解Web身份认证漏洞的一扇门。真正掌握它，不仅要会利用，更要懂原理和防御，这样才能在安全这条路上走得更稳更远。下次遇到JWT，不妨多花几分钟，想想它的签名是否真的牢不可破。