
Critical Vulnerabilities in JSON Web Token Libraries - pr0zac
https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/
======
bbrazil
Be wary if you do anything with signed data before you verify the signature.

[http://www.thoughtcrime.org/blog/the-cryptographic-doom-
prin...](http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/)

~~~
ploxiln
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
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.

------
odino
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

------
Kiro
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
If you change your algorithm, your old tokens are still usable because you
know which algorithm was used to create them.

~~~
marcioaguiar
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.

------
s_kilk
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)

------
zaroth
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
Yea, it bothers me as well. Trusting blogs for security vulnerabilities spread
across the internets isn't the model to be aiming for.

------
the_mitsuhiko
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.

------
d4mi3n
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.

------
omgitstom
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-...](https://tools.ietf.org/html/draft-ietf-oauth-json-web-
token-32#section-7.2)

~~~
btilly
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.

------
laumars
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?

~~~
sandstrom
I agree with you (I do the same).

However, in certain cases it's useful to have stateless sessions (or rather,
moving the state to the client, using signed and/or encrypted tokens).

In this case, JWT is used by e.g. OpenID-Connect, to pass data between
systems. In some of these use-cases the client is an intermediary, passing
along the token.

~~~
laumars
Like a portable passport rather than a centralised authentication model. That
does sound an interesting concept :)

~~~
mahmud
Passports (travel documents) are increasingly moving to central authentication
too. They were prone to trivial forgery before they were chipped and barcoded.
And exactly for the same reason.

------
MrBuddyCasino
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
The JavaScript version has additional crypto related vulnerabilities, by the
way :-)

------
mfjordvald
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/Authenticati...](https://github.com/firebase/php-
jwt/blob/master/Authentication/JWT.php)

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
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
Cheers, so using this library only to encode should not be an issue for us.

~~~
zaroth
As in, a third party is doing the decode? You should check which library
_they_ are using...

------
tptacek
Don't use JSON Web Tokens.

~~~
nosir33
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
I wrote 10 warning signs of bad crypto standards on Twitter a few minutes ago,
largely inspired by JWT.

~~~
jessaustin
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...](http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html)

~~~
jessaustin
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)

------
pvg
Original, non-spam source is:

[https://www.timmclean.net/2015/03/31/jwt-algorithm-
confusion...](https://www.timmclean.net/2015/03/31/jwt-algorithm-
confusion.html)

~~~
joshfriend
> This article originally appeared as a guest post on Auth0’s blog.

um...

~~~
pvg
That blurb was added later.

