7 ms·

Critical Vulnerabilities in JSON Web Token Libraries

147 points by pr0zac 12y ago

zaroth 12y ago
Also see: https://news.ycombinator.com/item?id=9111049 https://news.ycombinator.com/item?id=9111049 Where are the CVEs?! ... OK, I just sent a brief write-up to the oss-security list, we'll see what happens.
- omgitstom 12y ago
  Yea, it bothers me as well. Trusting blogs for security vulnerabilities spread across the internets isn't the model to be aiming for.
bbrazil 12y ago
Be wary if you do anything with signed data before you verify the signature. http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/ http://www.thoughtcrime.org/blog/the-cryptographic-doom-prin...
- ploxiln 12y ago
  That's a great link (which I've seen before) and I upvoted it. But these "typical JWT lib api vulns" are WAY SIMPLER than Vaudenay etc. Any programmer could do this in minutes or less. WOW. It's so obvious and straightforward (in hindsight I suppose). My mouth is still hanging open.
  - bbrazil 12y ago
    We've recently been looking at adding JWT, and one of the things I looked out for was that we were protected against downgrade attacks. This was done both as a check of the current library code, and an explicit check on our side that the alg is what we expect to protect against future library changes.
- Arnout 12y ago
  Don't trust the data before you verified it is indeed the common problem here. You have to be careful with JWK in a similar way: the public key can be specified a as a URL via the x5u parameter, you have to make sure you only trust keys from a whitelisted URL otherwise whoever supplies the token signed with a JWK can just provide their own public key and self-sign it. This can be problematic and need some leg-work on a developer's side when the URLs to be whitelisted aren't documented. For example Apple use a similar signed blob to allow 3rd parties to verify a Game Center identity, using generateIdentityVerificationSignatureWithCompletionHandler. The data you get back includes the publicKeyUrl, but not which URLs to expect. A naive implementation would just download the public key and run with it. Bad for two reasons: you're now downloading data from an arbitrary location and you are trusting a signature that you verified using untrusted information. In case anyone is interested, the two locations I've seen Apple provide here are https://sandbox.gc.apple.com https://sandbox.gc.apple.com and https://static.gc.apple.com https://static.gc.apple.com .
pvg 12y ago
Original, non-spam source is: https://www.timmclean.net/2015/03/31/jwt-algorithm-confusion.html https://www.timmclean.net/2015/03/31/jwt-algorithm-confusion...
- joshfriend 12y ago
  > This article originally appeared as a guest post on Auth0’s blog. um...
  - pvg 12y ago
    That blurb was added later.
