This Tiny JWT Mistake = Massive Bug Bounty

0:00 If you've ever been curious about how hackers actually bypass authentication in modern web apps, this video is for you. We're going hands-on with JWTs or JSON web tokens, and I'll show you real techniques that attackers use to forge, tamper, and even replay these tokens. This isn't just theory. We're going from zero to a real world exploitation. Plus, I'll walk you through a real example where I was able to access a production site just by exploiting a dev environment. First, we need to start with the basics. A JWT consists of three B 64 encoded parts, a header, a payload, and a signature, all separated by a dot. I'm using a simple script JWD signature to show you how typical tokens are signed. In this example, it's using HS 256, which relies on a secret key to sign the token. This is what the backend

0:45 uses to verify your identity. If the token is valid and the signature checks out, you're in. Now, real quick, JWTs can be signed in two main ways. HS 256 uses a single shared secret kind of like a password and it relies on HMAC which stands for hashbased message authentication code which is basically a way to make sure the data hasn't been tampered with. RS 256 on the other hand uses a private key to sign and a public key to verify. This bit of detail becomes really important later when we get into forging tokens. So bear with me. Now let's say you have a token. One attack here is to tamper with the algorithm. If the app doesn't validate the algorithm, you can set the algorithm to none, remove the signature, and send any payload that you want, and it tricks the server into accepting the token without verifying its signature. This

1:32 one isn't as common anymore, but it still pops up in legacy systems and poorly configured libraries. So, keep that in mind. This may work, but it's not going to be really valid for bug bounties, especially in today's world. A more realistic attack is cracking the secret key used in the HS 256 tokens. Developers love using weak secrets like secret 1, gwt123, password, or even default values. You can use a word list like rocku.txt that contains common passwords or just scrape something like GitHub for default secrets to try and crack it. Once you have cracked a key, you can modify the payload like changing your user ID, maybe changing the role, resigning the token, and then sending it over to our target application. So to make this attack work, we depend on knowing the key. But now we're going to talk about

2:18 something a little bit more advanced. Algorithm confusion. In RS 256, the server signs a token with a private key and verifies them with a public key. This is more secure because the private key is never exposed. But in some misconfigured apps, you can change the algorithm in the header to HS 256. Now, here's the issue. HS 256 uses a shared secret for both signing and verification. If the server blindly accepts HS256 and uses the RS 256 public key as the HMAC secret which is sometimes exposed by the web app. So you can kind of fuzz for it with fuff and maybe look within the well-known folder and find the file. But then if you have this it allows you to forge the token. So all you have to do is just grab that public key, switch the token header to H256 and sign your forge token using

3:05 that key. The app will then think this is valid because it uses the same key to verify it even though you sign it yourself. This happens a lot of times when the server trusts the algorithm Heather without enforcing expected values. This is why validating the algorithm on the server side and locking it down is absolutely critical. Now that we understand all the basics attacks that come with JWTs and we understand how they created and the different algorithms, let me walk you through something that I found that I was not expecting at all. I came across a dev site for a real web application. Let's just call it something like app-dev.site.com. Nothing fancy, just a login form. So, I signed up with my own email address, logged in, and grabbed the JWT token from my request. Then I thought to myself, what if I can actually use this token to log into the production side?

3:51 Keep in mind that the production side was an invite only. And somehow for the dev side, they allowed anybody to sign up without a code. So, this is really important because we don't have access on the prod side, but somehow we can get dev and it gives us a valid token. As my curiosity peaks, I switched over to the production side, reused the JWT token, and it worked. Except I was just logged in as another user. Same signature, same payload structure. It logged me into the production environment with my dev credentials. And that is because the dev and the production sites shared the same exact signing key. A critical mistake that allowed tokens to cross environments. So, not only I was able to bypass authentication on it, it also gave me an account takeover of some sort. This is why a bit of recon to find a dev or staging environment and testing

4:36 them is so important. Even if the production site looks solid, an insecure dev build can give you everything you need. Tokens, secrets, or even access paths that weren't meant to be exposed. This one is one of the most common attacks, especially when teams share keys to save time. And while token reuse is one of the big wins, it's not the only angle. If you get access to the dev site, start thinking bigger. What else can you do with this? Can you go from a user to admin? Can you find a vulnerability that might exist in both the div and production site? Is there hidden functionality in the div that is still accessible within the production systems? Always aim to maximize your impact like accessing sensitive data or features that are not available to you at all times. That's where the big security findings and the bounties are.

5:22 And while JWTs are one of the most common token formats out there, they're not the only ones that can be cracked or abused. You also have frameworks like Django, Flask, and even Express that use signed cookies or tokens that rely on predictable secrets in common algorithms. You can use tools like Cookie Monster by Ian Carroll to brute force for these secrets in the same way that we crack a weak JWT. So, when you're testing an app, don't stop at JWTs. Take the time to fingerprint the backend and see what signing methods is being used. you might find that a signed session cookie or framework specific token is just as vulnerable. This is why I always recommend hacking with an objective. Your goal isn't to just find bugs. It's to see how far you can go. So, if you can elevate your privilege or

6:08 find sensitive functionality in the dev side, the next question should be, how can I leverage this to impact the production system? Always think in terms of impact, that's where you're going to maximize your bounty and make the most out of your findings. All right, that's it for this video. Do me a favor. If you like content like this when we go from the basics all the way to a real world example, drop me a comment. Let me know what you think. I would love to make more content like this, but I also need to hear from you. So, if you've liked this video, do me a favor, hit that like, do the commenting, and do all the subscribing. And I will see you all in next week's video. Peace. [Music]