I am facing this JWT token validation issue in one of my projects.
When I create a JWT token and then use the same token in another request and validate, it works fine. But if I change the last character of the token and then check it works fine even then. So it passes the validation even then.
The token shouldn’t be validated when the last character is changed isn’t it?
The client of my project did a Penetration testing and found this issue as a vulnerability.
What you are seeing is normal. I think I have a reference to it somewhere which I will post if I can find it, but if I remember correctly it is related to the way the token content is padded out to a standard length before being encoded, and the character you are changing is just part of the padding.
You will see the same effect if you go to jwt.io and change the last character of the sample JWT from a ‘c’ to a ‘d’ (and possibly other characters). Changing the last char from a ‘c’ to a ‘d’ does not change the base64 decoded value.
As an example, here I mess with the end of a base64 encoded string. It’s only when I replace the last four character that the original string gets mangled:
#Encode the string
$ base64 -i -
The green leg dyed the apple blue in the sky.
VGhlIGdyZWVuIGxlZyBkeWVkIHRoZSBhcHBsZSBibHVlIGluIHRoZSBza3kuCg==
#Decode the string
$ base64 -d -
VGhlIGdyZWVuIGxlZyBkeWVkIHRoZSBhcHBsZSBibHVlIGluIHRoZSBza3kuCg
The green leg dyed the apple blue in the sky.%
#Change last char and decode
$ base64 -d -
VGhlIGdyZWVuIGxlZyBkeWVkIHRoZSBhcHBsZSBibHVlIGluIHRoZSBza3kuCi
The green leg dyed the apple blue in the sky.%
#Change last 3 chars and decode
$ base64 -d -
VGhlIGdyZWVuIGxlZyBkeWVkIHRoZSBhcHBsZSBibHVlIGluIHRoZSBza3kaaa
The green leg dyed the apple blue in the sky%
#Change last four chars and decode
$ base64 -d -
VGhlIGdyZWVuIGxlZyBkeWVkIHRoZSBhcHBsZSBibHVlIGluIHRoZSBza3aaaa
The green leg dyed the apple blue in the skv�%
$
