JWT Security

Introduction

• The Rise of APIs: APIs have become essential for modern web and mobile applications, enabling centralized server-side logic and code reuse.
• Token-Based Session Management: A modern approach to session management that uses tokens (e.g., JWTs) instead of traditional cookies.
• Benefits of Token-Based Approach:
  • API-centric: Suitable for various interfaces, not just web browsers.
  • Flexibility: Can be used in different contexts and architectures.
  • Security: Offers improved security when implemented correctly.

JWT Structure

• Components:
  • Header: Contains token type and signing algorithm (e.g., {"alg": "HS256", "typ": "JWT"}).
  • Payload: Contains claims (data about the user or session).
  • Signature: Ensures the integrity and authenticity of the token.
• Encoding: Each component is Base64Url encoded and separated by dots.

Signing Algorithms

• None: No signature is used (insecure).
• Symmetric: Uses a shared secret key (e.g., HS256).
• Asymmetric: Uses a public-private key pair (e.g., RS256).
• Security Implications:
  • The None algorithm should never be used in production.
  • Symmetric algorithms rely on the secrecy of the shared key.
  • Asymmetric algorithms provide stronger security.

Common JWT Vulnerabilities

• Sensitive Information Disclosure:
  • Avoid storing sensitive data (e.g., passwords, internal system information) in JWT claims.
  • Store sensitive data on the server-side and use the JWT to identify the user for retrieval.
• Signature Verification Issues:
  • Not Verifying: Always verify the JWT signature to prevent tampering.
  • Downgrading to None: Prevent downgrading the signing algorithm to None.
  • Weak Symmetric Secrets: Use strong and random secrets for symmetric algorithms.
  • Algorithm Confusion: Avoid mixing symmetric and asymmetric algorithms, which can lead to confusion and potential bypasses.
• Token Lifetime:
  • Set appropriate expiration times (exp claim) for JWTs.
  • Consider using refresh tokens for longer-lived sessions.
• Cross-Service Misconfigurations:
  • Use the aud (audience) claim to restrict JWT usage to specific applications.
  • Verify the audience claim on the application side to prevent cross-service relay attacks.

Practical Examples

• Example 1: Sensitive Information Disclosure: Demonstrates how sensitive data (e.g., password hash, flag) can be exposed if included in JWT claims.
• Example 2: Not Verifying the Signature: Shows how disabling signature verification allows forging JWTs and modifying claims.
• Example 3: Downgrading to None: Demonstrates how changing the algorithm to None can bypass signature verification.
• Example 4: Weak Symmetric Secrets: Shows how weak secrets can be cracked offline, allowing attackers to forge JWTs.
• Example 5: Algorithm Confusion: Demonstrates how downgrading from an asymmetric to a symmetric algorithm can lead to signature bypass if the library uses the public key as the secret.
• Example 6: Token Lifetime: Shows the risk of not setting an expiration time (exp claim) for JWTs.
• Example 7: Cross-Service Misconfiguration: Demonstrates a cross-service relay attack where a JWT intended for one application is used to gain unauthorized access to another application.

Key Takeaways

• JWTs are a powerful tool for session management, but they require careful implementation to ensure security.
• Always verify the JWT signature using the correct algorithm and secret or public key.
• Avoid storing sensitive information in JWT claims.
• Set appropriate expiration times and consider using refresh tokens.
• Use the audience claim to restrict JWT usage to specific applications.