This Tiny JWT Mistake = Massive Bug Bounty

### Overview This presentation explores real-world techniques used by attackers to tamper with, forge, and exploit JSON Web Tokens (JWTs) to bypass modern web application authentication. Beyond fundamental vulnerabilities in token implementations, the speaker demonstrates how environment misconfigurations—specifically sharing signing secrets between development and production environments—can lead to severe vulnerabilities such as invite-only bypasses and account takeover.

### Key Topics - **JWT Architecture and Algorithms**: Structure of JWTs (Base64-encoded header, payload, and signature) and the core distinctions between symmetric signing (HS256 using a shared HMAC secret) and asymmetric signing (RS256 using private/public key pairs). - **Algorithm Tampering & Weak Secrets**: Exploitation via the `none` algorithm and brute-forcing weak HS256 secret keys using dictionaries like `rockyou.txt` or default secrets sourced from public repositories. - **Algorithm Confusion Attacks**: Forging tokens by converting an RS256 token to HS256 and signing it using an exposed public verification key as the HMAC secret. - **Cross-Environment Token Reuse**: Exploiting differences between dev and production access controls when both systems rely on identical signing secrets. - **Signed Session Cookies and Framework Tokens**: Expanding beyond JWTs to target signed cookies and tokens in frameworks like Django, Flask, and Express.

### Technical Details - **Algorithm "none" Attack**: Attackers strip the signature, alter the header algorithm to `none`, and craft custom payloads that poorly configured or legacy backends accept without verifying. - **Secret Key Cracking**: Attackers brute-force HS256 tokens signed with predictable secrets (such as `secret1`, `jwt123`, or `password`) using wordlists like `rockyou.txt` or GitHub scrapers, allowing them to modify user IDs or roles and resign valid tokens. - **Algorithm Confusion Mechanics**: In misconfigured apps expecting RS256, attackers change the header to HS256. If the server does not enforce the algorithm, it may evaluate the token using its RS256 public key as the HMAC secret key. Attackers obtain this public key—often by fuzzing with `ffuf` or checking within the `/.well-known/` directory—and sign an arbitrary token using that public key. - **The Dev-to-Prod Case Study**: The speaker discovered an open development instance (`app-dev.site.com`) of an invite-only production web application. After signing up without an invite code on the dev site, the speaker obtained a valid JWT. Because both development and production environments shared the exact same signing key, the speaker submitted the dev token to the production site. The token was accepted, successfully bypassing the invite requirement and logging into an existing account in production. - **Expanding Scope**: Attackers are encouraged to fingerprint backends and test signed session cookies or framework tokens in Django, Flask, and Express using tools like `Cookie Monster` by Ian Carroll to brute-force predictable keys.

### Takeaways - **Enforce and Validate Algorithms**: Servers must strictly validate and lock down expected signing algorithms rather than trusting values supplied in token headers. - **Isolate Environment Secrets**: Development and staging environments must never share signing keys, secrets, or configurations with production. - **Hacking with an Objective**: Security researchers should focus on maximizing impact—using reconnaissance on development assets to pivot, escalate privileges, access hidden functionality, and impact production targets.