Typical "sins" of using JWT

Salute,

I recently crossed paths with colleagues with whom I recorded a podcast on secure development - info here.

It so happens that I would like to share with you an interesting approach, somewhat reminiscent of the classic model. These guys involved in consulting and Compliance have reviews regarding information security risks on the topic of vulnerabilities in development.

One of the interesting posts is this one. The author examines bypassing authentication on the web, describes attack vectors and how to minimize them. After reading, you can see that depending on the case, we can focus on the principle itself and tighten it up.

Let's look at JWT sessions in the same vein using the example of a regular implementation

Let's look at such a case, when JWT is used, but the issuing mechanism is simply implemented without any security measures, which usually happens in practice, since they pay for a quick feature in the product that would work and be easy. First, let's figure out what it is:

JWT (Json Web Token) is an authentication token for a user session, that is, the user himself for requests to API methods. Needed to transfer credentials to the server for each called method.

Thus, the mechanism itself shows that we can limit the availability of credentials externally when interacting, for example, with a counterparty and us via API, and at the same time we do not need to contact the database directly for validation, which extends the time for executing the procedure. You can read in detail here.

In this way, we explicitly ensure that encrypted values ​​can always help reduce the risk of leakage and hacking of user data if it is intercepted. It is also worth supplementing the mechanisms with special methods, such as:

- by limiting its lifetime

- validation initially checks the token lifetime

- blacklist

- secure data transmission channel

- session reset after the end of the token's lifetime in an inactive state

- binding to the action button in case of user activity inside the authenticated application window

- debug on jwt.io outside the development team for information security tests by modification

- do not transmit sensitive user data (base)

- use long key phrases and change them periodically

- forced change of tokens

- implement a white list of allowed algorithms on the application side

- sanitize data received from users

- we can simply revoke the token at any time, and then reissue it

- we can additionally use version control

- strengthen the signature scheme according to the Escrow model

- cover with salt (salt) in specific cases

It turns out that we have an access token - access for each request, a refresh token - re-issue of the pair, as well as a specified time-delay life value. The structure itself consists of data in the payload, header as a type and an encryption algorithm, cripto signature.

Total: the basic mechanism only implements updating and transmission, but without additional security measures attacks of the following type can be implemented:

- lack of signature verification, where if you set alg none, the server will accept the unsigned token explicitly with payload and rights for example admin

- manipulation of key identifiers due to the lack of key id complexity

- selection of a symmetric signature key and selection of a key phrase

- for asymmetric ones by changing the algorithm via hex using logical implementation errors

- token interception and UrlDecode

And yes, it’s still worth looking at colleagues and their cases at AKTIV.CONSULTING @aktivcons.

#reco #research #secrets #pmcases