Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 14

OAuth 2.0 ve OIDC Güvenlik Açıkları: State Parametresi ve Redirect URI Doğrulaması

Recommended resources

Merhaba, önceki dersimizde JWT implementasyonlarındaki incelikli zafiyetleri, özellikle algoritma manipülasyonu ve anahtar yönetimi hatalarını kod seviyesinde nasıl tespit edeceğimizi inceledik. Bir token'ın kendi içindeki güvenliğinin ne kadar kritik olduğunu gördük. Bu derste ise bir adım geri çekilip, bu token'ların dağıtıldığı ve kullanıldığı protokollerin, yani OAuth 2.0 ve OpenID Connect (OIDC) akışlarının kendisindeki mantık hatalarına odaklanacağız.

Bu dersin sonunda, OAuth 2.0 ve OIDC implementasyonlarındaki iki temel ve sıkça istismar edilen zafiyet sınıfını analiz edebileceksiniz: state parametresinin kötüye kullanımı yoluyla gerçekleştirilen CSRF saldırıları ve redirect_uri doğrulama eksikliklerinden kaynaklanan kod ve token sızdırma zafiyetleri. Bu beceriler, bir uygulamanın kimlik doğrulama akışının temel direklerini oluşturan ve genellikle otomatize araçların gözden kaçırdığı, ancak yıkıcı sonuçlar doğurabilen hataları bulmanızı sağlayacaktır.

OAuth 2.0 Akışının Kritik Dönemeçleri

Analizimize başlamadan önce, en yaygın kullanılan "Authorization Code" akışının temel adımlarını ve zafiyetlerin nerede pusuya yattığını hatırlayalım. Sizin gibi bu alanda tecrübeli bir uzman için bu akış tanıdık olacaktır, ancak zafiyetleri tartışacağımız iki kritik noktayı vurgulamak önemlidir:

  1. İlk Yönlendirme: Kullanıcı, istemci uygulama (Client Application) üzerinden "Login with X" butonuna tıkladığında, tarayıcısı Yetkilendirme Sunucusu'na (Authorization Server) yönlendirilir. Bu yönlendirme URL'i, client_id, scope, response_type ve bizim için kilit önem taşıyan redirect_uri ile state parametrelerini içerir.
  2. Son Yönlendirme: Kullanıcı, Yetkilendirme Sunucusu'nda kimliğini doğrulayıp izinleri onayladıktan sonra, tarayıcısı tekrar istemci uygulamanın redirect_uri'sine yönlendirilir. Bu yönlendirme, bir code (yetkilendirme kodu) ve orijinal state değerini içerir.

İşte tam bu iki yönlendirme arasındaki mantık zincirinde, saldırganların araya girerek akışı manipüle etme fırsatları doğar.

Web Security 0x1A | OAuth Zafiyetleri

Mehmet İnce'nin bu videosu, OAuth akışının arkasındaki temel mantığı ve HTTP yönlendirmelerinin bu süreçteki rolünü mükemmel bir şekilde görselleştiriyor. Konuya dalmadan önce bu akışın neden zafiyetlere açık olabileceğini anlamak için harika bir başlangıç.

Lütfen videonun başından OAuth'ın temel amacı ve aktörlerini anlatan bölümü ve ardından HTTP redirect mekanizmalarının akışın en zayıf halkası olabileceğini açıklayan kısmı izleyin. Bu, redirect_uri'nin neden bu kadar kritik olduğunu anlamanıza yardımcı olacaktır.

1. Yetersiz redirect_uri Doğrulaması: Kodu Yanlış Adrese Teslim Etmek

redirect_uri parametresi, Yetkilendirme Sunucusu'na, yetkilendirme kodunu (code) veya erişim belirtecini (access_token) nereye göndereceğini söyler. Eğer bu URI'nin doğrulaması zayıfsa, bir saldırgan bu parametreyi değiştirerek hassas bilgileri kendi kontrolündeki bir sunucuya yönlendirebilir.

Kod Analizinde Ne Aramalısınız?

Kod incelemesi sırasında, redirect_uri'nin nasıl doğrulandığına odaklanmalısınız. Temel ayrım "tam eşleşme" ve "desen eşleşme" arasındadır.

  • Zafiyetli Desen (Pattern Matching): startsWith(), endsWith(), contains() veya esnek Regex kontrolleri genellikle tehlikelidir. Örneğin, beyaz listedeki URI https://example.com/callback ise ve kontrol uri.startsWith("https://example.com") şeklindeyse, saldırgan https://example.com.attacker.com gibi bir alt alan adı kullanarak veya https://example.com/open-redirect?url=attacker.com gibi bir açık yönlendirme zafiyetini zincirleyerek kontrolü atlatabilir.

  • Güvenli Desen (Exact Match): Güvenli bir implementasyon, gelen redirect_uri'yi, istemci kaydedilirken beyaz listeye alınmış URI'lerin listesiyle birebir (byte-for-byte) karşılaştırmalıdır.

OAuth 2.0 Güvenliği – Ataklar ve Önlemler | Murat Kaya