d4mi3n 12y ago
For those of you concerned about if a JWT library you're using is vulnerable, you can see the current list of verified/validate clients for each language here: http://jwt.io/ http://jwt.io/ (page down to see the list) My team has been using ruby-jwt, so I'm glad to see that at least does not seem to be on the list of vulnerable libraries.
mfjordvald 12y ago
They list the php-jwt library from firebase as vulnerable but I can't see why. As far as I can see they do not support the None algorithm. https://github.com/firebase/php-jwt/blob/master/Authentication/JWT.php https://github.com/firebase/php-jwt/blob/master/Authenticati... It's not in the methods array and the decode method specifically does a check to see if it's empty. if (empty($header->alg)) { throw exception } Can anyone throw some light on this?
- ploxiln 12y ago
  The second critical problem, which is not addressed by php-jwt, is that it does not take as a parameter to the decode() function which algorithm should be used. It figures out the algorithm by looking at the header. As the original post describes, if your code expected to use a RSA public/private key pair, then it will pass the public key to decode(). Then an attacker can craft a JWT that claims to use a HMAC symmetric key and sign it with the public key, which is public. One and done. (your code in that case expected the header to specify an RSA algorithm, and be signed with the private key. but the decode() function doesn't know that)
  - mfjordvald 12y ago
    Cheers, so using this library only to encode should not be an issue for us.
    - zaroth 12y ago
      As in, a third party is doing the decode? You should check which library they are using...
odino 12y ago
By the way, claps for Tim for the amazing job. He contacted various people and gave them heads up weeks ago. I think the wat this was handled was awesome. <3 OSS
odino 12y ago
By the way, claps for Tim for the amazing job. He contacted various people and gave them heads up weeks ago. I think the wat this was handled was awesome. <3 OSS
laumars 12y ago
Can someone please explain to me the appeal of tokens like the following please? payload = '{"loggedInAs":"admin","iat":1422779638}' I've always worked under the assumption that everything the client sends is wrong; which means the only fields I issue are a user hash and session key. If either of those don't match the session table record then the token is rejected. Having group permissions issued from the client side seems like a bad design from the offset - however this seems a really obvious point to make, which makes me wonder if I'm missing the point of JWT's. Is anyone able to expand on this for me please?
- bbrazil 12y ago
  Such a token doesn't require you to have a database to lookup and maintain the user session/permissions in, which can lead to more reliable and lower latency designs.
  - laumars 12y ago
    Your "reliability" point I'd question because a session table method is harder to attack. But I'd be willing to agree that their reliability would be on a par with each other (where session tables are weaker, JWT's excel; and visa versa). If you don't mind me asking a few more questions, how are the JSON web tokens typically authenticated if not via a database? Or are they assumed correct? edit: Would the guy who down voted me mind explaining why it's now bad etiquette to ask questions on HN? Or was there something more specific about the post which you took a dislike to? It's becoming impossible to navigate around the complex neuroticisms of every HN member (since it can take only 1 vote to make a comment grey) so a little assistance would be greatly appreciated. :)
    - bbrazil 12y ago
      That's a security point, not a reliability point. They will be more reliable, as you don't need to talk to e.g. MySQL that might be down or slow. The disadvantage is that they're difficult to revoke. Cryptography is used to verify them.
Kiro 12y ago
I don't understand why you need the alg property at all. I mean, you are the one issuing the token so you definitely know what algorithm is used in the back-end. Why is this necessary?
- ultrafez 12y ago
  If you change your algorithm, your old tokens are still usable because you know which algorithm was used to create them.
  - marcioaguiar 12y ago
    It would not be possible to establish a period to migrate all tokens? This "if you change in a possible feature" is not a good argument when modeling something, in my opinion. That's how AbstractFactoryStrategies are made.
  - bronson 12y ago
    That sounds like a very niche case, probably not worth solving. That said, the JWT lib could allow you to specify one or more fallback algorithms in case the default one fails to validate. If you're switching off an algorithm, you're probably doing it because it's been broken. And, if it's broken, you won't use it anyway.
- jessaustin 12y ago
  As the issues described in TFA make clear, the verifier really should know the algorithm in order to verify completely. However, since this format allows various algorithms, the algorithm must be recorded somewhere, especially in the public-key scenario when the verifier is probably not the signer.
  - Kiro 12y ago
    Thanks. OT but what does TFA stand for? I've seen you use it in two threads and I presume it's referring to the posted article in question but I can't figure out the actual meaning.
s_kilk 12y ago
I found a (thematically) similar issue in the clojure jwt library last year [1]. Now I'm wondering if the issue may be wider than just that library. [1] https://github.com/liquidz/clj-jwt/issues/8 https://github.com/liquidz/clj-jwt/issues/8
the_mitsuhiko 12y ago
I'm glad someone of not finally made a statement about that. I have reported two bugs like this against libraries in the last two years and the general feedback has been, that it's not an issue. They just removed the none algorithm entirely.
Corporate_Shill 12y ago
This isn't a bug, it's a XKeyScore feature.
deleted 12y ago
[deleted]
omgitstom 12y ago
I've actually seen this same issue in JWT libs before (August 2014) as well. I think one of the main issue is JWT is simple to implement, the specification seems to be unclear about how to treat unsecure JWTs (with the `none` alg). From the specificaiton: Even if a JWT can be successfully validated, unless the algorithm(s) used in the JWT are acceptable to the application, it SHOULD reject the JWT. So what it is saying is that you should have code in your application to make sure to only trust algorithms that you like. The other issue is that following the specifications rules for validation get you in a hairy spot where this vulnerability exist: https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32#section-7.2 https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-...
- btilly 12y ago
  You didn't read carefully enough. Your site may well find both HMAC and RSA to be acceptable algorithms. However if you can be tricked into using HMAC to verify something actually signed with RSA, then anyone can forge content you accept as valid. What is important is not that the algorithm is acceptable. It is that the algorithm you use for verification is the algorithm that actually should be used.
tptacek 12y ago
Don't use JSON Web Tokens.
- k__ 12y ago
  Good alternatives?
- nosir33 12y ago
  Can you expand? JWT are a good way to remove state from the service and the HMAC lets you trust it. This looks like an implementation bug, which is unfortunate, but not a reason to avoid the technology.
  - tptacek 12y ago
    I wrote 10 warning signs of bad crypto standards on Twitter a few minutes ago, largely inspired by JWT.
    - jessaustin 12y ago
      All points well taken. Still, people need to pack stuff into cookies. There are probably some modules for some environments that do this in unimpeachable fashion. How likely is the average developer to reliably pick those modules, or (haha) just code up the equivalent without using a module? At least a flawed consensus around JWT gets people looking at it. So now what? The draft [0] hasn't expired yet, so it's possible they'll just rip out the public-key stuff. What should they add to answer your reservations about CTR+HMAC? [0] http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html http://self-issued.info/docs/draft-ietf-oauth-json-web-token...
      - jessaustin 12y ago
        Apparently the drafts have been sent to the editor so they can't be changed. [1] Oh well! [1] http://self-issued.info/?p=1323 http://self-issued.info/?p=1323
MrBuddyCasino 12y ago
If you love to confirm your stereotypes as much as the next guy, take a closer look at the languages: - Ruby, Java, Lua, Scala and .NET are unaffected - updates are available for Node.js and Python - there are still no fixed version for JavaScript and PHP libs
- kylequest 12y ago
  The JavaScript version has additional crypto related vulnerabilities, by the way :-)

