- 21 Eki 2015
- 477
- 1
JSON Web Tokens (JWTs) provide a standardized way to exchange information using locally-stored JSON objects. They are used as authentication tokens, especially with single sign-on, and can be digitally signed and encrypted for maximum security. But there are also many ways to get JWT security wrong, as demonstrated by Netsparker security researcher Sven Morgenroth.
Appearing on episode 673 of the Pauls Security Weekly cybersecurity podcast, Sven introduced JSON Web Tokens and demonstrated some of their security pitfalls. Watch the full interview and presentation below and read on for a summary of the main points.
What Are JSON Web Tokens?
JWTs provide a standardized way of storing and transmitting data in JSON format. Each JSON Web Token consists of three strings in base64url encoding, separated by dots: a header, a payload, and a signature. The header and payload are JSON objects, with the header containing token mêtadata (in particular the signing algorithm to be used) and the payload containing the actual token data. The signature is calculated by applying the specified algorithm to the header and payload combination.
Secure JWTs in a Perfect World
In the context of web application security, JSON Web Tokens are typically used to securely store session state on the client side, for example in a cookie or in local browser storage. This allows websites to authenticate user sessions as part of a stateless session management scheme.
When correctly implemented and used, JSON Web Tokens can be a powerful and highly secure method of storing and exchanging user identity information. Unlike most other plaintext cookies in modern web frameworks, JWTs can be encrypted and digitally signed to prevent tampering and session spoofing.
How JWT Security Can Go Wrong
The idea behind JSON Web Tokens was to have a common JSON-based format to store and exchange user information. The JWT specification provided in RFC 7519 is very detailed, flexible, and future-proof, anticipating many different use cases and adaptations. This includes provisions for encrypting and digitally signing tokens to make them a cryptographically secure information carrier.
The problem with JWT-based authentication is that it is easy to get it wrong and hard to debug. In many cases, a misconfigured JWT authentication scheme might silently fail, for example allowing any user to access a protected resource or tamper with token payloads. This is partly due to the multitude of available options and algorithms and partly due to the inherent challenges of developing authentication features. It is all too easy to assume that authentication works properly when, in reality, you simply missed a test case or forgot to re-enable the right algorithm after a debugging session.
How to Avoıd Common JSON Web Token Mistakes
In his presentation, Sven discusses several common issues related to implementing and using JSON Web Tokens, including:
No encryption algorithm specified: If none is specified as the algorithm value, tokens are unsigned and unencrypted plaintext that can be freely modified by attackers. Production builds should never use the none algorithm.
Key confusion: In some implementations, it may be possible to change the encryption algorithm from asymmetric to symmetric, causing the application to use the public key as a regular symmetric encryption key. This allows an attacker to correctly sign any payload.
No signature verification: Common programming errors can cause the application to silently accept any signature without proper verification. Unless covered by suitable test cases, this can completely disable the authentication process.
Use of trivial secrets: For symmetric encryption algorithms, attackers can locally bruteforce weak encryption keys and then use them to sign malicious payloads.
Beyond following best practices for application development and testing, the best way to avoıd these pitfalls is to use JWT functionality from a tried and tested library or framework instead of rolling your own. While implementing your own tokens may seem straightforward enough, security is all about eliminating gaps and even a single bug or oversight in the authentication process can open the door to attackers.
Appearing on episode 673 of the Pauls Security Weekly cybersecurity podcast, Sven introduced JSON Web Tokens and demonstrated some of their security pitfalls. Watch the full interview and presentation below and read on for a summary of the main points.
What Are JSON Web Tokens?
JWTs provide a standardized way of storing and transmitting data in JSON format. Each JSON Web Token consists of three strings in base64url encoding, separated by dots: a header, a payload, and a signature. The header and payload are JSON objects, with the header containing token mêtadata (in particular the signing algorithm to be used) and the payload containing the actual token data. The signature is calculated by applying the specified algorithm to the header and payload combination.
Secure JWTs in a Perfect World
In the context of web application security, JSON Web Tokens are typically used to securely store session state on the client side, for example in a cookie or in local browser storage. This allows websites to authenticate user sessions as part of a stateless session management scheme.
When correctly implemented and used, JSON Web Tokens can be a powerful and highly secure method of storing and exchanging user identity information. Unlike most other plaintext cookies in modern web frameworks, JWTs can be encrypted and digitally signed to prevent tampering and session spoofing.
How JWT Security Can Go Wrong
The idea behind JSON Web Tokens was to have a common JSON-based format to store and exchange user information. The JWT specification provided in RFC 7519 is very detailed, flexible, and future-proof, anticipating many different use cases and adaptations. This includes provisions for encrypting and digitally signing tokens to make them a cryptographically secure information carrier.
The problem with JWT-based authentication is that it is easy to get it wrong and hard to debug. In many cases, a misconfigured JWT authentication scheme might silently fail, for example allowing any user to access a protected resource or tamper with token payloads. This is partly due to the multitude of available options and algorithms and partly due to the inherent challenges of developing authentication features. It is all too easy to assume that authentication works properly when, in reality, you simply missed a test case or forgot to re-enable the right algorithm after a debugging session.
How to Avoıd Common JSON Web Token Mistakes
In his presentation, Sven discusses several common issues related to implementing and using JSON Web Tokens, including:
No encryption algorithm specified: If none is specified as the algorithm value, tokens are unsigned and unencrypted plaintext that can be freely modified by attackers. Production builds should never use the none algorithm.
Key confusion: In some implementations, it may be possible to change the encryption algorithm from asymmetric to symmetric, causing the application to use the public key as a regular symmetric encryption key. This allows an attacker to correctly sign any payload.
No signature verification: Common programming errors can cause the application to silently accept any signature without proper verification. Unless covered by suitable test cases, this can completely disable the authentication process.
Use of trivial secrets: For symmetric encryption algorithms, attackers can locally bruteforce weak encryption keys and then use them to sign malicious payloads.
Beyond following best practices for application development and testing, the best way to avoıd these pitfalls is to use JWT functionality from a tried and tested library or framework instead of rolling your own. While implementing your own tokens may seem straightforward enough, security is all about eliminating gaps and even a single bug or oversight in the authentication process can open the door to attackers.
Excerpted
