The application let us authenticate an user and see its privileges.
First thing we need to do know is to do more investigation on the requests that are being made. We do this by setting up our intercepting proxy so we can gain more understanding of the application under test.
After we set up our favourite intercepting proxy we are going to look at the traffic between the server and the front-end. Enter the credentials: username: user | password:user
The first thing to notice is after sucessful logon, the response contains an access token.
The image above shows the access-token contains three base64 encoded splitted with two dots (.) separators, which indicates it's a JSON Web Token (JWT):
Header
Claims
Signature
Last encrypted part, containing the digital signature for the token..
Exploitation
Step 1
A potential attacker can now decode the token in website to check its content.
As shown in the above picture, there are 2 points which can be tampered.
alg header: contains the information of which algorithm is being used for digital signature of the token.
indentity: this information is used by the application to identify which user ID is currently authenticated.
How about checking if the server is blindly accepting the digital signature algorithm as stored by token. Of course, changing the signature would also change the token signature, but, what if the server accepts NONE algorithm?
The NONE algorithm means signature is not required, so the token can be tampered and will be accepted by the server.
=======
Step 2
Header tampering
Now, let's play with the identity:
As the signature is not required, the new tampered JWT token will look like this:
