node-jsonwebtoken

I've raised a PR to rename decode() to unsafeDecode() (removing it from the public API might be a hard sell). I really have no idea why this is part of the public API. https://github.com/auth0/node-jsonwebtoken/pull/741

This exact vulnerability is something I've seen in a good number of open-source codebases or boilerplate repos in the Node ecosystem. The library most people use for JWT stuff in Node is Auth0's. There are two methods for decoding a token payload: jwt.decode() and jwt.verify() Both of them return the decoded payload, but one (if you don't read the documentation) sounds more immediately like the one you think you want to use. jwt.decode() doesn't verify the token when decoding: https://github.com/auth0/node-jsonwebtoken#jwtdecodetoken--o... If you dig through Node repos on Github searching for "jwt.decode()" or "this.jwtService.decode()" you'll see a shocking number of results. The other big mistake I've seen is encoding personal data in the token, instead of just an ID that only has meaning inside of your database. It turns out not everyo

If you don't set it it's set to a reasonable list of algorithms [0], which doesn't include "none" https://github.com/auth0/node-jsonwebtoken/blob/master/verif...

https://github.com/auth0/node-jsonwebtoken/blob/5f10bf9957a2... The end result depends entirely on the behavior of JavaScript's Array.indexOf() implementation.

I have been using JWT[1] since it's initial push as a mainstream authentication method. There's plenty of libraries that support it and make it easier to use[2]. There's even 0Auth[3] that is a company based around offering authentication services. Simply check for a valid token in the Authorization header, check out the introduction [4]. The library I've linked brings up a good point to make sure that you know the difference between decoding and verifying the token, but after that it's fairly plain sailing. [1]: https://jwt.io [2]: https://github.com/auth0/node-jsonwebtoken [3]: https://auth0.com [4]: https://jwt.io/introduction/

The "none" algorithm set in header is a well known problem and, for example, nodejs most used library automatically uses asymmetric keys when one is given, ignoring the header (https://github.com/auth0/node-jsonwebtoken/blob/master/verif...) As long as the problem is known to the developers and the key is specified, I think the biggest issue of JWT is the lack of session invalidation (that is, if you log out your already emitted tokens are still valid until their expiration), but it's a good tradeoff for not having server sessions.

> These tokens are usually signed to protect against manipulation (not encrypted) so the data in the claims can be easily decoded and read Is this really true? I mean, if you can decode the token you must have access to the secret anyway? From https://github.com/auth0/node-jsonwebtoken var token = jwt.sign({ foo: 'bar' }, 'shhhhh'); var decoded = jwt.verify(token, 'shhhhh'); console.log(decoded.foo) // bar

If there are libraries that silently accept an unsigned JWT with alg:none, even when they are provided a secret key to verify, that's a serious CVE right there... If a secret or public key is passed to the verify function, the function MUST fail if no signature is actually present in the token. E.g. on node-jwt; [1] if (parts[2].trim() === '' && secretOrPublicKey){ return done(new JsonWebTokenError('jwt signature is required')); } As another example, in the C# library, as long as 'RequireSignedTokens' is true, it will ensure the signature can't be stripped. [2] I'd say that's poor design to allow specifying a key and then ignoring it silently if 'RequireSignedTokens' is false, even if it is true by default, because the combination of 'RequireSignedTokens' = false, and a non-null key, is invalid. [1] - https://github.com/auth0/nod