AppSec All-in-One – All About JWT and its Attacks
Hello all !!! Here is the first write up in “AppSec All-in-One” series. As like I said I will be taking one attack vector at a time and go deeper into it by explaining each layer in that attack. Now, am going to discuss about “All About JWT and its Attacks“. Heads-up: This blog is completely theoretical which helps for easy access and go through the concepts (acts as a revise book for you). A practical walkthrough of all these JWT attacks will be demonstrated in DeDefence YouTube channel. Stay tuned and make sure to subscribe. Why Read This Blog: Because it covers right from fundamentals, attacks, approaches, mitigation. This blog will be very handy for: To prepare for AppSec interviews (Because it is most common topic which is often asked in every interview) Security Professionals Bug Bounty Hunters Developers QA First Things First: JSON Web Tokens (JWTs) have become a cornerstone of modern web applications and APIs, serving as a standardized, self-contained method for securely transmitting information like user authentication and authorization claims. Unlike traditional session tokens, JWTs store data on the client side, which simplifies architecture in distributed systems. However, this convenience introduces a unique and critical attack surface. The security of any system using JWTs is fundamentally dependent on the cryptographic integrity of the token’s signature. This blog synthesizes extensive research on JWT security, revealing that the most severe vulnerabilities stem from improper implementation and flawed signature validation. Attackers can exploit these weaknesses to bypass authentication, escalate privileges, and gain complete control over user accounts. Common attack vectors include: Stripping the signature by manipulating the header algorithm to none Cracking weak Guessable secret keys used for signing Tricking servers into using the wrong algorithm (an “algorithm confusion” attack) to validate a forged token Further risks arise from: Injecting malicious parameters into the token header to control the key verification process, potentially leading to path traversal, SQL injection, and the use of attacker-controlled keys. How to mitigate these hinges on a simple principle: Never trust user-controllable input within the token before its signature is rigorously verified. Security best practices mandate the use of strong, high-entropy secret keys, robust cryptographic algorithms, and strict server-side validation that enforces a specific, expected algorithm. By adhering to secure implementation guidelines—including using up-to-date libraries, setting short token expiration times, avoiding sensitive data in the payload, and storing tokens securely—organizations can leverage the power of JWTs without succumbing to their considerable risks. The Anatomy of a JSON Web Token (JWT) At its core, a JSON Web Token (also known as a “jot”) is a compact, URL-safe standard (RFC 7519) for creating data with an optional signature and encryption. Its payload holds JSON that asserts a number of “claims.” Because it is self-contained, all the information needed to verify the user is inside the token itself, reducing the need for server-side session storage. The Three Parts of a JWT A JWT is composed of three distinct parts, separated by dots (.), each of which is Base64Url encoded. HEADER.PAYLOAD.SIGNATURE Let’s examine a typical token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaXNBZG1pbiI6ZmFsc2V9.EypViEDiJhjeuXgjtGdibxrFPFZyYKn-KqFeAw3c2No About Header: The header provides metadata about the token, primarily the signing algorithm used and the token type. alg: Specifies the cryptographic algorithm used to sign the token, such as HS256 (HMAC with SHA-256) or RS256 (RSA with SHA-256). This field is the source of several critical vulnerabilities. typ: Declares the token type, which is almost always JWT. About Payload: The payload contains the claims, which are statements about an entity (typically the user) and additional data. The data is structured as a JSON object. Decoded Payload commonly consists of: Registered Claims: Predefined claims like iss (issuer), sub (subject), aud (audience), exp (expiration time), and iat (issued at). Public Claims: Custom claims defined to avoid collisions, usually registered in the IANA JSON Web Token Claims registry. Private Claims: Custom claims created for information sharing between parties. Titbits: The header and payload are only Base64Url encoded, not encrypted. And also keep in mind that the header and payload are Base64Url encoded/decoded not Base64 encoded/decoded. This means anyone who intercepts the token can easily decode and read its contents. Therefore, sensitive information like passwords, credit card numbers, or social security numbers should never be stored in a JWT payload. About Signature: The signature is the cryptographic component that guarantees the token’s integrity. It is created by signing the encoded header and payload with a secret or private key, using the algorithm specified in the header. If an attacker modifies the header or payload, the signature will no longer match when the server re-calculates it, thus invalidating the token—assuming the signature is properly verified. JWS vs. JWE: Signing vs. Encrypting The term JWT is often used interchangeably with JSON Web Signature (JWS), which is the most common implementation. JWS (JSON Web Signature): The token is signed to ensure data integrity, but the payload is readable. It proves that the data has not been tampered with. JWE (JSON Web Encryption): The token’s payload is encrypted, providing confidentiality. The content is hidden from parties who do not possess the decryption key. * This blog primarily focuses on JWS, as it is more widely used and is the source of the most common JWT vulnerabilities. Titbits: JWT tokens can be implemented “path-wise” in the same domain. For example: JWT token 1 can be used in domain.com/profile, JWT token 2 can be used in domain.com/cart. So here two JWT tokens have been used for two different paths in single domain. So have a keen observation on implementation of JWT tokens in all the paths of the target domain. The Attacker’s Playbook: Common JWT Vulnerabilities and Exploits The security of JWTs is brittle; a single implementation flaw can lead to a complete authentication and authorization bypass. The following sections detail the most prevalent attack vectors in JWT. Here you go !!! Attack 01: JWT Token Sent in GET Method Vulnerability: Sending a JWT as a query parameter in a URL (e.g., example.com/api/data?token=eyJ…) instead of in a secure Authorization header. URLs are frequently logged by browsers, proxies, and web servers. Relatable Example: It’s like writing your house key code on the outside of the