Murat Kaya'nın bu makalesi, redirect_uri doğrulamasının teorik temelini ve pratikteki saldırı vektörlerini çok net bir dille açıklıyor.

Lütfen makaledeki ilk bölümü okuyarak redirect_uri eşleştirmesinin neden önemli olduğunu anlayın. Ardından, "Yetersiz URI Yönlendirme Kontrolleri Saldırıları" başlığını okuyarak desen tabanlı (regex benzeri) doğrulamaların nasıl istismar edilebileceğini öğrenin. Son olarak, "Önlemler" başlığı altında neden "Tam Eşleşen" URI kullanımının en güvenli yöntem olduğunu pekiştirin.

İleri Seviye redirect_uri Saldırıları

Basit bir URI manipülasyonunun ötesinde, bu zafiyet daha karmaşık saldırı zincirleri oluşturmak için kullanılabilir.

a) Kod Sızdırma (Authorization Code Leakage):
Bu en temel saldırıdır. Saldırgan, kurbanı, redirect_uri'si kendi sunucusuna ayarlanmış bir OAuth başlatma linkine tıklamaya ikna eder. Kurban, Yetkilendirme Sunucusu'nda oturum açtıktan sonra, yetkilendirme kodu saldırganın sunucusuna gönderilir ve saldırgan bu kodla kurbanın hesabını ele geçirir.

Aşağıdaki video, bu saldırının PortSwigger laboratuvarında nasıl gerçekleştirildiğini adım adım gösterir.

Web Security 0x1A | OAuth Zafiyetleri

Mehmet İnce, bu bölümde redirect_uri'yi değiştirerek yetkilendirme kodunun nasıl ele geçirileceğini canlı olarak gösteriyor.

Lütfen bu bölümü izleyin. Saldırganın redirect_uri'yi kendi sunucusuna yönlendirip, gelen isteğin loglarından code'u nasıl yakaladığını ve bu kodla kurbanın hesabına nasıl girdiğini göreceksiniz.

b) Token Sızdırmak için Proxy Sayfa Kullanımı:
Bazen redirect_uri'yi tamamen harici bir siteye yönlendiremezsiniz, ancak aynı alan adı içindeki başka bir yola (path) yönlendirebilirsiniz. Eğer o yolda postMessage gibi bir mekanizma zafiyetli bir şekilde kullanılıyorsa (targetOrigin olarak * belirtilmişse), bu durum token'ı çalmak için bir "proxy" olarak kullanılabilir.

Bu görüntü, başarılı bir token hırsızlığı saldırısının sonucunu göstermektedir. Saldırgan, kurbanın access token'ını ele geçirerek onun adına yönetici (administrator) hesabına erişim sağlamıştır.

Bu ileri seviye tekniği aşağıdaki kaynakta detaylı olarak inceleyebilirsiniz.

İleri Seviye OAuth Authentication Zafiyetleri ve Uygulamaları

Sefa Yıldırım'ın bu yazısı, redirect_uri zafiyetinin path traversal ve zafiyetli bir postMessage implementasyonu ile birleştirilerek access token'ın nasıl çalındığını gösteren bir laboratuvar çözümünü anlatıyor.

Lütfen yazının başındaki "Lab: Stealing OAuth access tokens via a proxy page" bölümünü dikkatlice okuyun. Saldırganın redirect_uri'yi ../../post/comment/comment-form gibi bir yola yönlendirerek, bu sayfanın window.location.href'i postMessage ile herhangi bir origine göndermesinden nasıl faydalandığını analiz edin.

c) OIDC ile Gelen SSRF Vektörleri:
OpenID Connect, OAuth'u genişleterek dinamik istemci kaydı gibi yeni özellikler ekler. Bu özellikler, URI tabanlı yeni parametreler (logo_uri, jwks_uri, request_uri vb.) getirir. Eğer Yetkilendirme Sunucusu, bu URI'lara arka planda istek yapıyorsa ve bu URI'lar saldırgan tarafından kontrol edilebiliyorsa, bu durum Sunucu Tarafı İstek Sahteciliği (SSRF) zafiyetine yol açabilir.

Bu görsel, bir OIDC dinamik istemci kayıt isteğini ve ardından gelen yetkilendirme ekranını göstermektedir. `logo_uri` gibi parametrelerin, sunucunun arka planda bir istek yapmasına neden olarak SSRF zafiyetlerine yol açabileceğini ima eder.

İleri Seviye OAuth Authentication Zafiyetleri ve Uygulamaları

Bu kaynak, OIDC'nin dinamik client kaydı özelliğinin SSRF'e nasıl yol açabileceğini pratik bir laboratuvar üzerinden gösteriyor.

Lütfen "Unprotected dynamic client registration" bölümünü ve ardından gelen "Lab: SSRF via OpenID dynamic client registration" çözümünü okuyun. Saldırganın, kimlik doğrulaması gerektirmeyen bir kayıt endpoint'ine logo_uri olarak iç ağdaki bir meta-veri adresini vererek SSRF'i nasıl tetiklediğine dikkat edin.

