JWT 应该是Web安全里老生常谈的话题了，但“为什么总能被伪造”这个问题，我问过不少开发，能答上来的真不多。每次做渗透测试遇到JWT相关接口，随手改个alg改成none或者HS256一把梭就能打穿，说明很多人只是把JWT当成一个“会签名的token”来用，根本没搞懂签名背后的信任边界在哪里。这篇文章我打算从Burp Labs的JWT靶场出发，把签名验证、Header注入、算法混淆这三个最经典的绕过手法从头到尾拆一遍，每一招都会配上实操步骤和踩坑记录，希望能帮你在下次代码审计或渗透测试时少走弯路。无论你是写接口的后端开发，还是做安全的测试人员，只要跟token鉴权打过交道，这几页东西都值得存下来慢慢看。
1. 内容整体设计与思路拆解
1.1 JWT为什么总在鉴权环节出问题
先说个现象：JWT本身是一个极其简单的规范，三段式结构，Base64URL编码，一段Header、一段Payload、一段Signature。Header里声明算法和token类型，Payload里放claims，Signature则是对前两段内容的签名。就这么点东西，理论上只要签名算法用得对、密钥管得好，伪造难度并不低。可现实是，JWT相关的漏洞在Bug Bounty平台和攻防演练中依然高频出现，根源不在JWT本身，而在实现方式和信任模型上。
我们在讲JWT安全之前，先建立几个基础共识。
- 签名的作用是保证数据完整性和来源可信，不是用来加密的，Payload里的信息凡是base64解出来都能直接看，所以永远别往里面塞密码、身份证号这类敏感数据。
- JWT的验证方必须持有跟签发方一致的密钥或公钥，否则无法校验签名。问题就出在这里：很多系统不知道什么情况下该信任哪个密钥，或者密钥直接硬编码在前端代码里。
- 算法参数是从Header里读的，这个Header又是用户可控的，于是攻击者只需要找到一个能让服务器信任恶意参数的方式，就能顺理成章地完成伪造。
我对JWT漏洞的总体判断是：真正被攻破的高危场景，往往不是密码学层面被正面击穿，而是实现层面上的信任链断裂。要么服务端没有严格校验签名，要么在算法选择上给了攻击者降级的空间，要么在密钥获取上留了逻辑漏洞。Burp Labs里的JWT系列靶场，恰好把这几类典型问题都串了起来，很适合作为实操模板。
1.2 为什么要拿Burp Labs当实验场
Burp Labs是PortSwigger官方的在线漏洞靶场，里面的JWT系列分成多个独立实验，每个实验对应一种绕过思路，比如未校验签名、通过Header注入绕过、算法混淆、密钥爆破等。跟市面上其他靶场相比，Burp Labs最大的优势在于每个关卡都有明确的漏洞成因提示和过关条件，你可以在里面放心地反复试错，不用担心把生产环境搞挂。
我自己习惯的流程是先在Burp Labs里把每种攻击手法跑通，再去真实项目里做代码审计和渗透验证。原因很直接：真实系统里的JWT实现千奇百怪，各种Filter、拦截器、网关层层嵌套，攻击路径往往被埋得很深。而在靶场里，你能用最短路径把核心漏洞原理吃透，后面遇到复杂场景时，至少知道该往哪个方向去测。
这篇文章涉及的实验都是基于Burp Suite Community Edition或Professional版本完成的，配合自带的JWT Editor扩展来做密钥修改和签名重放。如果你还没装这个扩展，后面我会详细说安装和配置方式。
1.3 攻击者的核心思路：找到信任边界裂缝
JWT的攻击面虽然五花八门，但归纳起来就三类。
- 签名校验缺失，也就是服务器只解析了token内容，压根没验证签名。这种情况最常见的表现是，把Signature字段删掉或改成任意值，接口依然正常返回数据。
- 算法混淆，攻击者把Header里的alg从RS256改成HS256，然后拿公钥当作HMAC密钥来签名。如果服务端没有限制算法白名单，就会用公钥去验签，从而被骗过。
- Header注入，通过操纵kid、jku、x5u这些头部参数，诱导服务端去加载攻击者控制的密钥或密钥URL，达到用自己密钥签名的目的。
从攻击者的视角看，这三类问题本质上是同一个逻辑：我能不能控制服务器在验证签名时使用的“密钥”？只要这个答案变成“能”，JWT就等于形同虚设。接下来我详细拆每一类手法。
2. 核心细节解析与实操要点
2.1 签名验证缺失：最无脑但最常出现的问题
先讲最简单也最不应该出现的问题，服务端不验签。很多开发者在写中间件时，只做了JWT的解析和claims提取，没有检查签名是否有效。这种情况下，攻击者把token的Payload改成任意内容，再随便编一个签名，请求就能通过。
实操Burp Labs的步骤很简单。
- 抓取一个带JWT的请求，登录靶场拿到合法token。
- 在Burp里右键token，选择“Send to CyberChef”或者直接用JWT Editor的“Decode as JWT”功能查看结构。
- 修改Payload里的sub参数，比如把用户名改成administrator。
- 把Signature部分随便改成无效字符，比如删掉最后一位。
- 发送请求看响应。如果依然返回200且业务逻辑生效，说明服务端完全没有验签。
这类漏洞的修复方式也非常明确：在解析完JWT之后，必须强制调用verify方法，任何验签异常都必须直接拒绝请求，而不是抛个警告继续往下走。我听过的真实案例是某企业内部系统直接把JWT解析放到了网关层，但下游服务直接信任了网关透传的Header，结果网关验签通过后，下游却被伪造Header打穿，这种链路上的信任问题尤其值得注意。
2.2 JWT的三段式结构：Header和Payload不是秘密
要理解JWT怎么被伪造，先得把它的结构拆开看。JWT由三部分组成，用点号分割。
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c三段分别对应Header、Payload、Signature。
- Header部分base64解码之后类似这样：{"alg":"HS256","typ":"JWT"}。alg字段就是签名算法，typ一般是JWT。攻击者最关注的就是alg，因为它是后面所有绕过手法的起点。
- Payload部分存储的是claims，比如sub（主题）、name（用户名）、iat（签发时间）、exp（过期时间）、admin（管理员标志）等。这些字段是业务逻辑的判断依据。攻击者主要改的就是这里。
- Signature的生成规则是：签名算法(Header的alg指定) + Base64URL(Header) + "." + Base64URL(Payload) + 密钥。验证时，服务器用同样的密钥和算法重新计算，比对是否一致。
这里有个新手的常见误区：以为JWT是加密的，解不开。实际上任何能上网的人都可以把JWT粘贴到jwt.io或者jwt在线解析工具里，三秒钟就能看到全部明文内容。所以JWT真正安全与否，完全取决于签名能否被伪造，而不在于内容是否可见。
2.3 算法混淆攻击：RS256怎么被降级成HS256
算法混淆是最经典也最能说明问题的一种攻击手法。简单来说，RS256是非对称算法，密钥分成公钥和私钥，私钥在服务器手里用来签发，公钥分发给各验证方用来验签。而HS256是对称算法，签发和验签用的是同一个密钥，这个密钥必须是保密的。
攻击思路是这样的：如果服务端没有限制alg字段只能是RS256，攻击者就可以把Header里的alg改成HS256，然后用服务器的公钥作为HMAC的密钥去重新签名。服务端验签时看到alg是HS256，就会用HS256的方式，拿配置里的公钥去验签。由于HS256的验签密钥和服务端持有的公钥是同一个字符串，签名自然就能通过验证。
在Burp Labs里复现这个攻击，我需要用到JWT Editor扩展。
- 先登录靶场，拿到一个合法JWT。
- 找一下靶场提供的公钥，通常在实验描述或静态资源里，直接复制内容。
- 在Burp的JWT Editor里生成一个新的对称密钥，Key类型选HS256，把公钥内容粘贴进去。
- 修改token的Header，把alg改成HS256，Payload改成目标用户。
- 在JWT Editor里用刚生成的HS256密钥对token重新签名。
- 发送请求，观察是否成功越权。
这个攻击成功的根因是，服务器在验证签名时没有固定算法白名单，直接用Header里的alg来决定验签方式。修复方法也很简单，验证端必须校验alg是否为预期算法，如果不是就拒绝。比如明确要求只接受RS256，遇到HS256就报错，不能回退到其他算法。
2.4 弱密钥爆破：HS256的密钥不是随便设的
算法混淆之外，HS256的另一个常见问题是弱密钥。因为HS256是对称算法，密钥本身就是一个字符串，如果开发图省事直接用了类似secret、password、123456这类弱口令，那就等于把大门钥匙挂在门框上。
弱密钥爆破的常规手段是用hashcat配合字典。把JWT存成文件，指定模式是JWT HS256，命令大概是这样的。
hashcat -m 16500 jwt.txt rockyou.txt这个模式号16500就是专门处理JWT的，推荐用rockyou.txt、weakpass这类大字典跑，也可以用规则生成变种。如果是Burp用户，也可以直接在JWT Editor里右键token，选“Crack JWT”，用内置字典爆破，效果也很直观。
我看过的很多JWT弱密钥案例，密钥看起来像随机字符串，实际却是硬编码在代码里的固定值，比如项目名、公司名、接口路径之类。所以爆破时除了通用字典，最好把目标系统的相关信息都喂进去，命中率会高很多。
2.5 Header注入：kid参数背后的路径穿越与SQL注入
Header注入是一类更隐蔽的绕过方式，常见手法是通过操纵JWT头部里的kid、jku、x5u等字段，让服务端去加载攻击者指定的密钥或密钥URL。
先说kid这个参数。kid是Key ID的缩写，用来标识服务器应该用哪把密钥来验签。很多实现会把kid直接拼接到文件路径里，比如“/keys/”加kid，然后读取文件内容作为密钥。这时候如果服务端没有对kid做过滤，就可以尝试路径穿越。
实战中的操作思路是这样的。
- 把Header里的alg维持不变，将kid改成类似“../../../../etc/passwd”的路径，观察响应是否出现文件内容，或者是否报错泄露路径信息。
- 如果确认服务端会读取kid指向的文件内容作为密钥，可以把kid指向一个自己可控的文件，比如“/tmp/evil”或“../../dev/null”，然后用对应的密钥签名。
- 更高级的玩法是，如果后端会拿kid的值去数据库查密钥，甚至可以尝试SQL注入，把查询条件改成自己控制的密钥。
这里我提醒一下：利用路径穿越去读/dev/null是很多攻击者的常用技巧，因为空文件作为密钥时，等于签名密钥是空字符串，直接就能算出合法签名。这个技巧在真实的代码审计中也很实用。
再说jku和x5u。jku是JWK Set URL，服务器如果支持这个参数，会去指定的URL拉取一组公钥来验签。攻击者可以在自己的服务器上放一个恶意JWK Set，然后修改token的jku指向自己的地址。同理，x5u是指向X.509证书的URL。只要服务端允许从外网加载这些URL，且没有校验URL的域名或协议白名单，那攻击者就拿到了完整的签名伪造能力。
Burp Labs里专门有一关是测试jku注入的，大致流程是：
- 在Burp的JWT Editor里生成一对RSA密钥。
- 在公钥的JWK信息里修改jku值为自己服务器上托管的JWK集合地址。
- 把公钥的JWK信息发布到可控的URL上。
- 重新签名token，发送请求，看是否越权成功。
修这类漏洞的关键在于，服务端必须在代码中白名单化允许的密钥来源，禁止从不可信的外部URL加载密钥，对kid等参数做严格过滤，不能直接拼接路径。这类问题之所以高发，就是因为很多JWT库把参数处理的黑盒化了，开发只关注token验签结果，对签名过程中那些“辅助密码学参数”没有警觉。
2.6 算法混淆与Header注入的前置条件
前面讲的算法混淆和Header注入，在实际攻击中经常要加一些前置条件才能把链路打通。比如某些系统虽然允许你改alg，但服务器限制了jku加载的域名只能是内网域名，这时候就需要配合DNS重绑定或SSRF来绕过；再比如系统虽然会把kid拼进路径，但加了前缀目录，这时候就需要用../来穿越。
所以我的建议是：在测试JWT时，不要只盯着签名本身，要把JWT校验过程放到整个请求链路里看。如果有网关统一校验、下游服务再校验二次，或者JWT校验和业务参数校验在不同层，链路越复杂，可钻的空子越多。这一点在真实渗透测试中特别重要，很多看似严密的JWT实现，恰恰是因为多层逻辑之间没有对齐信任边界，才被打穿的。
3. 实操过程与核心环节实现
3.1 环境准备：Burp Suite与JWT Editor扩展安装
在开始实操之前，先把环境搭好。Burp Suite Community Edition是免费的，功能上已经够用，唯一不方便的是社区版有些自动化功能被限制，但手动改包和重放完全没问题。如果需要更流畅的体验，Pro版本会省很多事，尤其是Intruder和BApp扩展这两个模块。
JWT Editor的安装路径是：Burp界面顶部导航栏“Extender”或“Extensions”，在BApp Store里搜索“JWT Editor”，点击Install。安装完成后，在“Burp”主选项卡里就能看到JWT Editor的界面，支持对JWT做解码、修改、重新签名。
我顺便提一个生态里很好用的工具：jwt_tool。这是国外安全研究员写的命令行工具，可以一条命令完成算法混淆、密钥爆破、Payload篡改等操作。如果你更喜欢命令行操作，强烈推荐。Burp的JWT Editor适合图形化操作，jwt_tool适合批量和自动化，两者配合效率很高。
3.2 使用Burp Suite拦截并解析JWT请求
实操的第一步是让Burp能抓到目标请求。有两种方式，一种是直接用Burp内置浏览器访问靶场，另一种是把系统代理指到Burp的127.0.0.1:8080。我个人更推荐内置浏览器，省事而且不容易出问题。
抓到请求之后，如果Header或Cookie里有JWT，可以直接选中那段token，右键选择“Send to Repeater”或者直接在JWT Editor里查看。JWT Editor会帮你自动解码Header和Payload，你可以在界面上直接修改这两个部分的内容，然后重新签名再发送。
这里有个细节：JWT在请求里可能是以Authorization: Bearer头的形式，也可能是Cookie值，还可能是某个POST参数。测试时要先确认token的传输位置，否则改了半天发现业务没读取你改的那份token，白费功夫。Burp自带的“Search”功能可以全局搜索“JWT”或“eyJ”来快速定位，实战时很实用。
3.3 场景一：绕过签名校验直接越权（Burp Labs实操）
Burp Labs里有一关叫“JWT authentication bypass via unverified signature”，就是最直白的未验签漏洞。我这边的完整操作流程是这样的。
- 登录靶场，用提供的账号拿到一个JWT，比如用户是wiener。
- 把这个请求转发到Repeater，用JWT Editor解码token。
- 修改Payload里的sub字段，从wiener改成administrator。
- 用JWT Editor重新签名（随便选一个算法和密钥即可）。
- 发送请求，看是否返回了管理员面板内容。
如果你的token已经被修改过但签名无效，而服务器依然正常处理，那说明它根本就没校验签名。这个实验结果让我印象很深的是：攻击者完全不需要密码学知识，只需要把base64改一改，就能搞定。
修复这个漏洞，核心是必须把验签结果作为前置条件。如果用的是Java的jjwt、Python的PyJWT、Node的jsonwebtoken，都要确保在代码里调用verify方法，而不是只做decode。
3.4 场景二：算法混淆攻防复现（RS256降级HS256）
算法混淆攻击我一般是在Burp Labs的“JWT authentication bypass via algorithm confusion”关卡里复现的。
操作顺序如下。
- 拿到合法token，先不要改内容，先观察alg字段是什么，一般是RS256。
- 去靶场提供的公钥文件地址，把公钥内容下载下来，保存为pem文件。
- 在JWT Editor的“New Symmetric Key”里，把Key类型选为HS256，Key值粘贴公钥内容。
- 在token编辑界面，把Header的alg改成HS256，Payload改成目标账号。
- 选择刚创建的HS256密钥，重新签名。
- 发送请求。
如果服务端验签通过，说明它没有限制算法，直接用公钥当了HMAC密钥来验签，整个防线的后半段就形同虚设了。
这类问题在修复时一定要注意：即使你在签发端用的是RS256，也必须在验签端写死接受的算法类型。很多JWT库支持自动识别算法，这种“智能”恰恰是危险的，攻击者改一下alg就能牵着服务器鼻子走。正确的做法是：在验签函数中明文指定Algorithm，遇到非预期算法直接抛异常。
3.5 场景三：jku注入实现远程密钥伪造
jku注入是Header注入里比较有代表性的一种。Burp Labs里有一关是“JWT authentication bypass via jku header injection”，复现步骤相对繁琐，但逻辑很清晰。
- 用JWT Editor生成一对RSA密钥，右键选择“New RSA Key”即可。
- 把生成的公钥JWK内容复制出来，放到一台自己可控的公网服务器上，或者用一些在线服务托管该JSON文件。
- 修改token的Header，增加jku字段，值指向刚才托管的JWK集合地址，同时确保密钥的alg与服务器预期匹配。
- 用JWT Editor里的RSA私钥重新对token签名。
- 发送请求，如果服务器拉取了你的JWK集合并用它验签，那越权就成功了。
这里有三个容易踩的坑。
- JWK集合格式必须是标准的JSON数组，不能只放单个JWK对象，否则解析会失败。格式大概是{"keys":[{"kty":"RSA","kid":"...","alg":"RS256","n":"...","e":"AQAB"}]}。
- jku指向的地址必须能公网访问，但也要确保自己服务器的端口和路径正确，尽量用HTTPS，避免HTTP被某些库默认拒绝。
- 修改jku之后，kid要和JWK里的kid值一致，否则服务端可能因为找不到对应kid而拒绝。
这类漏洞在真实系统里很常见，尤其是自己实现了JWT验签逻辑、没有用成熟库的项目。修复建议是：不要支持从外部URL加载密钥，如果非要支持，必须白名单化允许的域名和协议。这种修复不影响正常功能，但能直接堵死一整类攻击。
3.6 场景四：kid路径穿越与弱密钥爆破进阶
除了Burp Labs的标准关卡，实战中还有两个高频场景值得展开说一下。
第一个是kid路径穿越。有些系统会把kid当文件名来读，代码大概长这样：
key = open('/keys/' + kid + '.pem').read()如果kid参数不带任何过滤，直接传“../../../../tmp/evil”就能跳到任意路径。攻击者把恶意公钥写到目标可读路径，再签一个token，就能骗过验签。测试时可以先试“../../../../etc/passwd”，如果报错信息里出现“No such file or directory: /keys/../../../../etc/passwd”这类信息，说明路径拼接确实存在。
第二个是弱密钥爆破。我遇到过一个运维后台，密钥是“qwertyuiop”。用hashcat跑rockyou字典，几秒钟就出了结果。爆破成功之后，直接拿密钥签发任意用户的token，等于把整个后台权限拿到手。建议你在做权限测试时，凡是遇到HS256算法的JWT，都先跑一遍弱密钥爆破，成本非常低但收益极高。
4. 常见问题与排查技巧实录
4.1 为什么改了alg但签名仍然不通过
我遇到过不少人照着教程操作，明明改了alg从RS256到HS256，也用公钥当密钥签名了，但服务器还是返回401。这类问题多半出在签名内容上。
JWT签名是对以下字符串做签名：
Base64URL(Header) + "." + Base64URL(Payload)也就是说，签名和前两段编码后的字符串强相关。如果用了JWT Editor签名，它会自动计算，一般不会出错。但如果你是用在线工具手工拼的，很容易把原始未编码的JSON当成签名输入，导致签名错误。最重要的是，修改Header和Payload后，前两段的Base64URL编码必须更新，否则签名对应的内容和实际发送的内容不一致，验签必然失败。
另一个常见原因是公钥格式问题。HS256需要的是原始密钥字符串，有些JWT库要求密钥是Base64编码，有些要求UTF-8字符串，格式不对验签就失败。建议多试几种编码方式，或者直接查看服务端源码来确认。
4.2 为什么jku指向自己的服务器仍然加载失败
jku注入失败的原因比算法混淆要多，常见的有：
- 公网服务器没有正确返回JSON，可能是格式错误，也可能是端口被防火墙拦截。提前用浏览器打开jku地址确认一下。
- 服务器配置了出网限制，根本无法访问外网。这种情况需要先测试是否存在SSRF或DNS重绑定之类的通道。
- jku必须是一个JWK Set，也就是包含keys数组的JSON，而不是单个JWK。Burp Labs原题里如果直接放单个对象，也是会失败的。
- 有些库会校验jku的域名是否在信任列表中，所以单纯把jku改成攻击者域名并不够，还需要找一个可信域名下的开放重定向或者JSONP接口来中转。
遇到加载失败时，建议在Burp里打开“Proxy”的HTTP历史，看服务器是否真的对jku地址发起了请求。如果压根没有外连请求，说明服务端没支持这个参数；如果发起了但验签不通过，问题多半出在JWK格式或密钥匹配上。
4.3 如何判断目标用的是HS256还是RS256
快速判断算法类型有三个小技巧。
- 直接解码Header看alg，前端能看到的信息当然是最直接的。
- 如果alg是RS256，通常在公钥目录、JWKS端点或源码仓库里能找到公钥文件。可以直接访问/.well-known/jwks.json这种路径，很多系统会暴露公钥，方便客户端验签。
- 如果rsa公钥出现在显眼位置但服务端用的是HS256，那很可能存在算法混淆漏洞。反过来，如果发现密钥像是随机字符串且从未出现在任何文档里，大概率是HS256加硬编码密钥。
除了算法本身，还要关注非对称密钥的密钥轮换策略。很多系统签发密钥有效期很长，公钥也很少更新，这就给攻击者拿了公钥慢慢研究的机会。密钥轮换虽然不能防住算法混淆，但可以缩短漏洞利用窗口期。
4.4 为什么有些JWT用工具能解析但业务仍报错
有读者问过我，说自己改了JWT后签名也更新了，为什么调接口还是报权限不足。这个问题往往不是签名问题，而是业务claims校验的问题。
比如系统会校验exp（过期时间）、nbf（不早于）、iat（签发时间）这些时间类claims，你把sub改成了administrator，但没改exp，token早就过期了，自然过不了校验。再比如系统把权限信息放在自定义claims里，比如role或scope，你只改了sub，role还是user，照样没权限。所以实战中篡改JWT时，要尽量多观察合法token里有哪些claims，然后针对性地修改，而不是只改用户名。
在Burp Labs里，绝大多数关卡只需要改sub就能过关，因为题目刻意简化了业务逻辑。但在真实系统里，claims的设计往往更复杂，比如用户ID和角色分离、租户隔离等，需要花更多时间分析业务规则。
4.5 修复JWT漏洞时的几个关键注意点
作为防守方，修复JWT漏洞时我建议从这几处入手。
- 写死算法白名单。验签时明确指定ExpectedAlgorithm，比如只接受RS256。任何其他算法直接拒绝，不给降级余地。
- 校验所有claims的合法性。除签名外，exp、nbf、iss、aud这些claims都需要校验，否则可能出现过期token重放的问题。
- 严格管理密钥。私钥绝不能出现在前端代码、公开仓库或日志中。HS256的密钥必须是高熵随机串。非对称密钥要规划轮换周期。
- 禁止加载外部密钥。除非业务实在需要，否则不支持jku和x5u，或者把这些URL限制在可信域名内。
- 使用成熟的JWT库。不要自己实现签名验证和Base64URL逻辑，成熟库已经把常见坑都踩过了。
5. 写在最后
这几套攻击手法，从签名不校验到算法降级再到Header注入，本质上都是在跟“密钥信任边界”做斗争。我个人的经验是，做JWT安全测试时，先看服务端用的什么库、配置了什么密钥源、有没有白名单限制，心里有底了再动手改token，成功率会高很多。Burp Labs的JWT系列虽然只有十几个关卡，但每关背后代表的都是真实环境里的一类漏洞，建议你有空把每一关都刷一遍，刷完再回看自己项目的JWT实现，大概率能发现几个此前没注意到的问题。
最后再分享一个小技巧：在Burp里给JWT请求加一个“匹配并替换”规则，把Authorization头的token自动替换成自己伪造的测试token，这样在测试流程里可以省去大量手工复制粘贴的重复劳动。测试完成后再把规则删掉，避免影响后续测试。
JWT不是银弹，也不是洪水猛兽。它的安全问题大多来自实现者对信任模型的误解。希望这篇内容能帮你在下一次写鉴权代码或挖洞时，多留一个心眼，少踩一个坑。
