JSON Web Tokens (JWTs) are a compact way to securely transmit information between parties as a JSON object signed with a secret or public/private key pair. JWTs have three parts - a header specifying the signing algorithm, a payload containing claims, and a signature. The document discusses the structure and security concerns of JWTs such as information leakage, weak algorithms, and attacks that modify the algorithm or signature.
Navigating the Deluge_ Dubai Floods and the Resilience of Dubai International...
Jwt Security
1. JSON Web Tokens (JWT) Security
SeidYassin.ApplicationSecurityConsultant.Dtssolution
2. • What is JSON Web Token?
• Why we use JSON Web Tokens?
• When should you use JSON Web Tokens?
• What is the JSON Web Token structure?
• How do JSON Web Tokens work?
• Security Concerns / Attack Types /
Agenda
3. What is JSON Web Token?
JSON Web Tokens are an open, compact and self-contained
industry standard RFC 7519 method for representing claims
securely between two parties.
7. JWT Security : The basics - Sessions
Browser Server Database
POST /login
Username ….
Password ….
Select
Username …. AND Password ….
200 ok
Set-Cookie : SESSIONID = A42
Found
{…….}
Set-Cookie : SESSIONID = A42
Get /Homepage
200 ok
Hello JOHN
Set
ID = A42
Get
ID = A42
Found
{…….}
Memory
9. JWT Security : The basics
Browser
Server
Load Balancer
Server
10. JWT Security : The basics
Browser Load Balancer
Server
Server
Server
Server
11. JWT Security : The basics
Browser Load Balancer
Server
Server
Server
Server
ID=A41
ID=A41
12. JWT Security : The basics
Browser Load Balancer
Server
Server
Server
Server
ID=A41 ?
ID=A41
ID=A41 ??
13. JWT Security : The basics
Browser Load Balancer
Server
Server
Server
Server
Shared
Cache
ID=A41
ID=A42
ID=B41
ID=C40
ID=A41 ?
< Single Point
Of Failure >
14. JWT Security : The basics
Browser Load Balancer
Server
Server
Server
Server
Distributed
Cache
15. JWT Security : The basics
Browser Load Balancer
+ Sticky
Sessions
Server
Server
Server
Server
Distributed
Cache
23. eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwi
bmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2
QT4fwpMeJf36POk6yJV_adQssw5c
JWT Structure : Payload
xxxxxxx.yyyyyyy.zzzzzzz
Payload contains the claims - statements about an entity (typically, the
user) and additional metadata.
• Reserved claims: A set of predefined claims which are not mandatory but
recommended, to provide a set of useful, interoperable claims. Examples: iss
(issuer), exp (expiration time), sub (subject), aud (audience)
• Public claims: These can be defined at will by those using JWTs. But to avoid
collisions they should be defined in the IANA JSON Web Token Registry or be
defined as a URI that contains a collision resistant namespace.
• Private claims: These are the custom claims created to share information
between parties that agree on using them.
30. Security Concern
The leakage of sensitive information
• the payload is transmitted in plaintext, information leakage occurs if there is
sensitive information in the payload
• eg.
• Credentials
• internal IP addresses through the tokens.
31. Security Concern
Weak algorithms for signature
JWT Signing Algorithms
The most common algorithms for signing JWTs are:
HMAC + SHA256 (HS256)
RSASSA-PKCS1-v1_5 + SHA256 (RS256)
ECDSA + P-256 + SHA256 ( ES256)
32. Security Concern
Weak Secret / Brute-Forcing HS256
• conduct offline brute-force attacks against the token by using wordlists of
possible secret-keys
• It is recommended to use sufficiently long (256 bit) keys to safeguard against
these attacks.
Please note the RFC7518 standard states that "A key of the same size as the hash output (for
instance, 256 bits for "HS256") or larger MUST be used with this algorithm."
Tools : jwt-cracker
33. Security Concern
Not Verifying the Algorithm - Signature Stripping attack
Modify the algorithm to none
• Some JWT libraries support the none algorithm, that is, no signature algorithm.
• When the alg is none, the backend will not perform signature verification.
• After changing alg to none, remove the signature data from the JWT (only header + ‘.’ + payload + ‘.’) and
submit it to the server.
35. Security Concern
Not Verifying the Algorithm - Signature Stripping attack
Modify the algorithm to none
CVE-2018–1000531 - INVERSOFT PRIME-JWT
Most of the modern implementations now have an added security check that rejects tokens
set with ‘none’ algorithm when a secret-key was used to issue them.
If you receive a JWT with an unexpected algorithm, type header, etc, discard it, and stop
right there.
36. Security Concern
Changing the algorithm from RS256 to HS256
• The algorithm HS256 uses a secret key to sign and verify each message.
• The algorithm RS256 uses a private key to sign messages, and a public key to verify them.
• If you change the algorithm from RS256 to HS256, the backend code uses the public key as the
secret key and then uses the HS256 algorithm to verify the signature.
Consider the following example code, which could be present at the server:
jwt = JWT.decode(token, public_key)
signing our own token using HS256 with the public key of the RS256 algorithm
The backend code uses the RSA public key + HS256 algorithm for signature verification.
37. Security Concern
Changing the algorithm from RS256 to HS256
const decoded = jwt.verify(
token,
publickRSAKey,
{ algorithms: ['HS256' , 'RS256'] } //accepted both algorithms
)
//header
{
alg: 'RS256' => 'HS256'
}
//payload
{
sub: '123',
name: ‘ahmed ali’,
admin: 'false' => 'true'
}
modification that attacker can make:
39. Security Concern
Changing the algorithm from RS256 to HS256
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9kZW1vLnNqb2VyZGxhbmdr
ZW1wZXIubmxcLyIsImlhdCI6MTU0NzcyOTY2MiwiZXhwIjoxNTQ3Nzk5OTk5LCJkYXRhIjp7Ik5DQ
yI6InRlc3QifX0.2zobdg7sgeApcEaR9ngMTRZT1dkWiMJOWYkelzQu5Z8
Resolution
1. Use only one encryption algorithm (if possible) 2. Create different functions to check different algorithms