json web imza kodu çözme: Bir Güvenlik Mühendisinin Sahiplenilmeme Rehberi

Modern erişim kontrolü, JSON tabanlı belirteçlerin üzerinde yaşar ve ölür. Bir OAuth erişim belirtecini, bir OpenID Connect ID belirtecini veya imzalanmış bir API oturumunu incelediğinizde, genellikle bir JSON Web İmzası (JWS) yapı. Arama motorları pek çok kişiyi opak dizeleri sihirli bir şekilde okunabilir JSON'a dönüştüren "json web signature decode" araçlarına yönlendirecektir.

Saldırgan ve savunmacı güvenlik mühendisleri için bu sadece ilk adımdır. Bir JWS'nin kodunu çözmek size belirtecin ne olduğunu söyler iddialarBu iddiaların güvenilir olup olmadığını, imzanın doğru bir şekilde uygulanıp uygulanmadığını ya da uygulamanın CVE veritabanında yer alıp almadığını söylemez.

Bu makalede, json web imzasının kodunu çözdüğünüzde gerçekte ne olduğu, gerçek dünyadaki güvenlik açıklarının JWS doğrulamasıyla ilgili ince hatalardan nasıl ortaya çıktığı ve otomatik, yapay zeka ile güçlendirilmiş bir pentest işlem hattına uyan tekrarlanabilir bir iş akışının nasıl oluşturulacağı anlatılmaktadır.

JSON Web İmzası gerçekte nedir

JWS spesifikasyonuna göre, bir JSON Web İmzası, JSON tabanlı yapılar kullanarak dijital imza veya MAC ile korunan rastgele içeriği temsil eder. Bir bayt dizisi için, bu baytların neyi temsil ettiğinden bağımsız olarak bütünlük ve özgünlük sağlar. (IETF Datatracker)

Pratikte, çoğu zaman bu bayt dizisi bir JSON nesnesidir. iddialar - JSON Web Token (JWT) olarak adlandırdığımız şeydir. JWS'nin kendisi [RFC 7515]'te tanımlanırken, JWT bu taleplerin nasıl yapılandırıldığı ve yorumlandığına odaklanan bir kardeş standartta yer almaktadır. (Orta)

Bilinen kompakt form şu şekildedir:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0Iiwic2NvcGUiOlsicmVhZCIsIndyaXRlIl0sImV4cCI6MTczNDkxMjAwMH0.
ODU5Y...imza-bayt-burada...

Kavramsal olarak, noktalarla birleştirilen Base64URL kodlu üç parçadan oluşur:

İster çevrimiçi bir araç tarafından ister kendi komut dosyalarınızda gerçekleştirilsin, bir json web imzası kod çözme işlemi yalnızca ilk iki bölümün Base64URL kodlamasını tersine çevirir ve JSON'u güzel bir şekilde yazdırır. Bunu yapar değil Araç, bilinen bir anahtar ve kısıtlı bir algoritma seti ile açıkça doğrulama yapmadığı sürece imzanın geçerli olduğunu kanıtlar. (developer.pingidentity.com)

Json web imzası çözme araçları gerçekte nasıl çalışır?

Çoğu JWT / JWS kod çözücü - tarayıcılarda veya web tabanlı oyun alanlarında kullanılan yaygın geliştirici araçları gibi - aynı minimum işlem hattını uygular:

1. Noktaları üç bölüme ayırın.
2. İlk iki segmentin Base64URL kodunu çözün.
3. Başlık ve yük için bunları JSON olarak ayrıştırın.
4. Bir doğrulama anahtarı sağlanmışsa, başlıkta bildirilen algoritmayı kullanarak imzayı yeniden hesaplayın ve üçüncü segmentle karşılaştırın. (developer.pingidentity.com)

Bir güvenlik mühendisinin bakış açısına göre, 1-3. adımlar çevrimdışı analiz için yeterince güvenlidir; 4. adım ise çoğu güvenlik açığının saklandığı yerdir.

Minimal Python kod çözme snippet'i

İşte Python'da kasıtlı olarak basit bir kod çözme parçacığı, bir pentest sırasında yakalanan belirteçleri ararken kullanışlıdır:

base64 içe aktar
import json

def b64url_decode(data: str) -> bytes:
    # JWT dolgu işleme
    dolgu = '=' * (-len(veri) % 4)
    return base64.urlsafe_b64decode(data + padding)

def decode_jws(token: str):
    header_b64, payload_b64, signature_b64 = token.split('.')
    header = json.loads(b64url_decode(header_b64))
    payload = json.loads(b64url_decode(payload_b64))
    return header, payload, signature_b64

