Bug report: JWT Verify doesn't require an algorithm

[joshbarth]

As detailed here, JWT verification functions should require specifying the algorithm that should have been used, in order to prevent an attacker from changing the algorithm to a symmetric algorithm from an asymmetric one and using the public key to sign the token. Probably low priority for this particular app, but it would be good to at least have the option.

[mifriis]

Hi @joshbarth,
Correct me if i am wrong or misunderstand you, but isn't the problem you link to, a serverside issue where developers simply trust whatever signing alg the token specifies? Removing the "none" signing alg from Cyberchef won't help the problem. Servers need to interpret the tokens with the signing alg it writes the tokens with.

Having the "none" signing alg there is a great tool for testing your implementation of JWT verification, to catch the problems mentioned in the link.

[joshbarth]

I don't mean removing the none algorithm, I meaning allowing the user to specify which algorithm is expected and raise an error if the jwt defines it differently. The relevant part of the article is this: https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/#RSA-or-HMAC-. Specifically "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 secret key." Basically, the solution is, rather than trusting the jwt alg field, allowing the user to define the algorithm. Hope that makes more sense.

[ghost]

Yeah, that would be good especially since the JWT header isn't shown at all. I recommend using https://jwt.io/ for playing with JWT tokens.