
# of days since the last alg=none JWT vulnerability - tosh
https://www.howmanydayssinceajwtalgnonevuln.com
======
gavinray
This exact vulnerability is something I've seen in a good number of open-
source codebases or boilerplate repos in the Node ecosystem.

The library most people use for JWT stuff in Node is Auth0's. There are two
methods for decoding a token payload: jwt.decode() and jwt.verify()

Both of them return the decoded payload, but one (if you don't read the
documentation) sounds more immediately like the one you think you want to use.

jwt.decode() doesn't verify the token when decoding:

[https://github.com/auth0/node-jsonwebtoken#jwtdecodetoken--
o...](https://github.com/auth0/node-jsonwebtoken#jwtdecodetoken--options)

If you dig through Node repos on Github searching for "jwt.decode()" or
"this.jwtService.decode()" you'll see a shocking number of results.

The other big mistake I've seen is encoding personal data in the token,
instead of just an ID that only has meaning inside of your database. It turns
out not everyone is aware that JWT tokens are publicly decodable and that the
only security is in the signing + verification. Many people I've spoke with
think the token is like a hash.

~~~
hinkley
I worked on some code signing code, and one of the internal customers, who had
a lot of clout (but not as much as they thought) were adamant that I needed to
provide them a way to pluck data out of the payload without verifying the
signature first. I told them, in a variety of extremely diplomatic ways, to
politely fuck off. In fact I did a sweep of the code to make extra sure that
none of the data paths gave you anything before verification had finished
(there were not barn doors but there were soft spots). When your dog is
sniffing around, it's time to hide the treats.

The only reason you want to look at a payload is to make decisions about it,
_before you can trust those decisions are rational_. What I did promise them
is that I would continue to try to make the checks cheaper, which we did.

Ten years later, I still trust that I made the right call. Never expose a
function from a security library that gives you the data without verifying it
first. You are doing _violence_ to the user, the team, the company, possibly
an entire industry.

~~~
lmilcin
In general I don't see any reason to look at any data in the payload before
the signature is verified. If anything, a good reason is that increases attack
surface by giving attacker ability to interact with my system without the
signature.

I don't know what exactly you mean by improving performance by looking at the
payload before the cost of signature verification. If you mean that for some
reason you could discard large portion of messages without actually verifying
the signature then this is generally false.

In a DoS situation the attacker might want to consume your resources without
bothering to forge the signature but just as well he can forge the content so
potentially easy fix to their fake content will cause you to pay for the
signature verification anyway.

If, on the other hand, the application somehow relies on this to be viable
then very likely this is a design fault. I can imagine for example that you
might want to discard messages with outdated tokens but there are better ways
to solve this (just don't send outdated tokens?)

~~~
hinkley
In one case they were trying to categorize the content based on inspecting the
manifest, shall we call it. If you start making decisions based on non-
authoritative information, my experience is that you very quickly forget that
it's non-authoritative. That slippery slope is universal, rather than
particular to any examples in this thread. If it can happen, it will happen.

If you decide things without checking with a higher authority, then you are
the Confused Deputy, and that typically ends badly. It's not Barney's fault he
keeps getting locked in the jail cell. It's Andy's.

------
asymptotically2
Slightly OT but why should I choose a JWT over creating some opaque token
(random bytes) and storing that in a database mapping it to a user's ID?

It seems like people create short lived JWTs and then pass some opaque token
to an auth endpoint to get a new JWT signed whenever the old one expires, or
they store the JWTs in a database so that they can be revoked, making me
question their usefulness.

~~~
shakna
> Slightly OT but why should I choose a JWT over creating some opaque token
> (random bytes) and storing that in a database mapping it to a user's ID?

To avoid the database lookup. Often you might want to hold some state, without
the latency.

JWT is about your server being able to be stateless, whilst the client is
stateful, which can speed up some... Irritating... Places of performance
problems.

~~~
dgellow
But you then lose the ability to revoke a token on the backend, given that
requires a DB lookup. Or you have very short lived token, meaning that you
don’t have real benefits versus an opaque token in DB.

IMHO JWTs only make sense in some constrained contexts, such as:

1\. You want a report, click on “generate”

2\. The processing starts, you receive a token to access the resource

3\. Once the file is created you get can access it by using the token
previously received

In those kind of short term and limited use cases they can make things a bit
nicer as the “report generation service” only need to check the token.

But in practice JWTs are often used used as a general
authentication/authorization mechanism, and that makes little sense (and
brings a lot of overhead).

------
kreetx
This appears to be just the start. There appears to be no longer list of prior
vulnerabilities, but these will come, right?

~~~
mfincham
A couple more from recent history:

[https://insomniasec.com/blog/auth0-jwt-validation-
bypass](https://insomniasec.com/blog/auth0-jwt-validation-bypass)
[https://auth0.com/blog/critical-vulnerabilities-in-json-
web-...](https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-
libraries/)

------
mooreds
My thoughts on this:
[https://twitter.com/mooreds/status/1300932665755856896](https://twitter.com/mooreds/status/1300932665755856896)

~~~
mooreds
Okay, maybe I shouldn't have linked to a twitter thread :).

You shouldn't use alg none unless you have some other way of protecting the
contents of your JWT (like, say, network isolation) and you have verified the
performance impact of signing a JWT is worth the possible security impact.

Not too many folks are in this situation, so in general, sign your JWTs!

~~~
kreetx
I don't quite get why it got down-voted. But if you are the author of the
site, perhaps extend the list with more past vulnerabilities?

~~~
mooreds
Ah, thanks. I'm not the author of the site, just someone with the same
mindset.

------
avmich
The domain name isn't spelled in full. /s

