深入解析JWT漏洞：高级攻击与防御指南

什么是JSON Web Tokens（JWT）

在JSON Web Tokens（JWT）成为现代应用开发的主流之前，Web应用主要使用服务器端会话，这带来了水平扩展性问题。JWT通过将认证数据从服务器移动到令牌本身来解决这个问题。它们是自包含、无状态且经过密码学签名的，满足了应用开发中的各种使用场景需求。

然而，当忽视最佳实践和标准安全规范时，JWT漏洞就会出现，通常导致对受影响组织及其客户构成高风险的安全缺陷。

JSON Web Tokens由3部分组成：头部（header）、载荷（payload）和签名（signature）。头部包含基本信息，用于指导库如何签名和验证令牌；载荷包含声明和其他开发者决定包含在令牌中的任意数据属性；签名确保头部和载荷不能被篡改。

在标准JWT令牌中，所有3部分都用点（.）字符分隔，并进行base64（URL安全）编码。

头部包含元数据，作为JWT库的指令，帮助验证、解密和签名令牌。元数据可以包括使用的算法、令牌类型、任何标识符（如kid）和其他相关元数据。

载荷包含实际的JWT声明和应用程序需要的任何数据。最佳实践是不包含任何敏感数据（如账单信息、电子邮件或其他PII），除非它是加密的（即JWE）。

签名用于验证令牌的完整性。这意味着没有密钥就无法篡改数据。

JWT漏洞源于实施过程中的错误配置和不正确的输入验证。下面我们将介绍7种测试JWT漏洞的方法。

在某些情况下，开发者启用了对none算法的支持，允许他们颁发和使用未签名的令牌，通常用于测试目的或启用对未签名令牌的支持。

如果生产环境中处理不当，任何人都能够篡改JWT，包括修改任何声明以提升应用内权限或利用注入攻击。

与之前的错误配置类似，在某些情况下，开发者在没有提供签名时完全跳过签名验证。通常目的是便于测试应用程序的认证部分或提供对未签名令牌的支持。

当执行不正确的解析时，它允许攻击者篡改声明，并可能冒充其他用户以提升应用内权限，或在服务器错误处理用户输入时利用注入攻击。

如果之前所有将算法设置为’none’的尝试都失败，强烈建议进行额外测试，因为可能提供了对其他算法的支持，这可能导致JWT密钥混淆攻击。

JWT算法（或密钥）混淆攻击源于开发者错误处理JWT的算法，启用了对默认使用算法之外的其他算法的支持。这允许攻击者为令牌的签名指定任何其他算法，如HS256，该算法通常使用公钥作为密钥进行签名。

在其他场景中，您可能会注意到JWT解析库存在缺陷，允许包含您自己的密钥对。这似乎不太可能，但CVE-2018-0114就是一个明确的例子，源于类型混淆，攻击者可以通过简单地在令牌中包含任意密钥对来伪造令牌。

有缺陷的解析

node-jose库允许任何未经认证的攻击者签名令牌，只要在头部指定了jwk属性。通过以下头部制作JSON Web Token实际上会指示解析库使用攻击者的密钥对来验证其签名，最终允许任何人伪造其内容。

正如我们之前所见，当头参数被错误处理时，可能会出现错误配置。在某些情况下，您可能会注意到密钥ID（kid）在JSON Web Token的头部部分被引用。此属性表示密钥文件的位置，本质上指示解析库从服务器文件系统上的何处获取签名密钥。

通过JWT kid属性利用路径遍历

如果目标使用一组密钥，因此将使用kid参数来识别哪个密钥对用于签名。在这种情况下，我们可以测试可能的路径遍历、SSRF和注入攻击，具体取决于参数的处理方式。

通过JWT kid属性利用SQL注入

与之前的情况类似，如果您的目标在从数据库加载签名密钥时考虑kid属性，我们实际上也可以测试SQL甚至NoSQL注入。

使用常见或弱密钥也可以促进伪造令牌。使用John The Ripper或JWT_tool等工具，我们可以轻松暴力破解用于签名和验证令牌的弱密钥。请注意，这仅在令牌使用密钥签名时才可能。RSA签名的JWS和JWE通常需要完整的密钥对，包括私钥，这使得猜测攻击几乎不可能。

密钥有时会意外推送到公共代码库、JavaScript文件和其他配置文件中。这些可能包括用于签名和验证JSON Web Tokens的JWT密钥。

始终建议利用公共信息和侦察方法，如JavaScript枚举、GitHub搜索和Google搜索，来发现意外硬编码的密钥。

提示！ 在客户端找到JSON Web Token密钥强烈表明JSON Web Token在客户端进行签名和验证。确保始终验证密钥的实际机密性。

JSON Web Token漏洞可能源于各种错误配置、不遵循最佳实践和解析缺陷。在本文中，我们介绍了开发者在实施JSON Web Tokens过程中不谨慎时可能出现的几种处理缺陷。