Authentication

• JWT Security: The Rise of APIs

  • APIs have become popular due to being able to serve multiple resource/apps through one interface. This allows server-side logic to be centralized and reused for all interfaces
  • From a security perspective, this also means we just have to protect implement server-side security on the API that would then protect our server regardless of the interface
  • However with APIs for sessions management cookies are not used, instead Token-Based Session Management is used!
• Token-Based Session Management:

  • Instead of using browser's automatic cookie management, it relies on client-side code for the process. After authenticating, the application provides the user with a token within the request body.
  • Using client-side JS code this token is then stored in the user's LocalStorage
• Token-Based Session Management

  • When a new request is made, JS code must load the token from LocalStorage and attach it as a header. For example, Json Web Tokens (JWTs) are passed in the {Authorization: Bearer} header.
  • Token like JWTs are a way to standardize token-based session management
• Json Web-Tokens:

  • JWTs are self-contained token that can be used to securely transmit session info. It is an open-standard, providing info for any developer or library creator who wants to use JWTs
  • JWT Structure:

  
• JWT Structure

  A JWT contains 3 components, each base64URL encoded and seperated by dots:

  • Header: The header usually indicates the type of token, which is JWT, as well as the signing algorithm used
  • Payload: The payload is the body of the token, which contains the claims. A claim is a piece of info provided for a specific entity. In JWTs, there are registered claims, which are claims predefined by the JWT standard and public or private claims. The public and private claims are those which are defined by the developer.

  
• JWT Structure

  • Signature: The signature is the part of the token that provides a method for verifying token authenticity. The signature is created by using an algorithm defined in the header of the JWT
• JWT Signing Algorithms

  • None: This None algo means no algorithm is used for the signature. This is JWT without a signature, meaning that the verification of the claims provided in the JWT cannot be verified through signature
  • Symmetric Signing: A symmetric signing algorithms such as HS265, creates the signature by appending a secret value to the header and the body of the JWT before generating a hash value. Verification of the header can be performed by any system that has knowledge of the secret key.
• Signing Algorithms

  • Asymmetric Signing: An Asymmetric signing algorithm, such as RS256, creates the signature by using a private key to sign the header and body of the JWT. This is created by generating the hash and then encrypting the hash using the private key.
  • Verification of the signature can be performed by any systems that has knowledge of the public key associated with the private key that was used to create the signature
• JWTs: Security in the Signature

  • JWTs can be encrypted (JWEs). Once a JWT is signed, it can be sent to the client, who can use this JWT whenever needed.
  • We can have centralized auth server that creates the JWTs used on several applications.
  • Each application can then verify the signature of the JWT, if verified, the claims provided within the JWT can be trusted and acted upon
• JWTs: Sensitive Information Disclosure:

  • With tokens the claims are exposed as the entire JWT is sent to the client-side. Some weaknesses include:
  • Credential disclosure with the password hash, or even worse, the clear-text password being sent as a claim
  • Exposure of internal network info such as private IPs or hostname of the auth server
• JWTs: Sensitive Information Disclosure

  • Sensitive info was added to the claim
  • Values such as password or the flag should not be added as claim as the JWT will be sent client-side, these values should be stored server-side in the backed
  • When required, the username can be read from a verified JWT and used to lookup these values

  
• JWTs: Signature Validation Mistakes

  • Not correctly validating JWT signatures. If signatures arent being correctly verified, an attacker could forge a valid JWT token and gain access to another users account
• JWTs: Not verifying the signature

  • If the server does not verify the signature of the JWT, then an attacker can modify the claims within the JWT to whatever they want.
  • While it is uncommon for an API to have no signature validation, all it takes is for one endpoint to fail to do this and this can have adverse affects
• JWTs: Verifying Signatures

  • The JWT should always be verified or additional authentication factors, such as certificates, should be used for server-to-server communication. The JWT can be verified by providing the secret (or public key)
• JWTs: Downgrading to None Signature

  • Another common issue is signature algo downgrades
  • The None Signature was originally for server-2-server communication where the signature may have already been verified by an upstream process
  • However for general, if developers do not deny or lock in the signature, an attacker could simply change their JWT signing algo to `None` which would then cause the library for sig verification to always return True
• JWTs: Downgrading to None Signature

  • Sometimes devs want to ensure their app accepts several JWT signature verification algos, the app would then grab the header of the JWT and parse the found algo into the sig verification component
  • However, when the threat actor specified None as the algo, signature verification is bypassed

  
• JWTs: Downgrading to None Signature: Fix

  • If multiple sig algos should be supported, the supported algos should be supplied to the decode function as an array list:

  
• JWTs: Weak Symmetric Secrets

  • If a symmetric signing algorithm is used, the security of the JWT relies on the strength and entropy of the secret used.
  • If a weak secret is used, it may be possible to perform offline cracking to recover the secret.
  • Once the secret value is known, you can again alter the claims in your JWT and recalculate a valid signature using the secret
• JWTs: Signature Algorithm Confusion

  • The last common issue with signature validation is when an algorithm confusion attack can be performed
  • Specifically happens with confusion between symmetric and asymmetric signing algorithms
• JWTs: Signature Algorithm Confusion

  • If an asymmetric signing algorithm, for example, RS256 is used, it may be possible to downgrade the algorithm to HS256. In these cases, some libraries would default back to using the public key as the secret for the symmetric signing algorithm.
  • Since the public key can be known, you can forge a valid signature by using the HS256 algorithm in combination with the public key.