When it comes to IT security, much attention is given to the terms authorization and authentication. Modern and conventional frameworks like OAuth or OpenID as well as various business applications use the JSON Web Token standard. The security options offered by JSON Web Tokens use two different standards: JSON Web Signature (JWS) and JSON Web Encryption (JWE). This article will focus only on signed JWTs (JWS) and explain how they are used and developed in addition to shedding light on their security vulnerabilities.

What is a JWT?

A JSON Web Token (JWT) is an access token that meets the RFC 7519 standard and transfers information between different parties in the form of a JSON object. The token contains the required information, which is why it can be used to authenticate or transfer information between the front-end and back-end, for example. The content of the token is base64url-encoded and the information contained in the JWT is therefore available in plain text. It is possible, however, to verify and sign the JSON Web Token to prevent manipulation of the token.

Structure of signed JWTs

A signed JSON Web Token has three sections: The JOSE header, the JWS payload and the signature. Each element is separated by a period ..

Example of a JSON Web Token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6InNjaXAgQUciLCJhZG1pbiI6dHJ1ZSwiaWF0IjoxNTE2MjM5MDIyfQ.dX_ACtDZVh9ZKaDMLmZFURrh7o5R99-6MEulWUFCaT0

The JWT example decodes:

• Header: {"alg": "HS256", "type": "JWT"}
• Payload: {"sub": "1234567890", "name": "scip AG", "admin": true, "iat": 1516239022}
• Signature with HS256: dX_ACtDZVh9ZKaDMLmZFURrh7o5R99-6MEulWUFCaT0 (uses the scipAG secret)

JOSE headers and unsecured JWTs

The first part of a JWT is the JOSE (JavaScript Object Signing and Encryption) header. It contains information about the algorithm used to sign the token. For example, a token can be signed with HMAC algorithms and a secret or using a public/private key method, such as RSA or ECDSA. All usable algorithms are described in the specification JSON web algorithms (JWA).

What is striking here is the algorithm is set to none. This means that it is possible to hack a JWT by setting the algorithm to {"alg":"none"} and removing the signature. If the back-end does not carry out any signature verification, the manipulated token can be readily accepted. That’s why it is essential to verify the signature. Otherwise, the information in the token’s payload can be changed to anything. For instance, changing the user role can help to achieve a privilege escalation.

JWS payload in the form of a JWT claims set

The second section of the token – the JWT claims set – is a JSON object that contains the information (claims) to be transferred. There are three classes of JWT claim names:

• Registered claim names
• Public claim names
• Private claim names

The names must always be unique. The predefined claims are explained in RFC 7519.

The JWS payload is also base64url-encoded, so it is important that no sensitive personal data is sent with a JWT, for example. Otherwise, an attacker can analyze a JWT to find this information, determine the structure of email addresses or usernames, or discover the exact designation of user roles. This is because signing the token merely prevents manipulation of the same – the information it contains is basically always visible in plain text. Making changes to a JWS payload is simple. Burp Suite, for example, offers various extensions, including JSON Web Tokens (JOSEPH) to help with this task.

The signature and cracking a secret by brute force

The third and final element of the token is the signature, which has an RFC 7515-compliant structure. The signature is also base64url-encoded and is created with the selected algorithm from the JOSE header. The signature is designed to prevent a token from being manipulated during transmission.

The signature of the JWT can, however, be vulnerable as well. If the HS256 algorithm is selected and a weak secret used, the secret can be cracked. Hashcat in particular includes a function for this purpose (hash mode 16500).

./hashcat64.bin --session <project> -a 16500 -m <jwt> -w 3 -r <rulepath> <dictpath>

As soon as the secret has been figured out, the token can then be manipulated or regenerated at will and signed with the corresponding secret. An online JWT generator can even be used for this purpose.

Updating unknown access tokens with your own refresh token

In general, there are access tokens and refresh tokens. If the validation of access and refresh tokens is not configured correctly, under certain circumstances it may be possible to refresh an access token (including an expired one) belonging to another user with your own refresh token if the hacker is able to get their hands on it. This can be done if only the validity of a refresh token is verified rather than the ownership of the access token.

The conditions for the request are based on the information about the endpoint where a new token is generated, an Authorization: Bearer header with the access token that has expired, as well as the refresh token in the body of the request.

Example of refreshing an unknown access token with one’s own refresh token:

POST /scipAG/JWT/refresh/newToken
[Various Headers]
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6InNjaXAgQUciLCJhZG1pbiI6dHJ1ZSwiaWF0IjoxNTE2MjM5MDIyfQ.dX_ACtDZVh9ZKaDMLmZFURrh7o5R99-6MEulWUFCaT0
[Various Headers]

{"refresh_token": "thisIsAnExampleOnly"}

Comparison to SAML 2.0 and SWT

Compared to SAML (Security Assertion Markup Language), a signed JSON Web Token has the advantage that it is easy to implement, since it is small enough to easily fit into an HTTP header. Conversely, it is not possible for a JWT to completely replace an SAML. SAML 2.0 offers more security options, but these involve greater complexity and scope. The use of XML, XML digital signature (DSIG) and XML canonicalization are reasons why SAML is so complex.

Compared to simple web tokens (SWTs), a JWT offers greater flexibility and more options. While both claim names and claim values are strings in the case of an SWT, the claim values of the JWT can assume any type of JSON. Moreover, SWT only supports HMAC SHA-256, while JWT lets you choose between different algorithms.

Conclusion

Signed JSON Web Tokens are secure as long as they are configured correctly and carefully. However, it is important to ensure that no sensitive information, such as the username, user role, etc., is sent with the token, because this data is only base64url-encoded and is not encrypted during transmission.

About the Author

Valérie Kastner studies Business Economics with focus on Risk & Insurance at the Zurich University of Applied Sciences. After several years in underwriting and technical center for insurances, she has been working in IT security since 2018 with a focus on Web Application Security Testing and Social Engineering. (ORCID 0000-0002-9214-572X)

Links

• http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
• https://docs.microsoft.com/en-us/previous-versions/azure/azure-services/hh781551(v=azure.100
• https://emtunc.org/blog/11/2017/jwt-refresh-token-manipulation/
• https://hashcat.net/wiki/doku.php?id=example_hashes
• https://jwt.io/
• https://jwt.io/introduction
• https://medium.com/101-writeups/hacking-json-web-token-jwt-233fe6c862e6
• https://medium.facilelogin.com/jwt-jws-and-jwe-for-not-so-dummies-b63310d201a3
• https://oauth.net
• https://openid.net/what-is-openid
• https://portswigger.net/
• https://portswigger.net/bappstore/f923cbf91698420890354c1d8958fee6
• https://scotch.io/tutorials/the-anatomy-of-a-json-web-token
• https://tools.ietf.org/html/rfc3275
• https://tools.ietf.org/html/rfc7515
• https://tools.ietf.org/html/rfc7518#section-3.1
• https://tools.ietf.org/html/rfc7519
• https://tools.ietf.org/html/rfc7519#section-4
• https://tools.ietf.org/html/rfc7519#section-4.1
• https://www.w3.org/TR/xml-c14n11/