OAuth ile Account takeover

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE) Azure Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

Temel Bilgiler

OAuth çeşitli sürümler sunar; temel bilgiler için OAuth 2.0 documentation adresine bakabilirsiniz. Bu bölüm öncelikle yaygın olarak kullanılan OAuth 2.0 authorization code grant type üzerine odaklanır ve bir uygulamanın başka bir uygulamadaki kullanıcının hesabına erişmesine veya hesap üzerinde işlem yapmasına izin veren bir authorization framework sağlar (authorization server).

Varsayımsal bir site olan https://example.com’u düşünün; bu site özel olanlar da dahil tüm sosyal medya gönderilerinizi sergilemek üzere tasarlanmıştır. Bunu gerçekleştirmek için OAuth 2.0 kullanılır. https://example.com sosyal medya gönderilerinize erişim izni isteyecektir. Bunun sonucunda https://socialmedia.com üzerinde, istenen izinleri ve istekte bulunan geliştiriciyi gösteren bir onay ekranı görüntülenir. Siz izin verdiğinizde, https://example.com sizin adınıza gönderilerinize erişme yetkisi kazanır.

OAuth 2.0 çerçevesindeki aşağıdaki bileşenleri anlamak önemlidir:

  • resource owner: Siz, yani kullanıcı/varlık, sosyal medya hesabınızın gönderileri gibi kaynaklarınıza erişime izin verirsiniz.
  • resource server: Uygulama resource owner adına bir access token aldıktan sonra kimlik doğrulanmış istekleri yöneten sunucu, örn. https://socialmedia.com.
  • client application: resource owner’dan yetki isteyen uygulama, örn. https://example.com.
  • authorization server: resource owner’ın başarılı kimlik doğrulamasını ve yetkilendirmesini takiben client application’a access tokens veren sunucu, örn. https://socialmedia.com.
  • client_id: Uygulama için genel, benzersiz bir tanımlayıcı.
  • client_secret: Yalnızca uygulama ve authorization server tarafından bilinen gizli bir anahtar; access_tokens üretmek için kullanılır.
  • response_type: Talep edilen token türünü belirten bir değer, örn. code.
  • scope: client application’ın resource owner’dan talep ettiği erişim düzeyi.
  • redirect_uri: Kullanıcının yetkilendirme sonrası yönlendirileceği URL. Genellikle önceden kayıtlı redirect URL ile eşleşmelidir.
  • state: Kullanıcının authorization server ile yönlendirilmesi sırasında veriyi korumak için kullanılan bir parametre. Benzersizliği CSRF koruması için kritiktir.
  • grant_type: Döndürülecek token türünü ve grant tipini belirten bir parametre.
  • code: authorization server tarafından verilen yetkilendirme kodu; client application tarafından client_id ve client_secret ile birlikte access_token almak için kullanılır.
  • access_token: client application’ın resource owner adına API istekleri yapmak için kullandığı token.
  • refresh_token: Uygulamanın kullanıcıyı yeniden istemeden yeni bir access_token almasını sağlar.

Akış

Gerçek OAuth akışı şu şekilde ilerler:

  1. https://example.com adresine gidersiniz ve “Integrate with Social Media” butonunu seçersiniz.
  2. Site daha sonra https://socialmedia.com adresine, https://example.com uygulamasının gönderilerinize erişmesi için yetki talep eden bir istek gönderir. İstek şu şekilde yapılandırılır:
https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123
  1. Ardından size bir onay sayfası gösterilir.
  2. Onayınızın ardından, Social Media redirect_uri’ye code ve state parametreleri ile bir yanıt gönderir:
https://example.com?code=uniqueCode123&state=randomString123
  1. https://example.com bu code’u, client_id ve client_secret ile birlikte kullanarak sizin adınıza bir server-side istek yapar ve bir access_token elde eder; bu, onayladığınız izinlere erişime olanak tanır:
POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
  1. Son olarak süreç, https://example.com sizin access_token’ınızı kullanarak Sosyal Medya’ya bir API çağrısı yapar ve erişim sağlar

