JWT [JSON WEB TOKENS]

Currently reading:
 JWT [JSON WEB TOKENS]

zazalover4000

Member
LV
1
Joined
May 11, 2023
Threads
11
Likes
5
Awards
4
Credits
2,027©
Cash
0$
As we all know, websites uses cookies and sessions to control and maintiain access control and authorization. JWT is also a type of cookies which is used to track the infromation about users.
But then you will ask me why we need JWT when we already have other session cookies like session-ids, wether it might be phpsiessionid or django session ID.
The answer is very simple.
Another session management system keeps all user information on a server and creates a special token for each user to use in future requests to confirm their authorization.
For example:
PHPSESSID=1a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p
Now, the token here doesn’t contain any information about the user. The website will get this token in the next request and validate if it’s a valid one. Sometimes these tokens are the directory name where the user’s data is stored in. If the directory exists it will be validated, if not it will be rejected.
This strategy can become troublesome when user numbers increase because the website would have to store all of the user’s data on the server, which could cause slowness, and it can be hard to manage.
Here comes the JWT to save us from these problems. The jwt stores all the user-related information on the client side like his `name`, `id`, `created time` etc. All the data is cryptographically signed and the website would just have to validate if the data is signed correctly with its specific algorithm and secret key. This makes the whole process seamless and less chaotic.

STRUCTURE OF JSON WEB TOKEN.

The typical JWT token consists of 3 main parts.
HEADER
PAYLOAD
SIGNATURE
All of these parts are separated by (.)a dot. All of these parts are also encrypted with `base64`.
FOR EXAMPLE:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

You can see the 2 dots between the token seprating the HEADER , PAYLOAD, SIGNATURE.
This token can be decrypted using the base64 decoder, or you can go to INFAMOUS
jwt.io

and Paste this token there, it will show you the data it contains.
0*boCl0u9-MLY4zlar.png


HEADER:​

As we can see the header part contains the algorithm and the type. The algorithms that are mostly used are.
  • HMAC
    HMAC methods produce a signature using a secret key. HS256 (HMAC-SHA256) and HS512 are the two HMAC algorithms for JWT that are most frequently used (HMAC-SHA512).
  • RSA
    RSA Algorithm used the public and private keys to generate and validate the Jwt’s RSA 256 and RSA 512 are the most commonly used ones.
  • ECDSA
    Elliptic Curve Digital Signature Algorithms use an elliptic curve key pair to generate and verify signatures. The most commonly used ECDSA algorithms for JWT are ES256 and ES512.

PAYLOAD:

The payload section contains information about the user.
For example:

{
"iss": "portswigger",
"exp": 1648037164,
"name": "Carlos Montoya",
"sub": "carlos",
"role": "blog_author",
"email": "carlos@carlos-montoya.net",
"iat": 1516239022
}
Like the above example, the payload section contains the name, email, role, expiry date, and the issue.
SIGNATURE:
The signature part contains the signature that validates the above portion. If HMAC is used, the signature is generated by a secret key or in other cases public and private keys.

Now we have a strong understanding of what JWT is we can discuss how JWT can be exploited and what are techniques to test when we are up against a JWT.

EXPLOITING JWT

There can be multiple ways of exploiting the JWT tokens.
1. Flawed signature Verification in Backend
2. JWT header parameter injections.
3. Brute forcing the Secret Keys If HMAC algorithm is used.
4. JWT Alorithm Confusion attacks

FLAWED SIGNATURE VERIFICATION.

Sometimes, the developers failed to implement a correct way to verify the signature of JWT tokens in the backend. Which can cause a heck lot of problems. When the signature verification is not implemented correctly, the attacker could change their username to admin and become an admin which could cause problems.
There are 2 main cases for this kind of flaw.
  • The application may not verify the signature part all together. That means if you send the JWT without the last signature part the application will accept that as a valid token.
For Example:
We got a jwt after we logged in.
0*Yq79omgvusYOeHs5.png


Let’s change the token payload to carlos and remove the signature.
0*JmxuBxlreE0AMeYw.png


We can see we are carlos now because the application does
OR
  • We can also perform the *None Algorithm Attack* we need to set the alg parameter to none in the header, this will make the application skip the signature verification.
0*ZyfB_L6dD3Lv-w5i.png


We can see the signature is striped and we are admin.
0*Edg6KHW9lgPcavB9.png


The Next type of vulnerability that can be used to attack JW’s are.

BRUTE FORCING THE SECRET KEY

As we discuss the algorithms that are used to generate the signatures, one of them uses the secret key to create the signature named HMAC.
Sometimes developer uses weak secret keys to make the signature which can be brute forced easily.
We can find many well-known secrets wordlists on the internet like this
github.com

Other than that, we just need to run the hashcat command with the wordlist and the jwt token.
hashcat -a 0 -m 16500 eyJraWQiOiIzMGFlZGM2Yy1iZjE3LTQzMGItYjY3Zi0yYzg0ZDcxZTdjYmUiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJwb3J0c3dpZ2dlciIsInN1YiI6IndpZW5lciIsImV4cCI6MTY3NzQ5MTk0NX0.QZ52SOv9T_a0RF3ka-3MKwUhS2uDwu6xoeGOn-lc32c jwt-sercrets.txt
0*X6QZdNtKFqITQlrv.png


Now we can go to
jwt.io

and sign our new token with the secret key.
0*tD01t7cIwdwjpAv1.png


We can sign new valid tokens and we can become any user we want.
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Tips

Similar threads

Top Bottom