Search the Community

Critical vulnerabilities exist in several JSON Web Token (JWT) libraries – namely the JavaScript and PHP versions – that could let an attacker bypass the verification step. Tim McLean, a Canadian security researcher who specializes in cryptography and dug up the issues, points out that attackers could exploit one of those vulnerabilities, which abuses an asymmetric signing algorithm, in some JWT libraries. Introduced a few years back, JWT is a standard that produces tokens between two parties. For example, a server can produce an admin token, transferred in JSON, signed by the server’s key. Clients can go on to use that token to verify the user is logged in as an admin. The issue revolves around a public key confusion between systems signed with the hash function HMAC and those signed with RSA. “If a server is expecting a token signed with RSA, but actually receives a token signed with HMAC, it will think the public key is actually an HMAC key,” McLean explained in a blog post Tuesday. “How is this a disaster? HMAC secret keys are supposed to be kept private, while private keys are well, public.” In this scenario if an attacker got access to a public key, through an API in some JWT libraries, they could use it as a token and the server would accept it. McLean advises anyone who runs a JWT implementation to verify that tokens with different signatures are set up to be rejected either via a whitelisting or blacklisting mechanism. “The server should already know what algorithm it uses to sign tokens, and it’s not safe to allow attackers to provide this value.” A separate issue, since fixed in many JWT libraries, previously let attackers choose the way tokens are verified, a condition that had “disastrous implications for some implementations,” according to McLean. McLean initially blogged about the issue in February and elaborated further on the issue this week. OAuth, one of the more popular standards for authorization, found his research so important, it republished the work on its own blog yesterday. This issue is rooted in the way that some libraries handled an algorithm known as “none.” Tokens signed with “none” could have be acknowledged as valid tokens with valid signatures, according to McLean. Attackers could modify tokens and sign them with “none” instead of HMAC-SHA256, or HS256. The tokens would then appear “signed.” Attackers then could have gone on to attach their own payload to gain arbitrary account access on some systems. According to McLean most libraries have fixed the “none” issue by ensuring that token verification fails any tokens that use the “none” algorithm. In order to fix the asymmetric keys issue, McLean, with the help of Auth0 got in touch with several of the library’s authors to make sure that any tokens with a different signature type are rejected by their libraries. Since JWTs can work across several languages, .NET, Node.js, Python, PHP, Java, Ruby, to name a few, there were a handful of libraries to contact about the vulnerability. Auth0 fixed the issue in its Node.js library last Thursday and is encouraging users to upgrade to 4.2.2, the latest version. Jose Padilla, who maintains the Python build of the library, fixed the signature verification vulnerability in version 1.0.0 last month by adding support for an alg whitelist. The most recent version, 1.0.1, also includes the fix. According to jwt.io, a service run by Auth0, the PHP or JavaScript versions of the libraries remain vulnerable. Auth0 instructing those who run those versions of JWT to seek out another non-vulnerable library until the issues are fixed or verified. Source