jws = "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...."
h, p, sig = decode_jws(jws)
print("Başlık:", h)
print("Yük:", p)

Bu fonksiyonun asla bir doğrulama rutini çağırır; sadece kod çözer. Bu, genellikle yeni bir hedefi değerlendirirken tam olarak istediğiniz şeydir: sıfır kriptografik varsayımla hızlı inceleme.

Doğrulama ile Node.js snippet

Kod çözmenin ötesine geçip doğrulamaya geçtiğinizde, her ayrıntı önemlidir:

import jwt from "jsonwebtoken";
import fs from "fs";

const publicKey = fs.readFileSync("public.pem", "utf-8");

function verifyJws(token) {
  // Kritik: desteklenen algoritmaları açıkça kilitleyin
  return jwt.verify(token, publicKey, {
    algoritmalar: ["RS256"],
  });
}

Eğer atlarsanız algoritmalar beyaz listeye alıp kütüphanenin güvenilmeyen başlıktan algoritmayı çıkarmasına izin verirseniz, tam olarak birden fazla JWT CVE'sine yol açan koşulları tekrarlamış olursunuz.

Kod çözme zararsızdır, kod çözülmüş veriye güvenmek

Olay raporlarında ve CVE'lerde bir model tekrar tekrar ortaya çıkıyor: geliştiriciler deşifre edildi JWT / JWS verileri halihazırda olduğu gibi doğrulandı. JWT güvenlik sorunlarına ilişkin çok sayıda modern yazı, Base64URL kod çözmenin önemsiz olduğunu ve bir belirtecin gizliliğinin "okunmasının zor olmasından" kaynaklanmadığını vurgulamaktadır. (PortSwigger)

Yinelenen üç böcek sınıfı öne çıkmaktadır:

1. "alg" alanı bir doğruluk kaynağı olarak ele alınır. Doğrulama kodunuz kullanılacak algoritmayı kullanıcı kontrolünde olan başlıktan alırsa, algoritma karışıklığı saldırılarına davetiye çıkarmış olursunuz.
2. Bu Hiçbiri algoritması yanlışlıkla kabul edilir. JWT standardı tarihsel olarak aşağıdakiler için destek gerektiriyordu "yok" "bütünlük koruması yok" anlamına gelen bir algoritma olarak. Auth0'ın klasik analizi, birkaç kütüphanenin bu seçimi nasıl safça onurlandırdığını ve imzasız belirteçlerin kontrolleri geçmesine izin verdiğini gösterdi. (Auth0)
3. Anahtar ipuçları (Çocuk, gömülü jwk, x5u) onaylanmamıştır. Hem JWS RFC hem de test kılavuzları, sıkı bir beyaz liste olmadan belirtecin kendi doğrulama anahtarını seçmesine izin vermenin, saldırganların keyfi genel anahtarları kaçırmasına veya saldırganların kontrolündeki konumlarda anahtar aramalarını zorlamasına izin verdiğini vurgulamaktadır. (PortSwigger)

Başka bir deyişle, json web imzası deşifresi size gözlemlenebilirlik sağlar. Size güven vermez. Bu ayrım, güvenli bir hata ayıklama kurulumunu uzaktan kod çalıştırma başlığından ayıran şeydir.

Kod çözme CVE'lerle buluştuğunda: somut JWS hata modları

Kod çözme ve doğrulama birbirine karıştırıldığında işlerin ne kadar kötü gidebileceğini anlamak için JWS doğrulama mantığı etrafında dönen birkaç CVE'ye bakmaya değer.

CVE-2015-9235 - HS/RS anahtar karışıklığı jsonwebtoken

Node.js'de jsonwebtoken modülünün 4.2.2 sürümünden önceki bir tasarım hatası, asimetrik bir algoritmadan (RS256 / ES256 aileleri) simetrik bir algoritmaya (HS256) geçerek imza doğrulamasını atlamayı mümkün kılıyordu. Savunmasız kod yolu, saldırgan HMAC sırrını değiştirdiğinde aynı değeri (RSA ortak anahtarı) HMAC sırrı olarak yeniden kullanmıştır. alg HS256'ya başlık. (nvd.nist.gov)

Saldırganın bakış açısına göre iş akışı basittir:

1. Orijinal belirtecin kodunu çözün ve başlığı inceleyin.
2. Sunucunun ortak anahtarını çıkarın (örneğin, bir JWK uç noktasından veya sertifikadan).
3. HMAC sırrı olarak ortak anahtarı kullanarak HS256 başlığıyla yeni bir belirteç oluşturun.
4. Sahte belirteci sunun; sunucu bunu yanlışlıkla geçerli olarak kabul eder.

