Series · 3 partsWhen Access Checks FailPart 2 · You are here
  1. 1CI/CD ve OIDC Güven Sınırı: GitHub Actions'tan Buluta Yetki Geçişi
  2. 2İmza Geçerli. Token Hâlâ Başka Bir Yere Ait: JWT Doğrulama SınırıYou are here
  3. 3İstek Sunucu Tarafında Kaldı. Kimlik Bilgisi Kalmadı: SSRF ve Cloud Metadata

60 saniyede JWT doğrulaması

“JWT imzası geçerlidir” cümlesi ilk bakışta nihai bir güvenlik kararı gibi duyulur. Oysa yalnızca kriptografik bir gözlemdir.

Bu ifade; belirli bir anahtarın, belirli bir algoritma altında bu baytları doğruladığını söyler. Ancak anahtarın gerçekten beklenen sağlayıcıya (issuer) ait olduğunu, sağlayıcının bu token’ı bu API için ürettiğini, token’ın doğru yetki türünde olduğunu veya içindeki claim’lerin talep edilen işlemi onayladığını henüz söylemez. Bunlar birbirinden bağımsız kontrollerle uygulanan ayrı bağlamlardır; bir token ilk adımı başarıyla geçerken tamamen başka bir yere ait olabilir.

JWT ile ilgili sızma testi bulgularının büyük bölümü kırılmış kriptografiden kaynaklanmaz. Doğru çalışan bir kriptografinin yanlış bir güven kararına bağlanmasından kaynaklanır.

Doğrulama bir bağlamlar zinciridir

Doğru zihinsel model “token’ı doğrula” demek değildir. Sırasıyla şu beş soruyu sormaktır:

  1. Algoritma → Anahtar: Bu token sınıfı için tam olarak bu algoritmaya izin veriliyor mu ve bu anahtarın bu algoritmayla kullanılmasına yetki var mı?
  2. Anahtar → Sağlayıcı (Issuer): Anahtar, güvenilmeyen token başlığının gösterdiği rastgele bir konumdan mı alındı, yoksa yapılandırılmış güvenilir bir JWKS kaynağından mı geldi?
  3. Sağlayıcı → Süje (Subject): Bu sağlayıcının bu uygulamada bu kullanıcı adına konuşmasına izin var mı?
  4. Token → Hedef Kitle (Audience): Token gerçekten bu API veya servis için mi üretildi?
  5. Token Türü → Doğrulayıcı: Bir access token kurallarıyla mı ele alınıyor, yoksa bir ID token kurallarıyla mı?

RFC 8725 bu maddeleri haklı bir nedenle birbirinden ayrı gereksinimler olarak tanımlar. Bir kütüphane imzayı mükemmel bir şekilde doğrularken, uygulamanın kendisi yanlış algoritmayı kabul edebilir, yanlış anahtarı çekebilir, audience doğrulamasını atlayabilir veya her JWT için tek bir genel geçer doğrulama profili kullanabilir.

GEÇERLİ BİR İMZA YALNIZCA DAHA GENİŞ BİR DOĞRULAMA HATTININ TEK BİR KAPISIDIR algoritma allowlist başlık yönetemez anahtar İMZA issuer mülkiyeti issuer iss + sub kimlik kapsamı audience BU APİ alıcı servis tür (typ) access profil
Kriptografik geçerlilik zorunludur ancak kasten yetersizdir. Alıcı servis claim'lere güvenmeden önce algoritmayı, anahtarı, issuer'ı, audience'ı ve token türünü yapılandırılmış tek bir doğrulama profiline bağlamak zorundadır.

Header bir girdidir, güvenlik politikası değil

JWT başlığı (header) dışarıdan, güvenilmeyen istemciden gelir. alg, kid, jku ve x5u gibi alanlar doğrulayıcının anahtarı bulmasına yardımcı olabilir; ancak doğrulayıcının güvenlik politikasını tek başlarına dikte etmelerine asla izin verilmemelidir.

alg parametresi mutlaka sunucu tarafında tanımlı bir beyaz liste (allowlist) ile kontrol edilmelidir. Uygulama token’a “hangi algoritmayı kullanmak istersin?” diye sorup ardından cevaba uyum sağlamamalıdır.

Evidence matrix

SinyalNeyi kanıtlarNegatif kontrolSavunmacı doğrulaması
Farklı bir client için üretilmiş token’ın kabul edilmesiAudience (aud) doğrulamasının eksik olduğunuAynı issuer’dan farklı aud içeren bir token gönderip 401 Unauthorized bekleyinAPI gateway seviyesinde hedef kitle zorunluluğunu test edin
alg: none veya simetrik/asimetrik karışıklığı (HMAC)Algoritmanın allowlist ile kısıtlanmadığınıAsimetrik açık anahtarla HMAC-SHA256 imzalanmış token gönderinYalnızca izin verilen algoritma setini kabul eden doğrulama kütüphanesi yapılandırın
Header’daki jku veya jwk URL’sine istek yapılmasıKey injection ve SSRF zafiyeti riskiniHarici bir saldırgan sunucusunu jku alanına yazıp isteği izleyinAnahtar kümelerini (JWKS) yalnızca sabit, güvenilir issuer URL’lerinden statik olarak çekin

Savunmacılara teslim edilmesi gerekenler

Her API için audience zorunlu olmalıdır. Bir servis gelen token’da kendi aud değerini görmüyorsa token ne kadar geçerli olursa olsun doğrudan reddetmelidir.

Token türlerini birbirinden ayırın. ID token bir kimlik kartıdır; API isteklerinde access token yerine geçemez. Yetkilendirme filtreleri typ: at+jwt veya açık rol claim’lerini doğrulamalıdır.

İmza güvenliğin ilk adımıdır; son adımı asla değildir.

Kaynaklar ve güncellik

Bu teknik not ne kadar güncel?

Kontrol edilen kaynaklar23 Ekim 2025

En son kaynak incelemesi, içerik güncellemesi veya yayın tarihi gösterilmektedir.

İnceleme DurumuYazar incelemesi tamamlandı

Yazar teknik incelemeyi tamamladı. Bu etiket tek başına laboratuvar yeniden üretimi iddiası taşımaz.

Birincil referanslar