# What is JWT?
JWT stands for JSON Web Token. It is an open standard that defines a concise way for securely transmitting information (in the form of JSON object) between two users.
Key points of JWT:-
- Security — To make sure the information is exchanged between authorized users
# JWT Structure
JWT consists of three parts separated by a dot(.)
Header.Payload.Signature
If We want to know the contents of our JWT we can visit jwt.io (talking about the above code)
Hereafter decoding Our JWT we can also notice that Header and Payload is simple base64url encoded text. We can use any base64url decoder to get the clear text of Header and Payload.
# Now What is base64url encoding and how it’s different from base64 encoding
Base64url is similar to Base64 with some modifications because using base64 in GET parameters or HTTP Headers might cause some problems.
Changes in base64url are:-
- (+) is replaced by (-)
- (/) is replaced by (_)
- (=) is completely removed
Talking about the Signature part it is not encoded using base64url encoding rather it uses other cryptographic algorithms for the above example we can see that it is using the SHA256 algorithm.
# How JWT Works
If a client wants to get some information from a resource server it will send a fetch request to the server but the resource server doesn’t know whether that client is authorized to read that information or not.
For that client first, send its credentials to the authorization server then it checks that with a database if found the correct server will provide a JWT token to the client to access those resources.
This token will be valid for all the servers who accept that authorization server token.
If an attacker will send a fetch request the access will be denied because it doesn’t have a valid token if it wants to gain access to those resources for that it either needs the credentials of a valid client so it can request for JWT token or it requires signing key (that is stored in authorization server) so that it can create its own JWT token and access the resources.
Talking about the Header of the JWT token it consists of two parts
The type that is jwt and the algorithm that must be used while validating the signature, it kinda metadata provides information to the authentication server.
MOGxk7Ybm9sxNgr_VCGy_gm1V4ePT6GB8fkDr62lcAk
JWT Signature consists of four parts: header, payload, key, and algorithm, and based on that sting is generated and appended at the end of the header and payload.
Now, How does the signature part work, it’s recalculated using the information and compared with the signature attached by the client to verify its authenticity. The two most commonly used algorithm in the JWT signature is HS256 and RS256.
Security issues that might be present in HS256:
- Key must be distributed to all servers
- Only one server needs to be compromised to get access to others
- Brute forcing shared key
Why RS256 is better:
- The private key is known to only authorization server
- Only a server with the private key can create a new token
- RSA keys are used in this process and they are long enough to prevent brute-forcing.
JWT Attack & Defence
Possible issues:-
- Use of none algorithm
- Signature stripping
- Cracking weak shared secrets
- Substitution attack
$ None algorithm in which no signature is used in JWT, It only consists of header and payload
-> None Algorithm
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiMW52M250MHIiLCJzdWIiOiJKV1QgVEVTVCJ9.
It is supported by many JWT frameworks but uncommon to encounter during security assessments.
In this type of attack, we have less privlaged users and we want to get information of some other user or root, We get the JWT of this user can decode that in any online decoder or burpsuit and change the user as per ower wish and with the new create JWT we can get the information of another user we are looking for and the reason we are able to do so is that it doesn’t perform any signature check as no signature is present.
-> Signature Stripping
In this type of attack, we modify the payload to get another user’s or root data but also modify the header algo part to none and base64url encode it and append it with modified payload and remove the signature completely.
Now when the request reaches the resource server it will give us the information we are looking for.
This happens because none is also listed in the array of the algorithm allowed in the source code and can be easily mitigated just by enforcing strict HS256 or RS256 algo decoding while validating the token.
In short in the above scenario user was allowed to choose the algorithm to decode the token for verification and we need to stop that to secure the application
-> Cracking weak shared secrets
JWT can be brute force using tools like: https://github.com/lmammino/jwt-cracker
If cracked attacker can craft his own JWT
The mitigation to this is using strong secrets that can’t be brute-forced :)
-> Substitution attack
In this type of attack, JWT is using RS256 (mean using RSA algo to create signature), we will capture the JWT and modify the payload as per our need then modify the header algo part from RS256 to HS256 and encode it using base64uel encoding now using the modified header and payload and the public key (assuming it is publicly available as it’s mostly is) we create a new JWT can using that to access the resource we can get whatever we want.
This happens mostly because the validate part of the server allows both HS256 and RS256 to decode the token for validating the JWT.
Mean user can define which algorithm to use at the time of validating
The flaw here is RS256 use private and public key but the HS256 use the same key for generating and validating.
Mitigation of this is to only use RS256 and not allow HS256 anywhere :)
Thank you
