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 का समर्थन करें

Basic Information

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

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

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

  • resource owner: आप, user/entity के रूप में, अपने resource — जैसे आपके सोशल मीडिया अकाउंट के पोस्ट — की पहुँच को authorize करते हैं।
  • resource server: वह server जो authenticated requests को manage करता है, जब application ने resource owner की ओर से access token हासिल कर लिया हो; उदाहरण के लिए, https://socialmedia.com।
  • client application: वह application जो resource owner से authorization चाहता है, जैसे https://example.com।
  • authorization server: वह server जो resource owner की सफल authentication और authorization के बाद client application को access tokens जारी करता है, उदाहरण के लिए https://socialmedia.com।
  • client_id: application के लिए एक public, unique identifier।
  • client_secret: एक confidential key, जो केवल application और authorization server को पता होती है, और जिसका उपयोग access_tokens उत्पन्न करने में होता है।
  • response_type: एक value जो दर्शाती है वांछित टोकन के प्रकार, जैसे code।
  • scope: वह access का स्तर जो client application resource owner से अनुरोध कर रही है।
  • redirect_uri: वह URL जहाँ user authorization के बाद redirect किया जाता है। सामान्यतः यह pre-registered redirect URL के साथ मेल खाना चाहिए।
  • state: एक parameter जो authorization server के साथ user के redirection से पहले और बाद के दौरान data को बनाए रखता है। इसकी uniqueness CSRF protection mechanism के रूप में काम करने के लिए महत्वपूर्ण है।
  • grant_type: एक parameter जो बताता है grant type और लौटाए जाने वाले token का प्रकार।
  • code: authorization server से प्राप्त authorization code, जिसका उपयोग client application द्वारा client_id और client_secret के साथ मिलकर access_token प्राप्त करने के लिए किया जाता है।
  • access_token: वह token जिसे client application resource owner की ओर से API requests के लिए उपयोग करता है।
  • refresh_token: application को बिना user से फिर से prompt किए एक नया access_token प्राप्त करने में सक्षम बनाता है।

Flow

