-
Notifications
You must be signed in to change notification settings - Fork 995
Vulnerabilities in JSON Web Token #59
Comments
I was just about to open an issue with the same topic. As far as I can tell, jwt-go is vulnerable to the HMAC-spoofing. Hopefully this will be fixed soon. |
You can restrict the key today in the user provided lookup function. The jwt.Token is passed into the lookup function. You can check the signing method and only return the key if it's valid for the signing method. This would allow you to prevent the RSA public key being used with a HMAC algorithm. |
Adding it to |
There are two simple ways to protect yourself from this attack today: // in your Keyfunc, check the alg
if _, ok := t.Method.(*jwt.SigningMethodRSA); !ok {
return nil, fmt.Errorf("Unexpected signing method: %v", t.Header["alg"])
} OR, you can simply return an |
IMO, the safest solution here would be to have
|
Updated README: |
It feels like what is really needed is for the verification method to be chosen based on the type of key returned from Edit: on second thought this wouldn't work. |
I'd be interested in a PR to that effect. I think it's easier said than one. The I also don't really love the idea of trying to parse a It's also worth looking at what the token specifies. If the token specifies one alg and we can infer a different one is valid, I'd still think we should reject that token. |
There's already a helper method to parse out RSA keys from PEM data. It's not that much extra code. In fact, I know some developer prefer this as it allows them to keep the parsed data cached and not add that overhead to every request. |
The thing that makes returning the expectation awkward is that there's no easy way to pass type information around. There are a few potential ways to do this:
// in the library
type Expectation reflect.Type
const (
ExpectedSigningMethodRSA = reflect.TypeOf(SigningMethodRS256)
// etc
)
type Keyfunc func(*Token) (interface{}, Expectation, error) |
Can you clarify the concern about passthrough? You want the API to discourage people from simply returning the contents of the I actually prefer that because as far as I can tell it allows me to take an algorithm specified in a JSON Web Keys and return it directly. For example, see: https://www.googleapis.com/oauth2/v2/certs If I understand your concern correctly, I see what you're getting at but it seems like the kind of problem we can solve with docs. |
On the other hand I like your suggestion, but:
|
Yes. The implementation today is perfectly safe if you remember to check the type. We could just solve the issue with documentation. I've already updated the README. If we're going to change the API, it should not require extensive documentation to follow correctly. |
I used reflect.Type because it saves table lookups later. It stores exactly the information we care about and it's directly comparable using the reflect library. Since they are predefined constants, users of the library shouldn't care about the type. Additionally, the supported algs are extensible. A developer can implement their own if they type they care about is not supported. Using integer identifiers makes collisions possible external alg implementations. |
Any solution here is going to be inconvenient for someone. Security always is. |
As a developer, I don't need the full token to find the key. I end up looking for the "kid" in the header and then the Method. With those two items, I can find the key and ensure it's valid for the algorithm. If I want to use the same key for multiple algorithms, it's up to me. Returning an expectation from Keyfunc seems to put the burden on the library as opposed to the developer who should be in control of the keys. |
That's a fair point. There is a trade-off between coddling developers and providing enough guidance to use the library safely. Some things can be done with documentation. Some things should be in the API. |
@dgrijalva Checking the signing method in the keyfunc solves my concerns. Thanks for the quick responses 👍 |
One big swing we can take here is to drop support for passing |
It's also more explicit. We already expose the helper methods used to decode those things, so it shouldn't add a huge burden. |
Any progress on this issue? |
Lots of progress in the 3.0 branch, which is pretty close to ready. For the current version, as long as you're verifying the signing method matches your expectations, everything is fine. |
Excellent. Thanks. |
Any updates on this? Thanks |
@scorpnode
|
There's another option: If you create an instance of |
3.0 (#77) is landing today or tomorrow. It drops support for |
Resolved by #77 |
Hi,
I believe some of the vulnerabilities mentioned in this article are also applicable to this library:
Critical vulnerabilities in JSON Web Token libraries
Think it would be good to add an argument to the
Parse
function which tells it which algorithm to use.The text was updated successfully, but these errors were encountered: