Skip to main content

BAD JWT

 Have you ever seen a JWT token that reveals way more than it should?


In offensive security, we always inspect JWTs for:

  • Weak or guessable signing keys (e.g., "secret")

  • Use of none algorithm

  • Missing or improperly enforced exp claims

  • Sensitive data in payload (passwords, tokens)

JWTs are NOT encrypted by default. Don’t store secrets inside them before encrypting sensitive data.

You may not believe but this is extremely common in JWT tokens, especially by junior developers because they think tokens are safe and unreadable so they just put all relevant info inside, because this is an “EASY WAY” of coding...

  • Password inside JWT?!

    • Never store passwords (even hashed) in a JWT payload. JWTs are just base64-encoded—not encrypted! We can break hashed passwords too. We can also break some encryption algorithms like MD5, so you should choose a good algorithm for encryption.

  • Credit Card Info in Payload?

    • Huge PCI-DSS violation and security risk. This data could be exposed in logs, browser storage, or intercepted.

  • Long expiration (exp)

    • A token that lives forever is a token that can be stolen and reused forever.

  • Weak Signature Key

    • A predictable or short secret (use a better signing key) can be brute-forced, allowing attackers to forge tokens.

Here’s a nice website you can use to decode JWT tokens: https://jwtauditor.com/

Labels:

Comments

Post a Comment

Popular posts from this blog

Beyond the Pentest: Why We Do What We Do

  “We had a two-week pentest. They gave us a 40-page report. We fixed the high-severity issues. Are we secure now?” This is a line I’ve heard far too many times from CISOs and security leads and I always give them the same answer: No, you’re not secure. Not even close. I’m a penetration tester, but not the kind you’re used to. Let me explain. The Old Red vs Blue Paradigm Is Dead We’re no longer living in a world where attackers show up, hit your network hard for a few days, and disappear. Real adversaries stay there and observe you for months. Even for Years . They don’t follow rules of engagement. They evolve. They study you. And they compromise you slowly. The traditional red team-blue team separation, and the "2-week pentest, fix top 5 CVEs" checklist approach? It’s outdated. It gives a false sense of security . We don’t play by those rules at Gl1tch | Risk. Offensive Security as a Service – A Different Approach In our practice, we go beyond traditional penetration testing...
Post a Comment
Read more

Entering Password Protected Windows Computer without the Password

 If you have a windows laptop and you don’t know the password for some reason (!) (Maybe it’s not yours ?) and want to login without entering the password, here’s a simple way to hack it without being too technical. You just need to bypass the password protection. I didn’t try this method on other windows versions, you can give it a try but for windows 10 and windows 11 it works perfectly fine. (You need an empty physical pen drive to bypass) Step 1: Download Hiren Boot ISO file: https://www.hirensbootcd.org/ Step 2: Mount the iso file to your USB (You will lose all of the data) You can use RUFUS to do this. I will skip this step. Step 3: Start the windows computer you want to bypass the password, and open the BIOS menu. Depends on the manufacturer the BIOS menu can be opened with F12, ESC or Delete buttons from the keyboard during system boot. Step 4: Select the USB from BIOS menu to boot. Step 5: It will open live os, similar to a windows environment but it’s not… We will use ...
Post a Comment
Read more

Stop the Scammers. Detection of Homoglyph Attack Attempt using KQL (Kusto Query Language)!

  Phishing attempts are getting sneakier, often leveraging homoglyph attacks or unusual characters to trick employees. I put together a simple but effective query to scan for new users created with "weird" characters in the email domain that indicates a potential sign of a spoofed or malicious account creation attempt. KQL Breakdown: This query scans 7 days of CloudAppEvents for the `Create user.` action, then checks the new user's email domain for any non-ASCII characters (characters outside the standard English keyboard set: $\text{U+0000}$ to $\text{U+007F}$) . This is a great starting point for spotting internationalized domain name (IDN) abuse or other sophisticated L3 attacks. CloudAppEvents | where TimeGenerated > ago(7d) | where ActionType == "Create user." | extend Email = tostring(parse_json(RawEventData).EmailAddress) | extend Domain = tostring(split(Email,"@")[1]) | where Domain matches regex @"[^\u0000-\u007F]" | project Ti...
Post a Comment
Read more