Burada, kod çözme saldırgana hammaddeyi (başlık, algoritma, anahtar konumları) verir; doğrulama mantığı gerisini halleder.

CVE-2018-1000531 - kabul etmek Hiçbiri algoritma

Bu güvenlik açığı, kitaplıkların şu şekilde imzalanmış belirteçleri kabul ettiği durumları izledi Hiçbiri algoritmasını kullanarak, herhangi bir imza olmamasına rağmen bunları geçerli olarak değerlendirir. İstismar modeli neredeyse komik derecede basittir: değiştir "alg": "RS256" için "alg": "yok", imza kısmını kaldırın ve hedef API'nin belirteci kabul edip etmediğine bakın. (0xn3va.gitbook.io)

CVE-2023-48238 - algoritma karışıklığı json-web-token

Bu json-web-token kütüphanesinin başka bir algoritma karışıklığı saldırısına karşı savunmasız olduğu tespit edildi. Temel sorun: doğrulama için kullanılan algoritma doğrudan o noktada güvenilmeyen token başlığından alınıyordu. Bu, saldırganların sunucu operatörünün uyguladığını düşündüğü algoritmadan daha uygun bir algoritma seçmesine olanak sağladı. (nvd.nist.gov)

CVE-2024-54150 - C JWT uygulamasında karışıklık

Daha yakın bir zamanda cjwt C kütüphanesi, şimdi CVE-2024-54150 olarak izlenen kritik bir algoritma karışıklığı kusuruna maruz kaldı. Kod incelemesi, uygulamanın belirteçleri doğrularken HMAC tabanlı algoritmaları RSA / EC olanlardan düzgün bir şekilde ayırt etmediğini ve yine anahtar karışıklığına kapı açtığını ortaya çıkardı. (nvd.nist.gov)

Bu vakalar tarihsel merak değildir; 2023-2024 yıllarında bile JWS'nin doğrulama yolundaki ince hataların ciddi güvenlik açıklarının aktif bir kaynağı olmaya devam ettiğini göstermektedir.

Birçok ekip, bir değerlendirme sırasında onları düzenli tutmak için aşağıdaki gibi bir kopya kağıdı oluşturur:

Bir json web imzası çözme alıştırması sırasında, gözlemlenen belirteçleri bu tabloyla açıkça eşleştirmek, hangi oyun kitaplarını denemeniz gerektiğini belirlemenin hızlı bir yoludur.

Penterler için pratik bir kod çözme öncelikli iş akışı

JWS'ye dayanan bir API veya SSO sistemini değerlendirirken, disiplinli bir kod çözme öncelikli iş akışı hem kör noktaları hem de gürültülü tahminleri önler.

1. Belirteçleri yakalayın ve kataloglayın. Tüm belirteçleri yakalamak için proxy'nizi veya test koşum takımınızı kullanın: Yetkilendirme üstbilgileri, çerezler, URL parametreleri. Veren ve hedef kitleye göre gruplandırın.
2. Başlık ve yükü çevrimdışı olarak çözün. Yukarıdaki Python parçacığı gibi komut dosyaları kullanın veya jwt_tool yalnızca deşifre etmek için; gerçek etkileşimlerde hassas belirteçler için asla çevrimiçi bir hizmete güvenmeyin. (GitHub)
3. Bir başlık matrisi oluşturun. Her bir belirteç ailesi için şunları kaydedin alg, Çocuk, varlığı jku / jwk / x5uve tüm özel başlık alanları. PortSwigger'ın gömülü JWK'ler ve saldırgan tarafından sağlanan anahtarlar hakkındaki rehberliği bu noktada doğrudan uygulanabilir hale gelmektedir. (PortSwigger)
4. Anahtar yönetim modellerini çıkarır. Başlık alanlarına ve iyi bilinen uç noktalara (/.well-known/jwks.json), anahtarların nasıl dağıtıldığını ve döndürüldüğünü çizin.
5. Bilinen hata sınıfları için test edin.
   • Boş-imzayı deneyin / Hiçbiri kütüphane veya yığın geçmişte bunları desteklediyse varyantlar.
   • Algs'in kilitli olmadığı yerlerde HS/RS anahtar karışıklığı denemeleri gerçekleştirin.
   • Sonda Çocuk dizin geçişi veya dosya ekleme davranışı için işleme.
   • Spesifikasyonun izin verdiği ancak uygulamanın kısıtlamayabileceği durumlarda gömülü JWK enjeksiyonunu deneyin.
6. Ardından, ancak o zaman, tam sömürü girişimlerine geçin. Bu aşamada, kara kutuya yük atmak yerine tam olarak neyi kanıtlamaya çalıştığınızı bilmeniz gerekir.