2. state Parametresi Kötüye Kullanımı: OAuth'ta CSRF

state parametresi, OAuth akışındaki temel CSRF koruma mekanizmasıdır. Amacı, kullanıcının başlattığı oturum ile Yetkilendirme Sunucusu'ndan dönen cevabı birbirine bağlamaktır.

Güvenli Akış:

  1. İstemci, akış başladığında kriptografik olarak güvenli, tahmin edilemez bir state değeri üretir.
  2. Bu değeri kullanıcının oturumunda (session) saklar.
  3. Kullanıcıyı Yetkilendirme Sunucusu'na yönlendirirken bu state değerini URL'e ekler.
  4. Yetkilendirme Sunucusu, kullanıcıyı geri yönlendirirken aynı state değerini parametre olarak ekler.
  5. İstemci, yönlendirme isteği geldiğinde, parametredeki state değeri ile oturumda sakladığı değeri karşılaştırır. Eşleşmezlerse, isteği reddeder.

Zafiyet Nerede?
Eğer istemci uygulama bu state değerini hiç kullanmazsa, kullanır ama doğrulamazsa veya tahmin edilebilir bir değer kullanırsa, akış CSRF saldırılarına açık hale gelir. Bu durum genellikle "sosyal medya hesabını bağla" gibi özelliklerde hesap devralmaya (account takeover) yol açar.

Web Security 0x1A | OAuth Zafiyetleri

Bu video, state parametresinin eksikliğinden kaynaklanan bir CSRF zafiyetinin, kurbanın hesabına saldırganın sosyal medya hesabını bağlayarak nasıl hesap devralmaya yol açtığını uygulamalı olarak anlatıyor.

Videodaki ikinci laboratuvar çözümünü dikkatle izleyin. Mehmet İnce, saldırı adımlarını şu şekilde özetliyor: Saldırgan kendi hesabıyla oturum açar ve sosyal medya bağlama akışını başlatır. Yetkilendirme sunucusuna yönlendiren son URL'i (/callback içeren) yakalar. Bu URL, state içermediği için (veya doğrulanmadığı için) zafiyetlidir. Bu URL'i kurbana bir oltalama saldırısıyla gönderir. Kurban linke tıkladığında, kendi oturumu aktif olduğu için, saldırganın sosyal medya hesabı kurbanın uygulamadaki hesabına bağlanır. Saldırgan artık "Login with Social Media" diyerek kurbanın hesabına erişebilir. Bu bölüm saldırının mantığını bir şema üzerinde tekrar özetleyerek konuyu pekiştiriyor.

Sonuç ve Kod Analizi Kontrol Listesi

OAuth ve OIDC gibi delege edilmiş kimlik doğrulama akışları, modern uygulamaların temel taşlarıdır, ancak güvenlikleri, implementasyonun her adımındaki detaylara sıkı sıkıya bağlıdır. Kod analizi yaparken, bu akışlardaki mantıksal boşlukları aramak, sizin gibi deneyimli bir göz için en verimli av sahalarından biridir.

İşte OAuth/OIDC implementasyonlarını incelerken kullanabileceğiniz bir kontrol listesi:

  1. redirect_uri Doğrulaması:
    • Doğrulama, beyaz listedeki URI'larla tam (birebir) eşleşme mi yapıyor, yoksa esnek desenlere (örn: startsWith) mi izin veriyor?
    • Desenlere izin veriliyorsa, alt alan adı, path traversal veya açık yönlendirme zafiyetleriyle bu kontrol atlatılabilir mi?
  2. state Parametresi ile CSRF Koruması:
    • Authorization Code ve Implicit akışlarında state parametresi kullanılıyor mu?
    • Oluşturulan state değeri her oturum için benzersiz ve kriptografik olarak tahmin edilemez mi?
    • Geri arama (callback) endpoint'i, gelen state parametresini kullanıcının oturumunda saklanan değerle karşılaştırıyor ve eşleşme yoksa isteği reddediyor mu?
  3. OIDC'ye Özgü Vektörler:
    • Dinamik istemci kaydı (/registration) endpoint'i kimlik doğrulaması olmadan erişilebilir mi?
    • logo_uri, jwks_uri, request_uri gibi parametreler kullanıcı tarafından sağlanabiliyor mu? Eğer öyleyse, bu URI'lara sunucu tarafından yapılan istekler SSRF zafiyetine yol açabilir mi?

Önceki dersimizde token'ın kendisine, bu derste ise token'ın elde edildiği akışa odaklandık. Bir sonraki dersimizde, bu token'larla yönetilen oturumların dağıtık mimarilerde nasıl karmaşık sorunlara yol açabileceğini inceleyeceğiz. "Çapraz hizmet oturum karışıklığı (cross-service session confusion)" ve "token yenileme yarış koşulları (token renewal race conditions)" gibi, mikroservis ortamlarına özgü, tespiti zor ancak kritik zafiyetleri kodda nasıl bulacağımızı analiz edeceğiz.