JSON Web Token
What is JWT?
JWT, or JSON Web Token, is an open standard used to share security
information between two parties — a client and a server. Each JWT
contains encoded JSON objects, including a set of claims. JWTs are
signed using a cryptographic algorithm to ensure that the claims
cannot be altered after the token is issued.
A JSON Web Token is used to send information and by using a digital
signature it can be trusted and verified. It comprises a compact and
URL-safe JSON object, which is cryptographically signed to verify its
authenticity, and which can also be encrypted if the payload contains
sensitive information.
Structure of JWT
A well-constructed JWT consists of three conjoined Base64url-encoded strings,
separated by dots (.):
• JWT Header: It contains metadata about the type of token and the
cryptographic algorithms used to secure its contents.
{
"alg" : "HS256",
"typ" : "JWT"
}
base64url encoded string: eyBhbGcgOiBIUzI1NiwgdHlwIDogSldUIH0K
• JWT payload (set of claims): It contains verifiable security
statements, such as the identity and information of the user and the
permissions they are allowed.
{
"user_name" : "admin",
}
base64url encoded string: eyB1c2VyX25hbWUgOiBhZG1pbiB9Cg
• JWT signature: It is used to validate that the token is trustworthy and
has not been tampered with. When you use a JWT, you must check its
signature before storing and using it.
signature = HMAC-SHA256(base64urlEncode(header) + '.' +
base64urlEncode(payload), secret_key
-> signature function returns
4Hb/6ibbViPOzq9SJflsNGPWSk6B8F6EqVrkNjpXh7M
A JWT typically looks like this:
Hacking Of JSON Web Token
Since JSON web tokens are used for access control, they often contain
information about the user. If the token is not encrypted properly, anyone can
base64 decode the token and read the token's payload. So, if the token contains
sensitive information, it might become a source of information leaks.
1. None algorithm
JWT supports a “none” algorithm. If the field alg is set to “none”, then any
token can be considered valid if their signature section is set to empty as well.
For example, the following token would be considered valid:
eyAiYWxnIiA6ICJOb25lIiwgInR5cCIgOiAiSldUIiB9Cg.eyB1c2VyX25hbW
UgOiBhZG1pbiB9Cg.
It is simply the base64url encoded versions and no signature is present.
{
"alg" : "none",
"typ" : "JWT"
}{
"user" : "admin"
}
2. HMAC Algorithm
The two most common types of algorithms used for JWTs are HMAC (Hash-based
message authentication) and RSA (Rivest-Shamir-Adleman encryption). With
HMAC, the token would be signed with a key, then later verified with the same
key. As for RSA, the token would first be created with a private key, and then
verified with a corresponding public key.
Let’s assume that there is some application using the RSA tokens. The tokens are
signed with a private key X, which is kept a secret from the public. Then the
tokens are verified with public key Y, which is available to anyone. It is perfectly
fine as long as the tokens are always treated as “RSA tokens”. But, if the attacker
alters the alg to HMAC, they might be able to create valid tokens by signing the
forged tokens with the RSA public key Y.
This is because originally when the token is signed with RSA, the program verifies
it with the RSA public key Y. When the signing algorithm is switched to HMAC,
the token is still verified with the RSA public key Y, but this time, the token can
be signed with the same public key Y (since it’s using HMAC) which uses a
symmetric key, unlike the RSA algorithm which uses asymmetric keys.
3. KID manipulation
KID stands for “Key ID”. It is an optional header field in JWTs, and it allows
developers to specify the key to be used for verifying the token. The proper
usage of a KID parameter looks like this:
{
"alg" : "HS256",
"typ" : "JWT",
"kid" : "1" // use key number 1 to verify the token
}
Since this field is controlled by the user, it can be manipulated by attackers
and lead to perilous consequences.
• Directory traversal
Since the KID is often used to retrieve a key file from the file system, if it
is not sanitized before use, it can further lead to a directory traversal
attack. When this is the case, the attacker would be able to specify any
file in the file system as the key to be used to verify the token.
“kid”: “../../public/css/[Link]” // use the publicly available
file [Link] to verify the token
• SQL injection
The KID could also be used to retrieve the key from a database. In this case, it
might be possible to utilize SQL injection to bypass JWT signing. If SQL injection
is possible on the KID parameter, the attacker can use this injection to return any
value they want.
“kid”: "aaaaaaa' UNION SELECT 'key';--"// use the string "key"
to verify the token
Impact
• Sensitive Information Disclosure
• Compromised Authentication of the user
• Account takeover
• Illegitimate access to the Server Files
• Access to unauthorize SQL Database
Prevention
Developers can effectively mitigate algorithm vulnerabilities by
strictly adhering to several precautions:
• Never let the header of the JWT alone drive verification.
• Know how the algorithms are structured.
• Ensure an appropriate, strong key size is used.
• Use well-known JWT libraries that are not exposed to known
vulnerabilities.
Conclusion
With an increase in the digitalization of nearly everything the
Organization or business firms can face new security vulnerabilities
often, stolen JWT tokens could be a wretched thing for any
enterprise providing online services.
An organization needs to ensure maximum security at the user level
and take crucial precautions to avoid security risks.
With little precautions, one can protect its users and also oneself
from the compromising JSON Web Token.
References
• [Link]
• [Link]
• [Link]