वास्तविक OAuth flow निम्नानुसार चलता है:

  1. आप https://example.com पर जाते हैं और “Integrate with Social Media” बटन चुनते हैं।
  2. फिर साइट https://socialmedia.com को एक request भेजती है, जो आपकी authorization मांगती है ताकि https://example.com की application आपकी पोस्ट्स तक पहुँच सके। यह request इस तरह संरचित है:
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 पैरामीटर के साथ एक प्रतिक्रिया भेजता है:
https://example.com?code=uniqueCode123&state=randomString123
  1. https://example.com इस code का उपयोग अपने client_id और client_secret के साथ मिलाकर आपकी ओर से access_token प्राप्त करने के लिए एक server-side request करता है, जिससे आप द्वारा सहमति दिए गए permissions तक पहुँच सक्षम हो जाती है:
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 निकाल सकता है।

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

  1. ऐसा https://idp.example/auth?...&redirect_uri=https://attacker.tld/callback URL तैयार करें और victim को भेजें।
  2. Victim authenticate करता है और scopes को अनुमति दे देता है।
  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 – validation punycode फ़ॉर्म (xn--) पर होती है, पर ब्राउज़र attacker द्वारा नियंत्रित Unicode डोमेन पर redirect करता है।
  • Arbitrary paths on an allowed host – pointing redirect_uri to /openredirect?next=https://attacker.tld or any XSS/user-content endpoint leaks the code either through chained redirects, Referer headers, or injected JavaScript.
  • Directory constraints without normalization – patterns like /oauth/* can be bypassed with /oauth/../anything.
  • Wildcard subdomains – accepting *.example.com means any takeover (dangling DNS, S3 bucket, etc.) immediately yields a valid callback.
  • Non-HTTPS callbacks – letting http:// URIs through gives network attackers (Wi-Fi, corporate proxy) the opportunity to snatch the code in transit.

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

XSS in redirect implementation

जैसा कि इस bug bounty रिपोर्ट https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html में बताया गया है, यह संभव हो सकता है कि redirect URL is being reflected in the response of the server after the user authenticates, being vulnerable to XSS. परीक्षण के लिए संभावित 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 को प्रत्येक ब्राउज़र इंस्टेंस के लिए एक क्रिप्टोग्राफिकली random value जेनरेट करनी चाहिए, उसे कहीं persist करना चाहिए जिसे केवल वही ब्राउज़र पढ़ सके (cookie, local storage, आदि), authorization request में भेजना चाहिए, और किसी भी response को reject कर देना चाहिए जो वही value वापस न करे। जब भी value static, predictable, optional, या user’s session से जुड़ी नहीं होती है, attacker अपना OAuth flow पूरा कर सकता है, अंतिम ?code= request को capture कर सकता है (बिना भेजे), और बाद में victim browser को उस request को replay करने के लिए मजबूर करके victim account को attacker के identity provider profile से linked करवा सकता है।

The replay pattern हमेशा एक जैसा होता है:

  1. The 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 हैंडलिंग के लिए एक practical checklist:

  • 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). असंगत वैल्यूज़ को स्वीकार करना मतलब stored token की कभी तुलना नहीं होती।
  • Predictable or purely data-driven state – कई apps state में redirect paths या JSON blobs डाल देते हैं बिना randomness मिलाए, जिससे attackers मान्य वैल्यूज़ का अनुमान लगा कर flows को replay कर सकते हैं। डेटा encode करने से पहले हमेशा मजबूत entropy prepend/append करें।
  • state fixation – अगर app users को state value देने की अनुमति देता है (उदा., crafted authorization URLs के माध्यम से) और पूरे flow में उसे reuse करता है, तो attacker एक ज्ञात value lock कर सकता है और उसे कई victims पर reuse कर सकता है।

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

Account Takeover से पहले

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

Secrets का प्रकटीकरण

The client_id जानबूझकर public होता है, लेकिन client_secret कभी भी end users द्वारा recoverable नहीं होना चाहिए। Authorization Code deployments जो secret को mobile APKs, desktop clients, या 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 बना सकें बिना legitimate app को शामिल किए। public/native clients को secrets रखने में असमर्थ मानें—उन्हें static secret के बजाय per-instance code verifier के कब्जे को प्रमाणित करने के लिए PKCE (RFC 7636) पर निर्भर करना चाहिए। टेस्टिंग के दौरान पुष्टि करें कि PKCE अनिवार्य है या नहीं और backend वास्तव में token exchanges को reject करता है या नहीं जो या तो client_secret या एक वैध code_verifier को omit करते हैं।

Client Secret Bruteforce

You can try to bruteforce the client_secret of a service provider with the identity provider in order to be try to steal accounts.
The request to BF may look similar to:

POST /token HTTP/1.1
content-type: application/x-www-form-urlencoded
host: 10.10.10.10:3000
content-length: 135
Connection: close

code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce]

Referer Header 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

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 – अगर access_token query/fragment में दिखाई दे, तो यह browser history, server logs, analytics, और third parties को भेजे जाने वाले 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 (जिसमें XSS payloads या malicious extensions शामिल हैं) के लिए tokens को एक्सपोज़ कर देते हैं।
  • Tokens persisted in Web Storage – localStorage/sessionStorage shared devices पर logout के बाद भी लंबा समय tokens को रखता है और ये scripts द्वारा एक्सेस किए जा सकते हैं।

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

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 minutes, not hours recommend करता है। 5–10 मिनट बाद code को redeem करके देखें; अगर यह अभी भी काम करता है, तो किसी leaked code के लिए exposure window बहुत बड़ा है।
  • Test sequential reuse – एक ही code को दो बार भेजें। अगर दूसरी request भी दूसरा token देती है, तो attackers सत्रों को अनिश्चित समय तक clone कर सकते हैं।
  • Test concurrent redemption/race conditions – दो token requests parallel में भेजें (Burp intruder, turbo intruder)। कमजोर issuers कभी-कभी दोनों को grant कर देते हैं।
  • Observe replay handling – reuse प्रयास केवल fail न हो बल्कि उस code से पहले से बने किसी भी token को revoke भी कर दे। अन्यथा, replay का पता चलने पर भी attacker का पहला token सक्रिय रहेगा।

एक replay-friendly code को किसी भी redirect_uri या logging bug के साथ मिलाने से persistent account access मिल सकता है, भले victim ने 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.

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

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

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

Caution

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

Two links & cookie

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

इस prompt को bypass करने के लिए, यह संभव था कि एक tab खोलकर Oauth flow init किया जाए जो इस 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 माँगे बिना ही access दे सकते हैं अगर वे पहले से platform पर logged in हों।

response_mode

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

  • response_mode=query -> कोड GET parameter के अंदर प्रदान किया जाता है: ?code=2397rf3gu93f
  • response_mode=fragment -> कोड URL fragment में प्रदान किया जाता है: #code=2397rf3gu93f
  • response_mode=form_post -> कोड एक POST form में एक input code के नाम से और उसके value के रूप में भेजा जाता है
  • response_mode=web_message -> कोड एक post message में भेजा जाता है: window.opener.postMessage({"code": "asdasdasd...

OAuth consent/login dialogs clickjacking के लिए आदर्श लक्ष्य होते हैं: अगर उन्हें framed किया जा सकता है तो एक attacker कस्टम ग्राफिक्स ओवरले कर सकता है, असली बटनों को छिपा सकता है, और users को खतरनाक scopes approve या accounts link करने के लिए trick कर सकता है। PoC बनाते समय:

  1. IdP authorization URL को एक <iframe sandbox="allow-forms allow-scripts allow-same-origin"> के अंदर लोड करें।
  2. fake बटनों को छिपे हुए Allow/Approve controls के साथ align करने के लिए absolute positioning/opacity tricks इस्तेमाल करें।
  3. वैकल्पिक रूप से parameters (scopes, redirect URI) पहले से भर दें ताकि चोरी की गई approval तुरंत attacker को फायदा दे सके।

टेस्टिंग के दौरान यह सत्यापित करें कि IdP पेज या तो X-Frame-Options: DENY/SAMEORIGIN emit करते हैं या एक restrictive Content-Security-Policy: frame-ancestors 'none'। अगर दोनों में से कोई नहीं है, तो NCC Group’s clickjacking PoC generator जैसे tooling से रिस्क दिखाएँ और record करें कि victim कितनी आसानी से attacker की app को authorize कर देता है। अतिरिक्त payload विचारों के लिए देखें 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

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

  1. Victim attacker के वेब पेज पर जाता है
  2. Victim malicious link खोलता है और एक opener Google OAuth flow start करता है जिसमें अतिरिक्त parameters के रूप में response_type=id_token,code&prompt=none होते हैं और referrer के रूप में attackers website का उपयोग होता है।
  3. Opener में, provider जब victim को authorize कर देता है, तो वह उन्हें redirect_uri parameter (victim web) पर 30X code के साथ वापस भेज देता है जो अभी भी attackers website को referer में रखता है।
  4. Victim की वेबसाइट referrer के आधार पर open redirect trigger करती है और victim user को attackers website पर redirect कर देती है; क्योंकि response_type id_token,code था, code URL के fragment में attacker को भेज दिया जाएगा जिससे attacker victim के site में 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) vulnerabilities के लिए उपयोगी हो सकता है। यह endpoint OAuth servers को client applications के बारे में विवरण प्राप्त करने की अनुमति देता है, जिसमें संवेदनशील URLs भी शामिल हैं जिन्हें exploit किया जा सकता है।

Key Points:

  • Dynamic Client Registration अक्सर /register पर मैप होती है और POST requests के जरिए client_name, client_secret, redirect_uris, और logo या 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 mishandle हुआ तो XSS का खतरा बन सकता है।
    • jwks_uri: client के JWK दस्तावेज़ का URL, जिसे malicious तरीके से बनाया गया हो तो server को attacker-controlled सर्वर पर outbound request करने के लिए मजबूर कर सकता है।
    • sector_identifier_uri: redirect_uris के JSON array को reference करता है, जिसे server fetch कर सकता है और इससे SSRF का मौका बन सकता है।
    • request_uris: client के लिए allowed request URIs की सूची, जिसे अगर server authorization प्रक्रिया के शुरुआत में fetch करता है तो exploit किया जा सकता है।

Exploitation Strategy:

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

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

OAuth में, sub field user को uniquely पहचानता है, लेकिन इसका format Authorization Server के हिसाब से बदलता है। कुछ clients users की पहचान standardize करने के लिए emails या user handles का उपयोग करते हैं। पर यह risky है क्योंकि:

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

Client Confusion Attack

Client Confusion Attack में, एक application जो OAuth Implicit Flow उपयोग करता है, यह सत्यापित करने में फेल हो जाता है कि final access token वास्तव में उसके अपने Client ID के लिए ही generate हुआ है। एक attacker एक public website सेटअप कर सकता है जो Google’s OAuth Implicit Flow का उपयोग करे और हजारों users को trick करके login करवा कर उन access tokens को harvest कर सकता है जो attacker की साइट के लिए बने होते हैं। अगर इन users के accounts किसी अन्य vulnerable वेबसाइट पर भी हों जो token के Client ID को validate नहीं करती, तो attacker harvested tokens का reuse करके victims की नुमाइंदगी कर सकता है और उनके accounts takeover कर सकता है।

Scope Upgrade Attack

Authorization Code Grant में user data भेजने के लिए secure server-to-server communication शामिल होती है। हालाँकि, अगर Authorization Server Access Token Request में एक scope parameter (जो RFC में defined नहीं है) पर implicitly भरोसा करता है, तो एक malicious application authorization code की privileges को बढ़ा सकता है higher scope request करके। जब Access Token generate होता है, तो Resource Server को उसे verify करना चाहिए: JWT tokens के मामले में यह JWT signature की जाँच और client_id तथा scope जैसे डेटा निकालने में शामिल है, जबकि random string tokens के लिए server को Authorization Server से token के details retrieve करने होंगे।

Redirect Scheme Hijacking

Mobile OAuth implementations में apps Authorization Codes प्राप्त करने के लिए custom URI schemes का उपयोग करते हैं। पर चूंकि एक ही scheme को कई apps पर register किया जा सकता है, इसलिए यह धारणा कि सिर्फ legitimate client redirect URI को नियंत्रित करता है टूट जाती है। Android पर, उदाहरण के लिए, एक Intent URI जैसे com.example.app:// oauth scheme और app के intent-filter में निर्दिष्ट optional filters के आधार पर catch किया जाता है। चूँकि Android की intent resolution व्यापक हो सकती है—विशेषकर अगर सिर्फ scheme specify किया गया हो—एक attacker एक malicious app register कर सकता है जिसमें सावधानीपूर्वक crafted intent filter हो जो authorization code को hijack कर ले। यह user interaction के जरिये (जब कई apps intent handle करने के योग्य हों) या bypass तकनीकों द्वारा जो overly specific filters का फायदा उठाती हैं, account takeover को सक्षम कर सकता है, जैसा कि Ostorlab की 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 का समर्थन करें