Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful

For server-to-server, I continue to prefer PGP to provide my encryption. While Google Payments[0] supports PGP and JWE for encrypting payloads, PGP is well tested and most of the bugs have been worked out. JWS/JWE continues to have implementation bugs (likely due to being too flexible).

[0] https://developers.google.com/standard-payments/reference/be...

Are they just closely protected by greybeards who won't listen to reason?

Question comes from a true place of ignorance/curiosity, I definitely understand the need to have unambiguous, easy to implement security tokens without the foot-guns.

We had an infosec guy excitedly tell us that PASETO was the future, and we need to change to it right now. It looked good, and a way to avoid some of the possible JiWY issues in the same way having a TLS implementation that only allowed strong ciphers might.

But we have to integrate with so many third party pieces that require JWT it wasn't an option.

But good work! With a RFC PASETO will be my choice for my next projects.

Are you planning an informational document, or going through the IETF standardization process?

Also, the last published draft is two years old this week. Have there been changes since then to the spec? Are implementations generally interoperable?

What libraries are you using? I just looked through the auth code for a project I'm working on (which uses `jsonwebtoken`) and it has an option to whitelist algorithms in the `jwt.verify` method.

Edit: removed repeated info

The list of supported options is not only knowable, but changes very slowly. Which means it's almost certainly known at commit time. Just enumerate them. By hand. Oh no, you might have to type in some text that exists somewhere else! Quelle horreur!

The list of unsupported options is unknowable. The list of string or path interpolation bugs is knowable, but isn't known by the sort of person who thinks a whitelist is a bad idea. Build a lookup table and stop trying to be clever.

  fn verify_jwt(
    // The input from the network/user; the JWT we will be verifying
    untrusted_jwt: String,
    // *The* way in which we expect JWTs to be issued / we will be verifying against:
    verifier: Verifier,
  ) -> ... {

    // Basic sanity checks & decoding.
    let untrusted_jwt: Jwt = ...;

    if !verifier.acceptable_alg(untrusted_jwt.alg) {
       bail;
    }
    verifier.verify(untrusted_jwt)
  }

I'm largely omitting¹ JWE, so perhaps there's some hidden dragon in there, or perhaps we just handle those completely separately. But for JWS, am I missing something? Unless you pass `NoneVerifier`, in which case you're explicitly opting in to alg: none and it's goriness.

Sadly, I don't think any of the top three Rust libraries do this.

¹I'm also omitting that RSA has many attached hash algorithms in JWS; one can imagine that JwtRsa might let you configure what hashers it will/will not use. As it is, some libraries take sort of this form, but split the key material off from the algorithm … letting you pass craziness like an RSA key material and HMAC-SHA256, which makes no sense. That is, what hash algorithms (if any) are possible is a function of the type of key material coming in.

¹I'm also omitting verification of the claims, which I think a library should generally handle.

The vulnerabilities implies that they don't verify the value against the very limited list of possible values, which is incredibly stupid.

I doubt anyone uses this deliberately (edit: except maybe for internal server to server communications?). I agree that having it as an option is a footgun. I still think this is a non-issue on the client/backend, most libraries explicitly make you whitelist token signing algorithms and will throw errors if the token isn't signed with the right algorithm.

> Even giving the user a choice of ciphers to use is a recipe for disaster.

How so? I'm still learning this stuff, so I'm genuinely curious.

FTFA:

> The JWT standard supports insecure JWT algorithms for scenarios where encryption and a signature are not suitable, such as trusted server-to-server communication. In these scenarios, the none algorithm is specified in the JWT header. The none alg type should never be used for untrusted user-supplied tokens.

The end result depends entirely on the behavior of JavaScript's Array.indexOf() implementation.

If Auth0 is doing any sort of normalization they will definitely be vulnerable to all the normalization bugs from unicode. Would be a great follow up vulnerability.

They are fine for human-visible names, but field names and internal enum values should use byte-by-byte comparison. It just makes entire class of vulnerabilities go away.

Don't encode your machine-to-machine protocol as human-readable strings, leading to things like declaring machine-readable identifiers to be case-insensitive when only the humans need this, not the machines.