Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful
1–10 of 97 posts
Re: Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful
#2Tired: {"alg":"none"}
Wired: {"alg":"nonE"}
The JOSE standards (including JWT) are a gift that keeps on giving to attackers.
I designed an alternative format in 2018 called PASETO, which doesn't contain the JOSE foot-guns. (I'm pushing for an IETF RFC this year.)
EDIT: Also, this affected their Authentication API rather than their JWT library.
If you use their JWT library, well, it certainly allows this kind of horrendous misuse... but it is not, per se, vulnerable.
Re: Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful
#3The gist of this Auth0 authentication API bypass is detailed as follows:
> The Authentication API prevented the use of alg: none with a case sensitive filter. This means that simply capitalising any letter e.g. alg: nonE, allowed tokens to be forged.
I really don't know what to think of why you need a case-sensitive filter for alg:'none'. The question is that why use and support 'alg:none' in the standard in the first place? As I previously commented, the option to have 'alg: none' should never be used as it is still the biggest footgun in the JOSE specification. Even giving the user a choice of ciphers to use is a recipe for disaster. Thus, JWT is still a cryptographically weak standard and its use is discouraged by many cryptographers.
PASETO [0] or Branca [1] are cryptographically stronger alternatives to use over JWT here.
Re: Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful
#4Always normalize your input?
Re: Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful
#5The gist of this Auth0 authentication API bypass is detailed as follows: > The Authentication API prevented the use of alg: none with a case sensitive filter. This means that simply capitalising any letter e.g. alg: nonE, allowed tokens to be forged. I really don't know what to think of why you need a case-sensitive filter for alg:'none'. The question is that why use and support 'alg:none' in the standard in the firs…
> the option to have 'alg: none' should never be used
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.
Re: Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful
#6At some point, that alg parameter gets resolved to an algorithm - an object or enum constant or something. This bug implies that the filtering was done on the string value of the parameter, and not the resolved value. That seems like a schoolboy error.
Re: Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful
#7Most JWT libraries require to hardcode the expected algorithm when verifying a token, so if your applications are verifying the token provided by Auth0 with a JWT library, they're most likely not vulnerable to this mistake.
Re: Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful
#8I've encountered issues like this in various systems using JWT at this point. The real problem is that developers blacklist the algorithms they don't want. Instead, the verification code should explicitly whitelist which algorithms you support.
More specifically, you can't even rely on using the 'alg' parameter before successful signature verification with any level of authority: after all, it is protected by the signature it declares the algorithm for itself. So even with a whitelist, there is the potential of downgrade attacks.
In other words, don't even use a whitelist, use a single specific expected algorithm.
Re: Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful
#9At some point, that alg parameter gets resolved to an algorithm - an object or enum constant or something. This bug implies that the filtering was done on the string value of the parameter, and not the resolved value. That seems like a schoolboy error.
It's much worse than that. There are like 5 options for the algorithm value, none, RS256, HS256, etc...
The vulnerabilities implies that they don't verify the value against the very limited list of possible values, which is incredibly stupid.
Re: Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful
#10The gist of this Auth0 authentication API bypass is detailed as follows: > The Authentication API prevented the use of alg: none with a case sensitive filter. This means that simply capitalising any letter e.g. alg: nonE, allowed tokens to be forged. I really don't know what to think of why you need a case-sensitive filter for alg:'none'. The question is that why use and support 'alg:none' in the standard in the firs…
> The question is that why use and support 'alg:none' in the standard in the first place?
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.