JWT攻击手册(附jwt

有关JWT库中已知漏洞的一些考虑因素是，它们是试图使伪造令牌被应用程序接受。当我们的攻击更改了要签名的内容时，它也会使现有签名无效。因此，我们将现有令牌有效负载值与相关攻击方法一起使用进行测试。如果攻击成功，我们的伪造令牌将被验证并使用原始值。换句话说，如果您使用有效令牌以“ user1”身份登录，并且尝试使用alg：none攻击并保留所有有效载荷数据并且将其注销，则该攻击将不起作用。如果您保持登录状态，那么您的攻击就成功了，您可以开始使用“有效负载”值来查看现在可以进行调整以获取特权或其他有益结果的内容。测试漏洞-‘none’算法（CVE-2015-9235）：设置没有签名的“ alg”：“ none”，但是不要更改有效载荷-页面是否仍返回有效？使用jwt_tool的-A标志切换算法并放弃签名

以下是应该测试的已知弱点。跨服务中继攻击一些Web应用程序使用受信任的JWT“服务”为其生成和管理令牌。在过去的某些情况下，为一个JWT服务的客户端生成的令牌实际上可以被另一个JWT服务的客户端接受。如果您发现JWT是通过第三方服务发布或更新的，则值得确定是否可以使用相同的用户名/电子邮件在该服务的另一个客户端上注册一个帐户。如果是这样，请尝试获取该令牌并在对目标的请求中重播它。被接受了吗？

现在您已经经历了已知和常见的攻击，但是请等待 -这还没有结束！ 每个优秀的应用程序测试人员都知道：应用程序处理的每条用户提交的数据都可能是攻击媒介。正如我们所知，我们的令牌权利要求的内容完全控制，所以它的时间去创作…… 起毛能力即将到jwt_tool，但在那之前，和技术建议和方法，检查了篡改和模糊测试页面。

以下是根据相关RFC提出的“官方”或要求的权利要求。在此确定了它们的功能，以及它们可能暴露的任何观察到的或理论上的漏洞。标头声明标头声明是令牌的“元数据”，告诉应用程序令牌是什么类型，令牌是如何签名的，签名密钥或秘密的存储位置以及其他详细信息。必须在验证令牌之前对它们进行处理，这就是为什么在Header声明中发现了大多数JWT库漏洞的原因。一些“标准”主张：| Token | Description | Format || ——- | —————————————————————- | —————- || typ | 令牌类型 (JWT/JWE/JWS等) | string || alg | 用于签名或加密的算法 | string || kid | Key ID - 用作查找 | string || x5u | x509证书的URL | URL || x5c | 用于签名的x509证书（作为嵌套的JSON对象） | JSON object || jku | JWKS格式键的URL | URL || jwk | 用于签名的JWK格式密钥（作为嵌套的JSON对象） | JSON object |标头声明中的漏洞

有趣的是，所有这些都通过操作标头值来影响令牌。这主要是因为头控制如何或用什么令牌进行签名。攻击有效负载部分中的目标值可能是特定于平台/服务的，而不是特定于库的。在这一点上还值得注意的是（在没有极其冗长的错误的情况下），您不太可能知道哪个JWT库（更不用说该库的哪个版本）正在给定服务上签名令牌。因此，在测试JWT时，我们最好的选择是尝试所有技巧，看看是否有任何问题。JWT库存在以下CVE：

CVE-2015-9235-Alg：无攻击此攻击针对JWT标准中用于生成无符号密钥的选项，输出实际上省略了第二个点之后的任何签名部分。由于某些库或服务器配置中的弱点，服务可能会读取被篡改的请求，请确保不需要对其进行签名，然后信任地接受它。示例：

解构：

如何抵御这种攻击？ JWT配置应该只指定所需的签名算法（不要指定“无”！）CVE-2016-5431-密钥混淆攻击此攻击的原因是某些库对签名/验证HMAC对称加密的密钥和包含用于验证RSA签名令牌的公钥的密钥使用相同的变量名。通过将算法调整为HMAC变体（HS256/HS384/HS512）并使用公共可用公钥对其进行签名，我们可以欺骗服务使用机密变量中的硬编码公钥验证HMAC令牌。示例：

解构：

如何抵御这种攻击？JWT配置应该只允许使用HMAC算法或公钥算法，决不能同时使用这两种算法。CVE-2018-0114-密钥注入攻击此攻击尝试了一些JWT库中不太常用的验证技术-包含内联公钥。攻击者可以使用新的私钥对令牌进行签名，在令牌中包含公钥，然后让服务使用该密钥验证令牌。示例：

解构：

如何防御这种攻击：JWT配置应该明确定义接受哪些公钥进行验证。JWKS欺骗此攻击使用“jku”和“x5u”标头值，它们指向用于验证非对称签名令牌的JWKS文件或x509证书（通常在JWKS文件中）的URL。通过将“jku”或“x5u”URL替换为包含公钥的由攻击者控制的URL，攻击者可以使用成对的私钥对令牌进行签名，并让服务检索恶意公钥并验证令牌。示例：

解构

要防御此攻击：JWT配置应该明确定义允许哪些JWKS文件/url。“kid”注射此攻击破坏了应用程序处理密钥ID值的方式。有些库使用系统调用（如文件系统查找）或数据库查询来提取“kid”头值中指定的密钥。通过将恶意数据注入此声明，攻击者可以强制应用程序执行任意SQL查询、系统命令，甚至可以将“密钥文件”的目标重定向到系统上的已知文件，以强制使用新的密钥对HMAC令牌进行签名和解密。要防御此攻击：在应用程序中，应该为“kid”值指定设置参数，并且在处理之前丢弃与此不同的输入。跨服务中继攻击一些服务使用外部身份验证服务，或共享本地身份验证服务器来生成令牌。如果这些令牌未指定特定的目标服务，则可能注册一个服务并将令牌重播到另一个服务，并获得具有不同权限的访问权限。要防御此攻击：确保所有共享身份验证服务令牌都包含一个“aud”（访问群体）声明，指定令牌的目标群体，或使用其他自定义方法来区分重播的令牌。弱密钥破解的乐趣，当使用HMAC对称签名算法时，可以使用各种简单的CPU破解工具离线破解，或者插入GPU驱动的强力破解设备。如果你使用一个弱的或短的字符串作为密钥，那么它可能很快就会被破解。要防御此攻击：跳过HMAC签名并使用非对称加密，它要更安全一点。如果由于某种原因无法避免HMAC签名，请确保实现长的随机密钥字符串，并定期更换密钥。

为了尝试使用非对称加密的令牌的某些攻击路径，我们可能需要找到公钥，有许多可能的方法。SSL密钥重用在某些情况下，令牌可能会使用网络服务器的SSL连接的私钥进行签名。抓住x509并从SSL中提取公钥非常简单：

API暴露为了验证令牌，服务可以通过API端点（例如“ / API / v1 / keys”）公开公钥。应该列出的位置是API的文档（如果您有权访问它们），否则您可能会在代理历史记录中看到到此端点的访问量。JWKS常见位置另一种常见的替代方法是在JWKS（JSON Web密钥存储）文件中公开密钥（或密钥集）。一些常见的位置是：

篡改成功利用后，您可以篡改有效载荷数据来尝试各种攻击。这些可能包括更改用户名或用户ID以接管另一个帐户，可能正在调整应用程序上的角色列表，可能涉及启用管理属性。只需查看可用的声明，看看您可以如何处理它们。使用jwt_tool的-T标志进入交互式篡改模式，并破坏标头和有效载荷声明以及大量的签名方法/攻击模糊测试将现有声明更改为各种值，使它们无效，从int更改为string等都是使服务无法正确解析JWT的好方法。这可能会提示错误消息或其他意外结果。模糊测试对于测试对有效载荷声明的注入攻击也很有用：例如XSS和SQLi攻击。Fuzzing模式jwt_tool仍在开发中（具有多种签名方法的选项），但与此同时，您可以使用Burp Intruder进行以下攻击：

进一步模糊的想法为什么不通过注入重复的声明来尝试参数污染？也许您可以将索赔从抬头移到有效载荷块，反之亦然？如何注入其他常见要求？如何为您在应用程序中看到的其他变量或参数添加声明？

如果您可以窃取并重播JWT，则无需破解JWT ！如果您在应用程序中存在其他漏洞，则可以窃取或劫持其他用户的令牌。XSS通用的cookie窃取程序XSS有效负载将可以访问以cookie形式存储的JWT：只要未将cookie设置为HTTPOnly，就可以使用有效负载来窃取LocalStorage或SessionStorage变量的内容。如果JWT存储在JavaScript变量中，那么您知道名称也可以窃取它。例子：

CSRF当通过身份验证的用户与目标站点进行交互时，存储在cookie中的JWT令牌（无论是否为HTTPOnly）将由浏览器自动发送。当受害者触发CSRF有效负载时，浏览器将发送包括令牌的关联cookie。攻击者将看不到这些内容，但是由于它们被用来进行攻击者的出价，因此这实际上并不重要。例子：

CORS配置错误当站点的CORS策略允许任意来源以及发送凭据时，可以在向Web服务器制作包含XHR请求的攻击页面的同时捕获响应。这导致两种可能的攻击路径：

它已对先前的标头和有效负载进行了编码，并用一个秘密进行了签名。

译文声明：本文由Bypass整理并翻译，仅用于安全研究和学习之用。

原文地址：https://github.com/ticarpi/jwt_tool/wiki