17 February 2021
Reading time: 2 min
Many attacks are based on a set of well-matched factors. The more popular the technology - the more likely the factors
1. Will coincide;
2. We can find and use them.
JWT is incredibly popular.
And, of course, attacks have such helpers as
Laziness
Economy
Desire to make it faster.
Based on these facts, let's talk about one of the attack vectors and how to defend against it.
Many projects use a staging environment to test their product. This is absolutely the right decision. Sometimes, the staging environment has free access, or the degree of access protection is much lower than it should be. We invite the reader to think about whether this is correct or not. Of course, the url of the environment is easy to predict. Try stg.my-amazing-product.com or staging.my-amazing-product.com. First success?
There are probably test users on staging. You can try admin / admin, admin / password, user / password, etc. Either we can register with the login we are interested in (the attacked login), or simply with any login, counting on integer incremental IDs.
Let's take a look at the example of incremental IDs.
With a probability of 99 percent, there are fewer users on the stg environment than on the production environment.
Thus, after registering on stg, we can get a user with the same id that already exists in the prod environment.
With a very high degree of probability, in the JWT token, the id will be used to identify the user.
Just in case, let's recall the general idea of the JWT. We have a set of fields, including some kind of user ID. These fields are signed with a private key. And all this information is encoded into a string, which is exactly the token.
When the server receives a token, it checks (I would like to believe that it does!) The validity of the signature. If the signature is valid, then we can be sure that the user is authenticated. Feel free to pull out the user's id from the fields and provide access to the resource.
Now to fit our puzzle we need one last piece. Let's assume that we decide to use the same private key in staging and production. Quite a common solution :)
Done! We can get a token on stg, and with this token go to prod from under a user with the same id. The attack was over.
What should we do in this case?
Use different private keys on different environments.
Do not forget to add the domain to the token, and check the domain on the server.
Close access to stg environment.
Arrange a security audit. Unfortunately, even very experienced developers make the mistakes described here. So you can't do without an independent expert's opinion.
P.S. All characters are not fictional. The coincidences are not accidental :)
read more
