JWT Vulnerabilities (Json Web Tokens)
最后更新于
最后更新于
如果您对黑客职业感兴趣并想要攻破不可攻破的系统 - 我们正在招聘！（需要流利的波兰语书面和口头表达能力）。
如果你很幸运，该工具会发现某些情况下网页应用程序未正确检查 JWT：
然后，你可以在代理中搜索该请求，或使用 jwt_ tool 转储用于该请求的 JWT：
您可以仅篡改数据，保持签名不变，并检查服务器是否正在检查签名。尝试将您的用户名更改为"admin"。
要检查JWT签名是否被验证：
错误消息表明正在进行验证；应查看详细错误中的敏感信息。
返回页面的变化也表明正在进行验证。
没有变化表明没有进行验证；这时可以尝试篡改有效载荷声明。
通过检查代理的请求历史记录，确定令牌是在服务器端生成还是在客户端生成。
首次从客户端看到的令牌表明密钥可能暴露给了客户端代码，需要进一步调查。
从服务器端生成的令牌表明是一个安全的过程。
检查令牌是否持续超过24小时...也许它永不过期。如果有一个"exp"字段，请检查服务器是否正确处理它。
将使用的算法设置为"None"并移除签名部分。
使用Burp扩展程序调用"JSON Web Token"来尝试此漏洞，并更改JWT内部的不同值（将请求发送到Repeater，在"JSON Web Token"选项卡中可以修改令牌的值。您还可以选择将"Alg"字段的值设置为"None"）。
算法HS256使用密钥对每条消息进行签名和验证。 算法RS256使用私钥对消息进行签名，并使用公钥进行身份验证。
如果将算法从RS256更改为HS256，后端代码将使用公钥作为密钥，然后使用HS256算法来验证签名。
然后，使用公钥并将RS256更改为HS256，我们可以创建一个有效的签名。您可以检索执行此操作的Web服务器的证书：
攻击者在令牌的标头中嵌入一个新的密钥，服务器使用这个新密钥来验证签名（CVE-2018-0114）。
这可以通过"JSON Web Tokens" Burp扩展程序完成。 (将请求发送到Repeater，在JSON Web Token选项卡中选择"CVE-2018-0114"，然后发送请求)。
说明详细介绍了一种评估JWT令牌安全性的方法，特别是那些使用"jku"标头声明的令牌。该声明应链接到一个包含令牌验证所需的公钥的JWKS（JSON Web Key Set）文件。
评估具有"jku"标头的令牌:
验证"jku"声明的URL，确保它指向适当的JWKS文件。
修改令牌的"jku"值，以指向一个受控的Web服务，允许观察流量。
监视HTTP交互:
观察HTTP请求到您指定的URL，指示服务器尝试从您提供的链接获取密钥。
在此过程中使用jwt_tool时，需要更新jwtconf.ini文件，将您个人的JWKS位置加入以便进行测试。
jwt_tool的命令:
执行以下命令，使用jwt_tool模拟场景：
一个可选的标头声明称为kid用于识别特定密钥，在存在多个密钥用于令牌签名验证的环境中尤为重要。该声明有助于选择适当的密钥来验证令牌的签名。
当标头中存在kid声明时，建议搜索Web目录以查找相应文件或其变体。例如，如果指定了"kid":"key/12345"，则应在Web根目录中搜索文件_/key/12345_和_/key/12345.pem_。
kid声明也可能被利用来浏览文件系统，潜在地允许选择任意文件。可以通过将kid值更改为目标特定文件或服务来测试连通性或执行服务器端请求伪造（SSRF）攻击。通过在jwt_tool中使用-T标志来篡改JWT以更改kid值，同时保留原始签名，如下所示：
通过针对具有可预测内容的文件，可以伪造有效的JWT。例如，在Linux系统中，已知包含值2的/proc/sys/kernel/randomize_va_space文件可以在kid参数中使用2作为对称密码用于JWT生成。
如果kid声明的内容用于从数据库中获取密码，则可以通过修改kid负载来实现SQL注入。一个使用SQL注入修改JWT签名过程的示例负载包括：
non-existent-index' UNION SELECT 'ATTACKER';-- -
这种修改会强制使用已知的秘钥ATTACKER进行JWT签名。
当kid参数指定在命令执行上下文中使用的文件路径时，可能会导致远程代码执行（RCE）漏洞。通过向kid参数注入命令，可以暴露私钥。一个用于实现RCE和密钥暴露的示例负载是：
/root/res/keys/secret7.key; cd /root/res/keys/ && python -m SimpleHTTPServer 1337&
jku代表JWK Set URL。 如果令牌使用“jku” Header声明，则检查提供的URL。这应该指向包含用于验证令牌的公钥的JWKS文件的URL。篡改令牌以将jku值指向您可以监视流量的Web服务。
首先，您需要使用新的私钥和公钥创建新证书。
您可以从公钥证书中获取参数"e"和"n"：
X.509 URL。指向一组以PEM格式编码的X.509（证书格式标准）公共证书的URI。该组中的第一个证书必须是用于签署此JWT的证书。随后的每个证书都会签署前一个证书，从而完成证书链。X.509在RFC 52807中定义。需要传输安全性来传输证书。
尝试将此标头更改为您控制的URL并检查是否收到任何请求。在这种情况下，您可以篡改JWT。
要使用由您控制的证书伪造新令牌，您需要创建证书并提取公钥和私钥：
您还可以滥用这两个漏洞进行 SSRF 攻击。
此参数可能包含以 base64 编码的证书：
如果攻击者生成自签名证书，并使用相应的私钥创建伪造令牌，然后将 "x5c" 参数的值替换为新生成的证书，并修改其他参数，即 n、e 和 x5t，那么伪造的令牌基本上将被服务器接受。
如果 JWT 嵌入了公钥，就像以下情况一样：
使用以下的 nodejs 脚本可以从这些数据中生成一个公钥：
可以生成新的私钥/公钥，将新的公钥嵌入令牌中，并使用它生成新的签名：
您可以使用以下的 Node.js 脚本获取 "n" 和 "e"：
如果某些应用程序使用ES256并使用相同的nonce生成两个JWT，私钥可以被还原。
JTI（JWT ID）声明为JWT令牌提供了一个唯一标识符。它可用于防止令牌被重放。 然而，想象一种情况，ID的最大长度为4（0001-9999）。请求0001和10001将使用相同的ID。因此，如果后端在每个请求中递增ID，您可以滥用此功能来重放请求（需要在每次成功重放之间发送10000个请求）。
跨服务中继攻击
已经观察到一些Web应用程序依赖于受信任的JWT服务来生成和管理它们的令牌。已记录到一个客户端的JWT服务生成的令牌被同一JWT服务的另一个客户端接受的情况。如果观察到通过第三方服务签发或更新JWT，则应调查使用相同用户名/电子邮件在该服务的另一个客户端上注册帐户的可能性。然后应尝试在请求目标时重放获得的令牌，以查看是否被接受。
令牌被接受可能表示存在严重问题，可能允许欺骗任何用户的帐户。但应注意，如果在第三方应用程序上注册，可能需要更广泛的测试权限，因为这可能涉及法律灰色地带。
令牌的到期检查
使用“exp”有效载荷声明检查令牌的到期时间。鉴于JWT经常在没有会话信息的情况下使用，需要谨慎处理。在许多情况下，捕获并重放另一个用户的JWT可能会使该用户被冒充。JWT RFC建议通过利用“exp”声明为令牌设置到期时间来减轻JWT重放攻击。此外，应用程序实施相关检查以确保处理此值并拒绝过期令牌的处理至关重要。如果令牌包含“exp”声明并且测试时间允许，建议存储令牌并在到期时间过去后重放它。可以使用jwt_tool的-R标志读取令牌的内容，包括时间戳解析和到期检查（时间戳为UTC）。
如果应用程序仍然验证令牌，则可能存在安全风险，因为这可能意味着令牌永远不会过期。
如果您对黑客职业感兴趣并想黑掉无法黑掉的东西 - 我们正在招聘！（需要流利的波兰语书面和口语能力）。
本文的部分内容基于这篇出色的文章： JWT渗透测试工具的作者
运行，选择All Tests!模式并等待出现绿色行。
然后，您可以使用例如来使用创建的公钥和私钥，并将参数jku指向创建的证书来创建新的JWT。为了创建有效的jku证书，您可以下载原始证书并更改所需的参数。
然后，您可以使用例如 来使用创建的公钥和私钥，并将参数 x5u 指向创建的证书 .crt 来创建新的 JWT。
这里有一个例子：
如果您想在HackTricks中看到您的公司广告或下载PDF格式的HackTricks，请查看！
获取
发现，我们的独家收藏品
加入 💬 或 或在Twitter 🐦 上关注我们。
通过向和 github仓库提交PR来分享您的黑客技巧。