Bu süreçte, json web imzası deşifresi, saldırı metodolojinizin geri kalanı için gözlemlenebilirlik katmanıdır.

Json web imzası kod çözme işlemini yapay zeka odaklı bir pentest işlem hattına entegre etme (Penligent.ai)

Manuel analiz tek bir etkileşim için işe yarar; ölçekte, ekiplerin bir boru hattına daha yakın bir şeye ihtiyacı vardır. Yapay zeka destekli bir platform Penligent.ai json web imza çözümünü doğrudan keşif ve sömürü aşamalarına katabilir.

Tipik bir kurulumda, platform HTTP trafiğini bir tarayıcı sanal alanından veya bir proxy'den alır, aday belirteçleri otomatik olarak çıkarır ve üstbilgiler ve yükler üzerinde toplu JWS kod çözme işlemi gerçekleştirir. Yapay zeka ajanı daha sonra token'ları veren kuruluşa, algoritmaya ve anahtar ipuçlarına göre kümeler ve beklenmedik algoritma çeşitliliği, garip Çocuk kodlamalar veya olağandışı talep kombinasyonları.

Bu temel oluşturulduktan sonra, Penligent'in saldırı motoru otomatik olarak iyileştirilmiş JWT / JWS oyun kitaplarını çalıştırabilir: boş imza denemeleri, algoritma karışıklığı senaryoları, gömülü JWK veya jku kötüye kullanım ve CVE'den esinlenen bilinen problar. Bu kontrolleri bir insanın hafızasına bırakmak yerine, sistem bunları her hedef üzerinde çalışan tekrarlanabilir test durumları olarak ele alır ve sonuçları kanıt öncelikli bir risk listesine ve makine tarafından okunabilir bir rapora geri besler.

Dahili bir "AI kırmızı ekip" yeteneği oluşturan güvenlik mühendisleri için, json web imzası kod çözme işlemini böyle otomatik bir boru hattına bağlamak, genellikle düşük seviyeli tesisatın en yüksek kaldıraçlı parçalarından biridir.

Sertleştirme kontrol listesi ve daha fazla okuma

Eğer günlük işiniz JWS / JWT belirteçlerini yayınlamayı veya doğrulamayı içeriyorsa, bunu asgari bir çubuk olarak ele alabilirsiniz:

• İzin verilen algoritmaların sunucu tarafında katı bir listesini uygulayın; asla okumayın alg güvenilmeyen bir belirteçten politika olarak.
• Asimetrik imzalar ve HMAC gizli dizileri arasında anahtarları ayırın; bir RSA açık anahtarını asla HMAC anahtarı olarak yeniden kullanmayın.
• Kalıcı olarak devre dışı bırak Hiçbiri üretim kütüphanelerinde ve bunu tanıtan herhangi bir belirteci reddedin.
• Tüm başlık alanlarını (Çocuk, jku, jwk, x5u) güvenilmeyen girdi olarak kabul edin ve bunları sabitlenmiş bir anahtar kümesine veya beyaz listeye karşı doğrulayın.
• JWT kütüphanelerinizi yamalı tutun; yığınınızın etkilenip etkilenmediğini görmek için CVE-2015-9235, CVE-2018-1000531, CVE-2023-48238 ve CVE-2024-54150 gibi CVE'leri periyodik olarak inceleyin. (Swissky'nin Laboratuvarı)
• Yok/algoritma karışıklığı senaryolarını açıkça uygulayan regresyon testleri ekleyin.

Daha derin dalışlar için, bu İngilizce referanslar yer imlerine eklemeye ve dahili çalışma kitaplarınızdan bağlantı vermeye değer:

• IETF'den çekirdek [JSON Web Signature (JWS) RFC 7515]. (IETF Datatracker)
• OWASP'ın Web Güvenliği Test Kılavuzu'ndaki [JSON Web Belirteçlerinin Test Edilmesi] bölümü. (OWASP Vakfı)
• PortSwigger'ın [JWT saldırıları] ve [algoritma karışıklığı] üzerine Web Güvenlik Akademisi laboratuvarları. (PortSwigger)
• Tim McLean'in [JSON Web Token kütüphanelerindeki kritik güvenlik açıkları] hakkındaki klasik Auth0 yazısı. (Auth0)
• IETF OAuth çalışma grubunda gelişmekte olan [JWT En İyi Güncel Uygulamalar] taslağı. (IETF)

Doğru kullanıldığında, json web imzası çözümlemesi yalnızca bir hata ayıklama kolaylığı değildir; uygulamalarınızın kimlik doğrulama yapısını anlamanın, saldırmanın ve güçlendirmenin sistematik bir yolunun ön kapısıdır.