JWT: A How Not to Guide

If there were a competition to assess the most effective technology tool of our time, applications would win hands down. Over the past two decades applications have gone through myriad transformations. In their current incarnation, applications are agile and experience-centric. Application programming interfaces (APIs) power these modern applications and with their prevalent use, cybercriminals’ enthusiasm for cracking them is equally growing. In F5 Labs’ 2020 Application Protection Report, we see how this architectural change is driving actualized risk. With 50% of the cases studied for API breaches and disclosures being authentication and authorization related, it is of utmost importance to analyze authentication as an attack vector.

What is JWT?

JSON Web Token (JWT) is a mechanism for authentication and is gaining popularity and experiencing greater adoption. RFC7519¹ defines JWT as a compact, URL-safe means of representing claims to be transferred between two parties. JWT can be instantiated in the form on JSON Web Signature (JWS) or JSON Web Encryption (JWE). While a JWE² represents encrypted JSON, a JWS³ represents signed JSON data. In this article, we delve into details of JWT—specifically JWS—and look at some common exploitation techniques.

Structure of JWT

JWTs are represented as three base64 URL-encoded components separated by two dots. Each consists of a header, payload, and signature, as represented in Figure 1.

Decoding the JWT

Running a base64 decode operation on the header and payload yields the constituents. A quick look reveals that the header field identifies the algorithm used to generate a signature, and the payload consists of the claims and signature used to validate the token (see Figure 2). JWTs support both symmetric HMAC (hashed message authentication code—a shared secret) and asymmetric signatures (a public-private key pair).

Compromising JWT

Signed JWTs are meant to provide integrity, however cybercriminals have discovered misconfiguration and implementation flaws that spill internal information or allow use of altered JWTs. The following are some of the common flaws:

• Information disclosure: At times, application developers try to take advantage of the self-contained nature of JWT and enriched them with sensitive information (for example, an internal IP address). This is most common when JWTs are used to manage sessions. Enriching JWT with confidential information might boost performance but it may not be the most optimal solution and might lead to security gaps.

• Signature abuse: A JWT maintains its integrity by virtue of the signature, which gives the assurance of its authenticity. Weak implementations and poor selection of secrets have often proved to undermine the integrity provided by JWT. Figure 4 illustrates some mechanisms that have been used to abuse the signature.

• • Unsecured JWT: RFC7519 allow the use on no algorithm for JWT signatures. This implies that no validation will be performed with the signature on the header and payload combination.
  • Weak Implementation: Poor implementation of JWT validation has vested hackers in either downgrading a secure JWT to an unsecured JWT or using a key of their choice, undermining the system integrity. Some common examples include:
    
    
    • Setting algorithm choice to “none”: Many open source and commercial JWT libraries have fallen prey to this attack. Hackers simply switch the algorithm to none and modify the payload. Since the library implements the RFC, it disregards the signature field.
    • Using key of hacker’s choice: RFC 7515 provides for optional parameters like jku (JWK set URL), kid (Key ID), and others, which provides information about the key used to sign the JWT. Hackers undermine the signature validation process by forcing the selection of a keys, effectively allowing them to assume any role in the system.
  • Weak secrets: Brute forcing to decipher the secret used for the HMAC is possible. Just like weak passwords, the use of weak secrets makes the process easier for attackers. Multiple open sources libraries¹ are available facilitating this process.
• Replay Attack: JWTs remain valid for their defined lifetime, and since no validation request is made to the issuing server, it is prone to a replay attack.

Conclusion

Security misconfigurations allows the hacker to turn JWTs’ ability to provide integrity into a weakness. Authentication is a widely exploited vector for APIs, and a growing number of microservices and APIs depend on JWT for identity claims. It is strategic to understand the weak points and design defenses to protect against information disclosure and the acceptance of spoofed tokens.