You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To fix this issue: Keys MUST be stored, in memory, as both the raw key bytes and the specific algorithm the key is expected to be used with. After fetching a key, this algorithm MUST be validated against the allowed_algorithms list.
I see the potential issue here. I think the gem is already indirectly doing a type check on the given JWKs when they are imported. So if a RSA public key is picked from the JWKs it cannot be used as the HMAC secret.
The keys are translated into the following Ruby types based on the kty property of the JWK:
EC -> OpenSSL::PKey::EC
OCT -> String
RSA -> OpenSSL::PKey::RSA
The error handling is not pretty in this scenario but the verification will fail with some type related error.
Here is an example where we try to fool the keyfinder to fetch a RSA key for a HMAC check, this just illustrates that mixing RSA keys with HMAC verification will always fail.
The decoding process will not get to the verification part because the given signing key is of the wrong type. It will eventually result in a TypeError (no implicit conversion of OpenSSL::PKey::RSA into String)
Could be something I'm missing here and would love to se a POC of a way to fool the verification.
Initially,
JWT.decode
correctly rejects tokens with analg
header that isn't included inallowed_algorithms
.ruby-jwt/lib/jwt/decode.rb
Line 38 in 3b4a1ab
However, this check can be bypassed if multiple keys are permitted, through the
kid
header mechanism:ruby-jwt/lib/jwt/decode.rb
Lines 40 to 41 in 3b4a1ab
ruby-jwt/lib/jwt/jwk/key_finder.rb
Lines 13 to 20 in 3b4a1ab
This is identical to the problem in firebase/php-jwt#351 https://seclists.org/fulldisclosure/2021/Aug/14
To fix this issue: Keys MUST be stored, in memory, as both the raw key bytes and the specific algorithm the key is expected to be used with. After fetching a key, this algorithm MUST be validated against the
allowed_algorithms
list.Note: This particular sharp edge isn't covered by the JWT Best Practices RFC.
The text was updated successfully, but these errors were encountered: