4 comments

[ 3.4 ms ] story [ 22.8 ms ] thread
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/node-jsonwebtoken/blob/master/index...

[2] - https://github.com/AzureAD/azure-activedirectory-identitymod...

Very good catch. You should file CVEs for these, since it's about as hair-on-fire bad as a security bug can be!

News at 5: Library for securing tokens doesn't secure tokens.

Thanks for spotting this Tim, I appreciate it. I've patched python-jwt and linked to your article. Please let me know if you file a CVE so I can link to it too.

The docs did say:

  returns: ``(header, claims)`` if the token was verified successfully. The token must pass the following tests:
  - Its signature must verify using the public key or its algorithm must be ``none``.
but passing the responsibility for checking header['alg'] to the caller was the wrong way round so thanks again!