Vulnerabilities

Open redirect_uri

Per RFC 6749 §3.1.2, authorization server tarayıcıyı yalnızca önceden kaydedilmiş, tam eşleşen redirect URIs’e yönlendirmelidir. Buradaki herhangi bir zayıflık, bir saldırganın mağduru kötü amaçlı bir authorization URL’si üzerinden göndermesine ve IdP’nin mağdurun code (ve state) değerini doğrudan saldırganın endpoint’ine teslim etmesine izin verir; saldırgan daha sonra bunu redeem ederek tokens toplar.

Tipik saldırı akışı:

  1. https://idp.example/auth?...&redirect_uri=https://attacker.tld/callback oluşturun ve mağdura gönderin.
  2. Mağdur kimlik doğrulaması yapar ve scopes’ları onaylar.
  3. IdP attacker.tld/callback?code=<victim-code>&state=... adresine redirect eder; saldırgan isteği kaydeder ve kodu hemen exchange ederek alır.

Sınanacak yaygın doğrulama hataları:

  • No validation – herhangi bir absolute URL kabul edilir, bu da anında code hırsızlığı ile sonuçlanır.
  • Weak substring/regex checks on the host – evilmatch.com, match.com.evil.com, match.com.mx, matchAmatch.com, evil.com#match.com veya match.com@evil.com gibi benzer görünümlü host’larla atlatılabilir.
  • IDN homograph mismatches – doğrulama punycode formunda (xn--) yapılır, fakat tarayıcı saldırganın kontrolündeki Unicode domaine yönlendirir.
  • Arbitrary paths on an allowed host – redirect_uri’yi /openredirect?next=https://attacker.tld veya herhangi bir XSS/kullanıcı-içeriği endpoint’ine işaret etmek, zincirlenmiş redirect’ler, Referer header’ları veya injected JavaScript yoluyla code’un sızmasına neden olur.
  • Directory constraints without normalization – /oauth/* gibi desenler /oauth/../anything ile atlatılabilir.
  • Wildcard subdomains – *.example.com kabul edilmesi, herhangi bir takeover (dangling DNS, S3 bucket vb.) durumunda anında geçerli bir callback sağlar.
  • Non-HTTPS callbacks – http:// URI’lerine izin verilmesi, ağ saldırganlarına (Wi-Fi, corporate proxy) kodu aktarım sırasında ele geçirme fırsatı verir.

Ayrıca auxiliary redirect-style parametrelerini (client_uri, policy_uri, tos_uri, initiate_login_uri, vb.) ve OpenID discovery dokümanını (/.well-known/openid-configuration) gözden geçirin — buralardaki ek endpoint’ler aynı doğrulama hatalarını miras alabilir.

XSS in redirect implementation

As mentioned in this bug bounty report https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html redirect URL’nin server yanıtında yansıtılıyor olması ve bunun XSS’ye açık olması mümkün olabilir. Test edilebilecek olası payload:

https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>

CSRF - state parametresinin uygunsuz işlenmesi

state parameter is the Authorization Code flow CSRF token: the client must generate a kriptografik olarak rastgele değer, her tarayıcı örneği için, bunu yalnızca o tarayıcının okuyabileceği bir yere saklamalı (cookie, local storage, vb.), yetkilendirme isteğinde göndermeli ve aynı değeri döndürmeyen herhangi bir yanıtı reddetmelidir. Değer statik, öngörülebilir, isteğe bağlı veya kullanıcının oturumuna bağlı değilse, saldırgan kendi OAuth akışını tamamlayıp son ?code= isteğini yakalayabilir (göndermeden), URL’yi saklayabilir ve daha sonra kurban tarayıcısını bu isteği yeniden oynatmaya zorlayarak kurban hesabının saldırganın identity provider profiline bağlanmasını sağlayabilir.

Tekrar oynatma deseni her zaman aynıdır:

  1. Saldırgan kendi hesabıyla IdP’ye kimlik doğrular ve code (ve varsa state) içeren son yönlendirmeyi yakalar.
  2. O isteği atar (göndermez), URL’yi saklar ve daha sonra herhangi bir CSRF primitive’ini (link, iframe, otomatik gönderilen form) kötüye kullanarak kurban tarayıcısının bunu yüklemesini sağlar.
  3. Eğer client state’i zorunlu kılmazsa, uygulama saldırganın yetkilendirme sonucunu tüketir ve saldırganı kurbanın uygulama hesabına giriş yapmış gibi oturum açtırır.

Testler sırasında state işleme için pratik kontrol listesi:

  • Tamamen eksik state – eğer parametre hiç görünmüyorsa, tüm giriş CSRF’ye açıktır.
  • state gerekli değil – ilk istekte kaldırın; eğer IdP yine de client’ın kabul ettiği kodları veriyorsa, savunma isteğe bağlıdır.
  • Dönen state doğrulanmıyor – yanıt içindeki değeri değiştirin (Burp, MITM proxy). Uyuşmayan değerleri kabul etmek, saklanan token’in asla karşılaştırılmadığı anlamına gelir.
  • Öngörülebilir veya tamamen veri odaklı state – birçok uygulama yönlendirme yollarını veya JSON blob’larını state içine koyar ancak rastgelelik katmaz; bu, saldırganların geçerli değerleri tahmin edip akışları tekrar oynatmasına izin verir. Verileri encode etmeden önce mutlaka güçlü entropi ekleyin (başına/sonuna).
  • state fixation – eğer uygulama kullanıcılara state değerini sağlamasına izin veriyorsa (örn. hazırlanmış authorization URL’leri aracılığıyla) ve akış boyunca bunu yeniden kullanıyorsa, saldırgan bilinen bir değeri kilitleyip farklı kurbanlarda yeniden kullanabilir.

PKCE, state’i tamamlayabilir (özellikle public clients için) — authorization code’u bir code verifier’a bağlayarak — ancak web client’ları yine de cross-user CSRF/account-linking hatalarını önlemek için state’i takip etmelidir.

Hesap Ele Geçirme Öncesi

  1. Hesap Oluştururken Email Doğrulaması Olmaması: Saldırganlar kurbanın e-postasını kullanarak önceden bir hesap oluşturabilir. Eğer kurban daha sonra üçüncü taraf bir hizmetle giriş yaparsa, uygulama yanlışlıkla bu üçüncü taraf hesabını saldırganın önceden oluşturduğu hesapla ilişkilendirebilir ve yetkisiz erişime yol açabilir.
  2. Gevşek OAuth Email Doğrulamasını Sömürme: Saldırganlar, e-postaları doğrulamayan OAuth servislerini kötüye kullanarak bu serviste kayıt olabilir ve sonra hesap e-postasını kurbanın e-postasına değiştirebilir. Bu yöntem de benzer şekilde yetkisiz hesap erişimi riski taşır; ilk senaryoya benzer ama farklı bir saldırı vektörü aracılığıyla gerçekleşir.

Gizli Bilgilerin İfşası

client_id kasıtlı olarak herkese açıktır, ancak client_secret asla son kullanıcılar tarafından geri elde edilebilir olmamalıdır. Secret’ı mobile APK’lara, desktop client’lara veya single-page app’lere gömen Authorization Code dağıtımları, paketi indirebilen herkese bu kimlik bilgilerini verir. Public client’ları her zaman şu şekilde inceleyin:

  • APK/IPA, desktop installer veya Electron uygulamasını açıp client_secret, Base64 blob’ları (JSON çözen) veya hard-coded OAuth endpoint’leri için grep ile arayın.
  • Paketlenmiş config dosyalarını (plist, JSON, XML) veya decompile edilmiş string’leri client kimlik bilgileri açısından gözden geçirin.

Saldırgan secret’ı çıkardıktan sonra, herhangi bir kurbanın yetkilendirme code’unu (zayıf bir redirect_uri, loglar vb. aracılığıyla) çalması yeterlidir; böylece meşru uygulamayı dahil etmeden /token’a doğrudan istek yapıp access/refresh token’lar oluşturabilir. Public/native client’ları secret saklayamaz olarak değerlendirin — bunun yerine statik bir secret yerine her örneğe özgü bir code verifier sahipliğini kanıtlamak için PKCE (RFC 7636) kullanılmalıdır. Test sırasında PKCE’nin zorunlu olup olmadığını ve backend’in client_secret veya geçerli bir code_verifier eksikse token exchange’lerini gerçekten reddedip reddetmediğini doğrulayın.

Client Secret Bruteforce

You can try to bruteforce the client_secret of a service provider with the identity provider in order to be try to steal accounts.
The request to BF may look similar to:

POST /token HTTP/1.1
content-type: application/x-www-form-urlencoded
host: 10.10.10.10:3000
content-length: 135
Connection: close

code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce]

Referer Header içinde leaking Code + State

İstemci code and state’ı aldıktan sonra, farklı bir sayfaya giderken bunlar Referer header içinde yansıtılıyorsa, uygulama savunmasızdır.

Tarayıcı Geçmişinde Saklanan Access Token

Authorization Code grant’in temel garantisi, access tokens hiçbir zaman resource owner’ın tarayıcısına ulaşmaz. Implementasyonlar token’ları client-side leak ettiğinde, herhangi bir küçük hata (XSS, Referer leak, proxy logging) anında hesap ele geçirmeye dönüşür. Aşağıdakileri mutlaka kontrol edin:

  • Tokens in URLs – Eğer access_token query/fragment içinde görünüyorsa, tarayıcı geçmişine, sunucu loglarına, analytics’e ve üçüncü taraflara gönderilen Referer header’larına düşer.
  • Tokens transiting untrusted middleboxes – token’ların HTTP üzerinden veya debugging/kurumsal proxy’ler aracılığıyla dönmesi, ağ gözlemcilerinin bunları doğrudan yakalamasına izin verir.
  • Tokens stored in JavaScript state – React/Vue store’ları, global değişkenler veya serileştirilmiş JSON blob’ları token’ları origin’deki her script’e (XSS payload’ları veya kötü amaçlı uzantılar dahil) açar.
  • Tokens persisted in Web Storage – localStorage/sessionStorage token’ları, paylaşılan cihazlarda logout’tan çok sonra bile saklar ve script’ler tarafından erişilebilir olur.

Bu bulgulardan herhangi biri, genellikle aksi takdirde “low” seviyesinde olan hataları (ör. CSP bypass veya DOM XSS) tam bir API ele geçirmeye yükseltir çünkü saldırgan leaked bearer token’ı basitçe okuyup tekrar oynatabilir.

Sürekli kalan Authorization Code

Authorization code’lar kısa ömürlü, tek kullanımlık ve replay-aware olmalıdır. Bir akışı değerlendirirken bir code yakalayın ve:

  • Test the lifetime – RFC 6749 dakikaları tavsiye eder, saatleri değil. codeu 5–10 dakika sonra redeem etmeyi deneyin; hala çalışıyorsa, herhangi bir leaked code için maruz kalma süresi aşırı büyüktür.
  • Test sequential reuse – aynı codeu iki kez gönderin. İkinci istek başka bir token veriyorsa, saldırganlar oturumları sınırsızca klonlayabilir.
  • Test concurrent redemption/race conditions – iki token isteğini paralel çalıştırın (Burp intruder, turbo intruder). Zayıf issuer’lar bazen her ikisini de verir.
  • Observe replay handling – bir yeniden kullanım denemesi sadece başarısız olmamalı, aynı zamanda o code’dan daha önce üretilmiş token’ları da iptal etmelidir. Aksi halde, tespit edilen bir replay saldırganın ilk token’ını aktif bırakır.

Replay-dostu bir code’u herhangi bir redirect_uri veya logging hatası ile birleştirmek, mağdur meşru girişi tamamladıktan sonra bile kalıcı hesap erişimine izin verir.

Authorization/Refresh Token client’a bağlı değilse

Eğer authorization code’u elde edip farklı bir client ile kullanabiliyorsanız, diğer hesapları ele geçirebilirsiniz.

Happy Paths, XSS, Iframes & Post Messages ile code & state değerlerini leak etmek

Bu yazıya bakın

AWS Cognito

Bu bug bounty raporunda: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ görebileceğiniz gibi, token’ın AWS Cognito tarafından kullanıcıya geri verilmesi, kullanıcı verisini üzerine yazmaya yetecek kadar izinlere sahip olabilir. Bu nedenle, eğer bir kullanıcının e-postasını farklı bir kullanıcı e-postasıyla change edebiliyorsanız, başkalarının hesaplarını ele geçirebilirsiniz.

# Read info of the user
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]

# Change email address
aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com
{
"CodeDeliveryDetailsList": [
{
"Destination": "i***@f***.com",
"DeliveryMedium": "EMAIL",
"AttributeName": "email"
}
]
}

For more detailed info about how to abuse AWS Cognito check AWS Cognito - Unauthenticated Enum Access.

Diğer Uygulamaların token’larını kötüye kullanma

As mentioned in this writeup, OAuth akışları token (kod değil) almayı bekliyorsa ve tokenın uygulamaya ait olduğunu doğrulamıyorsa zayıf olabilir.

Bu, bir saldırganın kendi uygulamasında OAuth destekleyen ve login with Facebook (örneğin) bir uygulama oluşturabilmesinden kaynaklanır. Daha sonra, bir kurban saldırganın uygulamasında Facebook ile giriş yaptığında, saldırgan kurbana verilen OAuth token’ını alıp, bu token’ı kullanarak kurbanın OAuth uygulamasına kurbanın kullanıcı token’ı ile giriş yapabilir.

Caution

Bu yüzden, saldırgan kullanıcıyı kendi OAuth uygulamasına eriştirirse, token bekleyen ve tokenın kendi app ID’lerine verilip verilmediğini kontrol etmeyen uygulamalarda kurbanın hesabını ele geçirebilir.

According to this writeup, kurbana returnUrl’u saldırganın sunucusuna işaret eden bir sayfa açtırmak mümkündü. Bu bilgi bir cookie’de (RU) saklanırdı ve sonraki bir adımda prompt kullanıcıya saldırganın host’una erişim verip vermek istemediğini sorardı.

Bu prompt’u atlatmak için, RU cookie’sini returnUrl kullanarak ayarlayacak OAuth akışını başlatmak üzere bir sekme açmak, prompt gösterilmeden önce sekmeyi kapatmak ve o değerin olmadığı yeni bir sekme açmak mümkündü. Böylece prompt saldırganın hostunu bildirmeyecek, ancak cookie ona ayarlanmış olacağından token yönlendirmede saldırganın hostuna gönderilecektir.

Prompt Interaction Bypass

As explained in this video, bazı OAuth implementasyonları webde kullanıcı platforma zaten giriş yaptıysa verilen erişimi doğrulamalarını engellemek için GET parametresi olarak prompt’u None (&prompt=none) olarak belirtmeye izin verir.

response_mode

As explained in this video, final URL’de kodun nerede verileceğini belirtmek için response_mode parametresini kullanmak mümkün olabilir:

  • response_mode=query -> Kod bir GET parametresi içinde verilir: ?code=2397rf3gu93f
  • response_mode=fragment -> Kod URL fragment parametresi içinde verilir: #code=2397rf3gu93f
  • response_mode=form_post -> Kod code adlı input ile bir POST form içinde verilir
  • response_mode=web_message -> Kod bir post message ile gönderilir: window.opener.postMessage({"code": "asdasdasd...

OAuth consent/login diyalogları clickjacking için ideal hedeftir: eğer frame içinde yüklenebiliyorsa, bir saldırgan kendi grafiklerini bindirebilir, gerçek butonları gizleyebilir ve kullanıcıları tehlikeli scope’ları onaylamaya veya hesap bağlamaya ikna edebilir. PoC’ler şu şekilde oluşturun:

  1. IdP authorization URL’sini <iframe sandbox="allow-forms allow-scripts allow-same-origin"> içinde yükleyin.
  2. Sahte butonları gizli Allow/Approve kontrolleri ile hizalamak için absolute positioning/opacity hileleri kullanın.
  3. İsteğe bağlı olarak stolen approval’ın hemen saldırgana fayda sağlaması için parametreleri (scopes, redirect URI) önceden doldurun.

Test sırasında IdP sayfalarının ya X-Frame-Options: DENY/SAMEORIGIN ya da kısıtlayıcı bir Content-Security-Policy: frame-ancestors 'none' verip vermediğini doğrulayın. Eğer ikisi de yoksa, NCC Group’s clickjacking PoC generator gibi araçlarla riski gösterin ve bir kurbanın saldırganın uygulamasını ne kadar kolay onayladığını kaydedin. Ek payload fikirleri için bakınız Clickjacking.

OAuth ROPC flow - 2 FA bypass

According to this blog post, bu, OAuth üzerinden username ve password ile girişe izin veren bir akıştır. Bu basit akış sırasında kullanıcıya izin verilen tüm eylemlere erişen bir token döndürülürse, bu token kullanılarak 2FA atlatılabilir.

ATO on web page redirecting based on open redirect to referrer

This blogpost bir open redirect’in referrer değerini kullanarak OAuth’u ATO’ya nasıl istismar edilebileceğini açıklar. Saldırı şu şekildeydi:

  1. Kurban saldırganın web sayfasına erişir
  2. Kurban kötü amaçlı linki açar ve bir opener Google OAuth akışını ek parametreler olarak response_type=id_token,code&prompt=none ile başlatır; referrer olarak saldırganın sitesi kullanılır.
  3. Opener’da, provider kurbanı yetkilendirdikten sonra redirect_uri parametresinin değerine (kurbanın web sitesi) 30X kod gönderir; bu yönlendirme sırasında hala referer saldırganın sitesini korur.
  4. Kurbanın sitesi referrer’a göre open redirect’i tetikler ve kurbanı saldırganın sitesine yönlendirir; çünkü response_type id_token,code idi, code URL fragment’inde saldırgana gönderilecek ve bu sayede saldırgan kurbanın hesabını Google üzerinden kurbanın sitesinde ele geçirebilecektir.

SSRFs parameters

Check this research For further details of this technique.

Dynamic Client Registration, OAuth’ta daha az belirgin fakat kritik bir güvenlik vektörüdür; özellikle Server-Side Request Forgery (SSRF) saldırıları için önemlidir. Bu endpoint, OAuth sunucularının client uygulamalara ait detayları almasına izin verir ve bunlar hassas URL’ler içerebilir.

Ana Noktalar:

  • Dynamic Client Registration genellikle /register ile eşlenir ve client_name, client_secret, redirect_uris ve logo veya JSON Web Key Sets (JWKs) için URL’ler gibi detayları POST ile kabul eder.
  • Bu özellik RFC7591 ve OpenID Connect Registration 1.0 spesifikasyonlarına uyar; bu spesifikasyonlar SSRF’ye açık olabilecek parametreler içerir.
  • Kayıt süreci sunucuları SSRF’ye birkaç şekilde açabilir:
    • logo_uri: Client uygulamanın logosu için bir URL; sunucu tarafından fetch edilirse SSRF tetikleyebilir veya URL yanlış işlendiğinde XSS’e yol açabilir.
    • jwks_uri: Client’ın JWK dokümanına ait bir URL; kötü amaçlı oluşturulursa sunucunun saldırgan kontrollü bir sunucuya outbound istek yapmasına neden olabilir.
    • sector_identifier_uri: redirect_uris dizisini referans eden bir URL; sunucunun bunu fetch etmesi SSRF fırsatı yaratabilir.
    • request_uris: Client için izin verilen request URI listesi; sunucu bu URI’leri authorization sürecinin başında fetch ediyorsa istismar edilebilir.

Sömürme Stratejisi:

  • logo_uri, jwks_uri veya sector_identifier_uri gibi parametrelere kötü amaçlı URL’ler koyarak yeni bir client kaydı yaparak SSRF tetiklenebilir.
  • request_uris üzerinden doğrudan istismar whitelist kontrolleriyle engellenmiş olabilir, ancak önceden kaydedilmiş, saldırgan kontrollü bir request_uri sağlamak authorization aşamasında SSRF kolaylaştırabilir.

OAuth providers Race Conditions

If the platform you are testing is an OAuth provider read this to test for possible Race Conditions.

Mutable Claims Attack

OAuth’ta sub alanı bir kullanıcıyı benzersiz şekilde tanımlar, ancak Authorization Server’a göre formatı değişir. Bazı client’lar kullanıcı kimliğini standardize etmek için email veya kullanıcı takma isimleri kullanır. Bu risklidir çünkü:

  • Bazı Authorization Server’lar bu özelliklerin (ör. email) immutable kalmasını garanti etmez.
  • Bazı implementasyonlarda — örneğin “Login with Microsoft” — client email alanına güvenir; bu alan Entra ID içinde kullanıcı tarafından kontrol edilir ve doğrulanmış değildir.
  • Bir saldırgan kendi Azure AD organizasyonunu (ör. doyensectestorg) oluşturup bunu Microsoft ile giriş yapmak için kullanarak bunu istismar edebilir.
  • Object ID (sub içinde saklanan) immutable ve güvenliyken, mutable email alanına güvenmek hesap ele geçirmeye yol açabilir (ör. victim@gmail.com gibi bir hesabın çalınması).

Client Confusion Attack

Bir Client Confusion Attack’te, OAuth Implicit Flow kullanan bir uygulama nihai access token’ın özellikle kendi Client ID’si için oluşturulduğunu doğrulamaz. Bir saldırgan Google’ın OAuth Implicit Flow’unu kullanan halka açık bir web sitesi kurar, binlerce kullanıcıyı giriş yapmaya kandırarak saldırganın sitesi için oluşturulmuş access token’ları toplar. Bu kullanıcıların aynı zamanda token’ın Client ID’sini doğrulamayan başka bir savunmasız siteye hesapları varsa, saldırgan toplanan token’ları yeniden kullanarak kurbanların yerine geçebilir ve hesapları ele geçirebilir.

Scope Upgrade Attack

Authorization Code Grant türü kullanıcı verilerini iletmek için güvenli server-to-server iletişimi içerir. Ancak, Authorization Server Access Token Request içindeki (RFC’de tanımlı olmayan) scope parametresine zımni bir şekilde güvenirse, kötü amaçlı bir uygulama authorization kodunun ayrıcalıklarını daha yüksek bir scope isteyerek yükseltebilir. Access Token oluşturulduktan sonra Resource Server bunu doğrulamalıdır: JWT tokenlar için JWT imzasını kontrol etmek ve client_id ile scope gibi verileri çıkarmak gerekir; rastgele string tokenlar için ise sunucu token detaylarını almak üzere Authorization Server’a sorgu göndermelidir.

Redirect Scheme Hijacking

Mobil OAuth implementasyonlarında uygulamalar Authorization Code’ları almak için custom URI schemes kullanır. Ancak bir cihazda aynı scheme’i birden fazla uygulama kaydedebildiği için sadece meşru client’ın redirect URI’yi kontrol ettiği varsayımı bozulur. Android’de örneğin com.example.app:// gibi bir Intent URI scheme ve uygulamanın intent-filter’larında tanımlanan opsiyonel filtrelere göre yakalanır. Android’in intent çözümlemesi özellikle sadece scheme belirtilmişse geniş olabilir — bu durumda bir saldırgan dikkatle hazırlanmış bir intent filter ile kötü amaçlı bir uygulama kaydederek authorization kodunu ele geçirebilir. Bu, (birden fazla uygulama intent’i ele alabilecek durumda olduğunda) kullanıcı etkileşimiyle veya Ostorlab’ın değerlendirme akışının detaylandırdığı gibi aşırı spesifik filtreleri kötüye kullanan atlatma teknikleriyle hesap ele geçirmeye yol açabilir.

References

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE) Azure Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin