Stronger_Cracker
- 25 Tem 2022
- 6,399 Mesaj
Selamunaleyküm,
Modern web uygulamalarının büyük bölümü kimlik doğrulama ve yetkilendirme süreçlerini dış servis sağlayıcılara devretmek için OAuth 2.0 ve OpenID Connect (OIDC) protokollerini kullanmaktadır. Google, Microsoft, GitHub gibi sağlayıcılarla yapılan “Login with X” entegrasyonlarının büyük kısmı bu standartlara dayanır.
Ancak bu protokoller doğru şekilde implement edilmediğinde kimlik ele geçirme, token çalınması ve yetkisiz erişim gibi kritik güvenlik açıklarına yol açabilir. Çoğu saldırı doğrudan protokol zafiyetinden değil, geliştiricilerin implementasyon hatalarından kaynaklanır.
Bu konumuzda OAuth 2.0 ve OpenID Connect implementasyonlarında en sık görülen teknik güvenlik hataları ve bu hataların nasıl sömürülebileceği detaylı olarak ele alacağız.
OpenID Connect ise OAuth 2.0 üzerine inşa edilmiş bir kimlik doğrulama katmanıdır.
Tipik Authorization Code Flow şu adımlardan oluşur:
Kullanıcı uygulama üzerinden login işlemini başlatır >> Uygulama kullanıcıyı Authorization Server'a yönlendirir >> Kullanıcı kimlik doğrulaması yapar >> Authorization Server uygulamaya bir authorization code gönderir >> Uygulama bu code'u kullanarak access token ve ID token alır >> Access token ile API çağrıları yapılır
UYARI Yapılan yanlış implementasyon güvenlik riski oluşturabilir.
Eğer redirect URI doğrulaması hatalı yapılırsa saldırgan authorization code interception gerçekleştirebilir.
Örnek:
Sunucu şu kontrolü yapıyorsa:
Saldırgan şu URI'yi kullanabilir:
Authorization code saldırgana gider.
Örnek:
Authorization server şu URI'yi kabul ediyorsa:
Saldırı şu şekilde gerçekleşir:
Bu durumda ne olur?
Authorization code example.com'a gönderilir >> Open redirect tetiklenir >> Code attacker.com'a yönlendirilir
Bu teknik birçok bug bounty programında kritik zafiyet olarak rapor edildi.
Normalde:
Authorization server bu değeri geri döndürür:
Uygulama state değerini doğrular.
Kullanıcı saldırganın hesabına bağlı token ile login olur ve hesap bağlama saldırısı gerçekleşir
Bu saldırı türü Login CSRF olarak bilinir.
PKCE mekanizması şu adımlardan oluşur:
Authorization request:
Token request:
Server doğrular.
Kullanıcı public WiFi kullanıyor >> Saldırgan MITM pozisyonunda >> Authorization code yakalanır >> Saldırgan token endpoint'e gönderir >> Access token elde edilir
PKCE bu saldırıyı engeller çünkü saldırgan code_verifier değerini bilmez.
Bir ID token tipik olarak şu yapıdadır:
Payload içinde şu alanlar bulunur:
Saldırgan şu token'ı oluşturabilir:
Sunucu imza doğrulaması yapmaz.
Bu durum authentication bypass ile sonuçlanır.
Eğer doğrulanmazsa:
Saldırgan başka bir uygulama için token alır. Bu token hedef uygulamada kullanılır ve Authentication bypass oluşur
Peki tehlikesi nedir?
XSS saldırıları token çalabilir.
Tehlikeler:
Browser history, Referer header, Log sistemleri vs.
SameSite cookie
kısa ömürlü access token
refresh token rotasyonu
Örneğin,
Uygulama iki sağlayıcı destekliyor diyelim:
Google ve GitHub
Eğer authorization response hangi sağlayıcıdan geldiği doğrulanmazsa saldırgan akışları karıştırabilir.
Meydana ne gelir?
yanlış identity mapping ve hesap ele geçirme.
Kaldırılan özellikler:
Implicit Flow
Password Grant
Önerilen standart:
Güvenlik için başka neler yapılmalı?
strict redirect URI validation, signed authorization requests, sender constrained tokens vs.
Modern web uygulamalarının büyük bölümü kimlik doğrulama ve yetkilendirme süreçlerini dış servis sağlayıcılara devretmek için OAuth 2.0 ve OpenID Connect (OIDC) protokollerini kullanmaktadır. Google, Microsoft, GitHub gibi sağlayıcılarla yapılan “Login with X” entegrasyonlarının büyük kısmı bu standartlara dayanır.
Ancak bu protokoller doğru şekilde implement edilmediğinde kimlik ele geçirme, token çalınması ve yetkisiz erişim gibi kritik güvenlik açıklarına yol açabilir. Çoğu saldırı doğrudan protokol zafiyetinden değil, geliştiricilerin implementasyon hatalarından kaynaklanır.
Bu konumuzda OAuth 2.0 ve OpenID Connect implementasyonlarında en sık görülen teknik güvenlik hataları ve bu hataların nasıl sömürülebileceği detaylı olarak ele alacağız.
OAuth 2.0 ve OpenID Connect Temelleri
OAuth 2.0 aslında bir yetkilendirme (authorization) protokolüdür. Kullanıcı kimlik doğrulaması doğrudan OAuth’un görevi değildir.OpenID Connect ise OAuth 2.0 üzerine inşa edilmiş bir kimlik doğrulama katmanıdır.
Tipik Authorization Code Flow şu adımlardan oluşur:
Kullanıcı uygulama üzerinden login işlemini başlatır >> Uygulama kullanıcıyı Authorization Server'a yönlendirir >> Kullanıcı kimlik doğrulaması yapar >> Authorization Server uygulamaya bir authorization code gönderir >> Uygulama bu code'u kullanarak access token ve ID token alır >> Access token ile API çağrıları yapılır
UYARI Yapılan yanlış implementasyon güvenlik riski oluşturabilir.
Redirect URI Doğrulama Hataları
OAuth akışının en kritik parametrelerinden biri redirect_uri parametresidir. Authorization server, login işleminden sonra kullanıcıyı bu URI'ye yönlendirir.Eğer redirect URI doğrulaması hatalı yapılırsa saldırgan authorization code interception gerçekleştirebilir.
Hatalı Doğrulama Örnekleri
En yaygın hata partial matching kullanılmasıdır.Örnek:
Kod:
Allowed redirect:
https://example.com/callbackSunucu şu kontrolü yapıyorsa:
Kod:
if redirect_uri.startswith("https://example.com")Saldırgan şu URI'yi kullanabilir:
Kod:
https://example.com.attacker.com/callbackAuthorization code saldırgana gider.
Open Redirect Zinciri
Bir diğer saldırı tekniği uygulama içindeki open redirect endpointlerinin kullanılmasıdır.Örnek:
Kod:
https://example.com/redirect?url=https://attacker.comAuthorization server şu URI'yi kabul ediyorsa:
Kod:
https://example.com/redirectSaldırı şu şekilde gerçekleşir:
Kod:
redirect_uri=https://example.com/redirect?url=https://attacker.comAuthorization code example.com'a gönderilir >> Open redirect tetiklenir >> Code attacker.com'a yönlendirilir
Bu teknik birçok bug bounty programında kritik zafiyet olarak rapor edildi.
State Parametresi ve CSRF Saldırıları
OAuth akışında state parametresi CSRF koruması için kullanılır.Normalde:
Kod:
GET /authorize?
client_id=123
redirect_uri=https://app.com/callback
state=random_valueAuthorization server bu değeri geri döndürür:
Kod:
https://app.com/callback?code=abc&state=random_valueUygulama state değerini doğrular.
State Kullanılmayan Sistemlerde Saldırı
Eğer state kullanılmazsa saldırgan kullanıcıyı şu linke yönlendirir:
Kod:
https://authserver.com/authorize?
client_id=victim_app
redirect_uri=https://victim.com/callback
code=attacker_codeKullanıcı saldırganın hesabına bağlı token ile login olur ve hesap bağlama saldırısı gerçekleşir
Bu saldırı türü Login CSRF olarak bilinir.
PKCE Eksikliği ve Authorization Code Interception
Public client'lar (mobil uygulamalar, SPA) client secret saklayamaz. Bu yüzden PKCE (Proof Key for Code Exchange) kullanılır.PKCE mekanizması şu adımlardan oluşur:
Kod:
code_verifier -> random string
code_challenge = SHA256(code_verifier)Authorization request:
Kod:
code_challenge=abc123Token request:
Kod:
code_verifier=original_stringServer doğrular.
Peki.. PKCE Olmadan Saldırı Olsaydı ?
Örneğin,Kullanıcı public WiFi kullanıyor >> Saldırgan MITM pozisyonunda >> Authorization code yakalanır >> Saldırgan token endpoint'e gönderir >> Access token elde edilir
PKCE bu saldırıyı engeller çünkü saldırgan code_verifier değerini bilmez.
ID Token Doğrulama Hataları
OpenID Connect implementasyonlarında en kritik hatalar JWT doğrulama aşamasında yapılır.Bir ID token tipik olarak şu yapıdadır:
Kod:
header.payload.signaturePayload içinde şu alanlar bulunur:
Kod:
iss
aud
sub
exp
iatAlgoritma Manipülasyonu (alg none)
Bazı hatalı implementasyonlar JWT doğrulamasını şu şekilde yapar:
Kod:
if token.alg == "none":
accept_token()Saldırgan şu token'ı oluşturabilir:
Kod:
header:
{
"alg": "none"
}Sunucu imza doğrulaması yapmaz.
Bu durum authentication bypass ile sonuçlanır.
Audience Kontrolünün Yapılmaması
ID token içindeki aud alanı token'ın hangi uygulama için üretildiğini belirtir.Eğer doğrulanmazsa:
Saldırgan başka bir uygulama için token alır. Bu token hedef uygulamada kullanılır ve Authentication bypass oluşur
Token Saklama Hataları
Access token ve ID token yanlış saklanırsa token theft gerçekleşebilir.Tehditi Saklama Yöntemleri
LocalStorage:
Kod:
localStorage.setItem("token", access_token)XSS saldırıları token çalabilir.
URL İçinde Token
Implicit flow kullanan sistemlerde token URL fragment içinde taşınır.
Kod:
https://app.com/callback#access_token=123Tehlikeler:
Browser history, Referer header, Log sistemleri vs.
Daha Güvenli Yöntemler
HttpOnly cookieSameSite cookie
kısa ömürlü access token
refresh token rotasyonu
OAuth Mix-Up Attack
Bu saldırı çok sağlayıcılı OAuth implementasyonlarında görülür.Örneğin,
Uygulama iki sağlayıcı destekliyor diyelim:
Google ve GitHub
Eğer authorization response hangi sağlayıcıdan geldiği doğrulanmazsa saldırgan akışları karıştırabilir.
Meydana ne gelir?
yanlış identity mapping ve hesap ele geçirme.
OAuth 2.1 ve Modern Güvenlik Yaklaşımı
OAuth 2.1 birçok riskli akışı kaldırmayı hedefler.Kaldırılan özellikler:
Implicit Flow
Password Grant
Önerilen standart:
Kod:
Authorization Code Flow + PKCEGüvenlik için başka neler yapılmalı?
strict redirect URI validation, signed authorization requests, sender constrained tokens vs.