147 points by pr0zac 12y ago

Also see: https://news.ycombinator.com/item?id=9111049 https://news.ycombinator.com/item?id=9111049 Where are the CVEs?! ... OK, I just sent a brief write-up to the oss-security list, we'll see what happens.

omgitstom 12y ago
Yea, it bothers me as well. Trusting blogs for security vulnerabilities spread across the internets isn't the model to be aiming for.

bbrazil 12y ago

Be wary if you do anything with signed data before you verify the signature. http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/ http://www.thoughtcrime.org/blog/the-cryptographic-doom-prin...

ploxiln 12y ago
That's a great link (which I've seen before) and I upvoted it. But these "typical JWT lib api vulns" are WAY SIMPLER than Vaudenay etc. Any programmer could do this in minutes or less. WOW. It's so obvious and straightforward (in hindsight I suppose). My mouth is still hanging open.
- bbrazil 12y ago
  We've recently been looking at adding JWT, and one of the things I looked out for was that we were protected against downgrade attacks. This was done both as a check of the current library code, and an explicit check on our side that the alg is what we expect to protect against future library changes.
Arnout 12y ago
Don't trust the data before you verified it is indeed the common problem here. You have to be careful with JWK in a similar way: the public key can be specified a as a URL via the x5u parameter, you have to make sure you only trust keys from a whitelisted URL otherwise whoever supplies the token signed with a JWK can just provide their own public key and self-sign it. This can be problematic and need some leg-work on a developer's side when the URLs to be whitelisted aren't documented. For example Apple use a similar signed blob to allow 3rd parties to verify a Game Center identity, using generateIdentityVerificationSignatureWithCompletionHandler. The data you get back includes the publicKeyUrl, but not which URLs to expect. A naive implementation would just download the public key and run with it. Bad for two reasons: you're now downloading data from an arbitrary location and you are trusting a signature that you verified using untrusted information. In case anyone is interested, the two locations I've seen Apple provide here are https://sandbox.gc.apple.com https://sandbox.gc.apple.com and https://static.gc.apple.com https://static.gc.apple.com .

pvg 12y ago

Original, non-spam source is: https://www.timmclean.net/2015/03/31/jwt-algorithm-confusion.html https://www.timmclean.net/2015/03/31/jwt-algorithm-confusion...

joshfriend 12y ago
> This article originally appeared as a guest post on Auth0’s blog. um...
- pvg 12y ago
  That blurb was added later.

d4mi3n 12y ago

For those of you concerned about if a JWT library you're using is vulnerable, you can see the current list of verified/validate clients for each language here: http://jwt.io/ http://jwt.io/ (page down to see the list) My team has been using ruby-jwt, so I'm glad to see that at least does not seem to be on the list of vulnerable libraries.

mfjordvald 12y ago

They list the php-jwt library from firebase as vulnerable but I can't see why. As far as I can see they do not support the None algorithm. https://github.com/firebase/php-jwt/blob/master/Authentication/JWT.php https://github.com/firebase/php-jwt/blob/master/Authenticati... It's not in the methods array and the decode method specifically does a check to see if it's empty. if (empty($header->alg)) { throw exception } Can anyone throw some light on this?

ploxiln 12y ago
The second critical problem, which is not addressed by php-jwt, is that it does not take as a parameter to the decode() function which algorithm should be used. It figures out the algorithm by looking at the header. As the original post describes, if your code expected to use a RSA public/private key pair, then it will pass the public key to decode(). Then an attacker can craft a JWT that claims to use a HMAC symmetric key and sign it with the public key, which is public. One and done. (your code in that case expected the header to specify an RSA algorithm, and be signed with the private key. but the decode() function doesn't know that)
- mfjordvald 12y ago
  Cheers, so using this library only to encode should not be an issue for us.
  - zaroth 12y ago
    As in, a third party is doing the decode? You should check which library they are using...

odino 12y ago

By the way, claps for Tim for the amazing job. He contacted various people and gave them heads up weeks ago. I think the wat this was handled was awesome. <3 OSS

odino 12y ago

By the way, claps for Tim for the amazing job. He contacted various people and gave them heads up weeks ago. I think the wat this was handled was awesome. <3 OSS

laumars 12y ago

Can someone please explain to me the appeal of tokens like the following please? payload = '{"loggedInAs":"admin","iat":1422779638}' I've always worked under the assumption that everything the client sends is wrong; which means the only fields I issue are a user hash and session key. If either of those don't match the session table record then the token is rejected. Having group permissions issued from the client side seems like a bad design from the offset - however this seems a really obvious point to make, which makes me wonder if I'm missing the point of JWT's. Is anyone able to expand on this for me please?

bbrazil 12y ago
Such a token doesn't require you to have a database to lookup and maintain the user session/permissions in, which can lead to more reliable and lower latency designs.
- laumars 12y ago
  Your "reliability" point I'd question because a session table method is harder to attack. But I'd be willing to agree that their reliability would be on a par with each other (where session tables are weaker, JWT's excel; and visa versa). If you don't mind me asking a few more questions, how are the JSON web tokens typically authenticated if not via a database? Or are they assumed correct? edit: Would the guy who down voted me mind explaining why it's now bad etiquette to ask questions on HN? Or was there something more specific about the post which you took a dislike to? It's becoming impossible to navigate around the complex neuroticisms of every HN member (since it can take only 1 vote to make a comment grey) so a little assistance would be greatly appreciated. :)
  - bbrazil 12y ago
    That's a security point, not a reliability point. They will be more reliable, as you don't need to talk to e.g. MySQL that might be down or slow. The disadvantage is that they're difficult to revoke. Cryptography is used to verify them.

Kiro 12y ago

I don't understand why you need the alg property at all. I mean, you are the one issuing the token so you definitely know what algorithm is used in the back-end. Why is this necessary?

ultrafez 12y ago
If you change your algorithm, your old tokens are still usable because you know which algorithm was used to create them.
- marcioaguiar 12y ago
  It would not be possible to establish a period to migrate all tokens? This "if you change in a possible feature" is not a good argument when modeling something, in my opinion. That's how AbstractFactoryStrategies are made.
- bronson 12y ago
  That sounds like a very niche case, probably not worth solving. That said, the JWT lib could allow you to specify one or more fallback algorithms in case the default one fails to validate. If you're switching off an algorithm, you're probably doing it because it's been broken. And, if it's broken, you won't use it anyway.
jessaustin 12y ago
As the issues described in TFA make clear, the verifier really should know the algorithm in order to verify completely. However, since this format allows various algorithms, the algorithm must be recorded somewhere, especially in the public-key scenario when the verifier is probably not the signer.
- Kiro 12y ago
  Thanks. OT but what does TFA stand for? I've seen you use it in two threads and I presume it's referring to the posted article in question but I can't figure out the actual meaning.

s_kilk 12y ago

I found a (thematically) similar issue in the clojure jwt library last year [1]. Now I'm wondering if the issue may be wider than just that library. [1] https://github.com/liquidz/clj-jwt/issues/8 https://github.com/liquidz/clj-jwt/issues/8

the_mitsuhiko 12y ago

I'm glad someone of not finally made a statement about that. I have reported two bugs like this against libraries in the last two years and the general feedback has been, that it's not an issue. They just removed the none algorithm entirely.

Corporate_Shill 12y ago

This isn't a bug, it's a XKeyScore feature.

deleted 12y ago

[deleted]

omgitstom 12y ago

I've actually seen this same issue in JWT libs before (August 2014) as well. I think one of the main issue is JWT is simple to implement, the specification seems to be unclear about how to treat unsecure JWTs (with the `none` alg). From the specificaiton: Even if a JWT can be successfully validated, unless the algorithm(s) used in the JWT are acceptable to the application, it SHOULD reject the JWT. So what it is saying is that you should have code in your application to make sure to only trust algorithms that you like. The other issue is that following the specifications rules for validation get you in a hairy spot where this vulnerability exist: https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32#section-7.2 https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-...

btilly 12y ago
You didn't read carefully enough. Your site may well find both HMAC and RSA to be acceptable algorithms. However if you can be tricked into using HMAC to verify something actually signed with RSA, then anyone can forge content you accept as valid. What is important is not that the algorithm is acceptable. It is that the algorithm you use for verification is the algorithm that actually should be used.

tptacek 12y ago

Don't use JSON Web Tokens.

k__ 12y ago
Good alternatives?
nosir33 12y ago
Can you expand? JWT are a good way to remove state from the service and the HMAC lets you trust it. This looks like an implementation bug, which is unfortunate, but not a reason to avoid the technology.
- tptacek 12y ago
  I wrote 10 warning signs of bad crypto standards on Twitter a few minutes ago, largely inspired by JWT.
  - jessaustin 12y ago
    All points well taken. Still, people need to pack stuff into cookies. There are probably some modules for some environments that do this in unimpeachable fashion. How likely is the average developer to reliably pick those modules, or (haha) just code up the equivalent without using a module? At least a flawed consensus around JWT gets people looking at it. So now what? The draft [0] hasn't expired yet, so it's possible they'll just rip out the public-key stuff. What should they add to answer your reservations about CTR+HMAC? [0] http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html http://self-issued.info/docs/draft-ietf-oauth-json-web-token...
    - jessaustin 12y ago
      Apparently the drafts have been sent to the editor so they can't be changed. [1] Oh well! [1] http://self-issued.info/?p=1323 http://self-issued.info/?p=1323

MrBuddyCasino 12y ago

If you love to confirm your stereotypes as much as the next guy, take a closer look at the languages: - Ruby, Java, Lua, Scala and .NET are unaffected - updates are available for Node.js and Python - there are still no fixed version for JavaScript and PHP libs

kylequest 12y ago
The JavaScript version has additional crypto related vulnerabilities, by the way :-)