OAuth to Account takeover

Reading time: 20 minutes

Basic Information

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

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

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

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

Flow

वास्तविक OAuth प्रवाह इस प्रकार है:

1. आप https://example.com पर जाते हैं और “Integrate with Social Media” बटन का चयन करते हैं।
2. साइट फिर https://socialmedia.com पर आपके प्राधिकरण के लिए एक अनुरोध भेजती है ताकि https://example.com के एप्लिकेशन को आपके पोस्ट तक पहुंचने की अनुमति मिल सके। अनुरोध इस प्रकार संरचित है:

https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123

3. आपको फिर एक सहमति पृष्ठ प्रस्तुत किया जाता है।
4. आपकी स्वीकृति के बाद, Social Media redirect_uri को code और state पैरामीटर के साथ एक प्रतिक्रिया भेजता है:

https://example.com?code=uniqueCode123&state=randomString123

5. https://example.com इस code का उपयोग करता है, इसके client_id और client_secret के साथ, आपके पक्ष में access_token प्राप्त करने के लिए एक सर्वर-साइड अनुरोध करने के लिए, जिससे आपको उन अनुमतियों तक पहुँचने की अनुमति मिलती है जिन पर आपने सहमति दी थी:

POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}

6. अंत में, प्रक्रिया समाप्त होती है जब https://example.com आपके access_token का उपयोग करके सोशल मीडिया पर API कॉल करती है।

Vulnerabilities

Open redirect_uri

redirect_uri OAuth और OpenID कार्यान्वयन में सुरक्षा के लिए महत्वपूर्ण है, क्योंकि यह संवेदनशील डेटा, जैसे कि प्राधिकरण कोड, को प्राधिकरण के बाद भेजने के लिए निर्देशित करता है। यदि गलत तरीके से कॉन्फ़िगर किया गया, तो यह हमलावरों को इन अनुरोधों को दुर्भावनापूर्ण सर्वरों पर पुनर्निर्देशित करने की अनुमति दे सकता है, जिससे खाता अधिग्रहण संभव हो जाता है।

शोषण तकनीकें प्राधिकरण सर्वर की मान्यता लॉजिक के आधार पर भिन्न होती हैं। ये सख्त पथ मिलान से लेकर निर्दिष्ट डोमेन या उपनिर्देशिका के भीतर किसी भी URL को स्वीकार करने तक हो सकती हैं। सामान्य शोषण विधियों में ओपन रीडायरेक्ट, पथ यात्रा, कमजोर regex का शोषण, और टोकन चोरी के लिए HTML इंजेक्शन शामिल हैं।

redirect_uri के अलावा, अन्य OAuth और OpenID पैरामीटर जैसे client_uri, policy_uri, tos_uri, और initiate_login_uri भी पुनर्निर्देशन हमलों के प्रति संवेदनशील हैं। ये पैरामीटर वैकल्पिक हैं और इनका समर्थन सर्वरों में भिन्न होता है।

जो लोग OpenID सर्वर को लक्षित कर रहे हैं, उनके लिए खोज समाप्ति बिंदु (**.well-known/openid-configuration**) अक्सर मूल्यवान कॉन्फ़िगरेशन विवरण जैसे registration_endpoint, request_uri_parameter_supported, और "require_request_uri_registration" सूचीबद्ध करता है। ये विवरण पंजीकरण समाप्ति बिंदु और सर्वर के अन्य कॉन्फ़िगरेशन विशिष्टताओं की पहचान करने में मदद कर सकते हैं।

XSS in redirect implementation

जैसा कि इस बग बाउंटी रिपोर्ट में उल्लेख किया गया है https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html, यह संभव हो सकता है कि पुनर्निर्देशित URL सर्वर के उत्तर में परिलक्षित हो रहा है जब उपयोगकर्ता प्रमाणीकरण करता है, जिससे यह XSS के प्रति संवेदनशील हो जाता है। परीक्षण के लिए संभावित पेलोड:

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

CSRF - Improper handling of state parameter

OAuth कार्यान्वयन में, state parameter का दुरुपयोग या अनुपस्थिति Cross-Site Request Forgery (CSRF) हमलों के जोखिम को काफी बढ़ा सकती है। यह कमजोरियां तब उत्पन्न होती हैं जब state parameter या तो उपयोग नहीं किया जाता, स्थिर मान के रूप में उपयोग किया जाता है, या लॉगिन करते समय उपयोगकर्ताओं के सत्र के साथ सही ढंग से मान्य या संबद्ध नहीं किया जाता है, जिससे हमलावर CSRF सुरक्षा को बायपास कर सकते हैं।

हमलावर इसको अधिकृत प्रक्रिया को इंटरसेप्ट करके शिकार के खाते के साथ अपने खाते को लिंक करने के लिए उपयोग कर सकते हैं, जिससे संभावित खाते पर कब्जा हो सकता है जब एक उपयोगकर्ता हमलावर के लगभग पूर्ण OAuth प्रवाह के साथ लॉगिन करता है। यह विशेष रूप से उन अनुप्रयोगों में महत्वपूर्ण है जहाँ OAuth का उपयोग प्रमाणीकरण उद्देश्यों के लिए किया जाता है।

इस कमजोरियों के वास्तविक दुनिया के उदाहरण विभिन्न CTF चुनौतियों और हैकिंग प्लेटफार्मों में दस्तावेजीकृत किए गए हैं, जो इसके व्यावहारिक प्रभावों को उजागर करते हैं। यह समस्या तीसरे पक्ष की सेवाओं जैसे Slack, Stripe, और PayPal के साथ एकीकरण तक भी फैली हुई है, जहाँ हमलावर सूचनाओं या भुगतानों को अपने खातों में पुनर्निर्देशित कर सकते हैं।

state parameter का उचित प्रबंधन और मान्यता CSRF के खिलाफ सुरक्षा और OAuth प्रवाह को सुरक्षित करने के लिए महत्वपूर्ण है।

Pre Account Takeover

1. खाते के निर्माण पर ईमेल सत्यापन के बिना: हमलावर शिकार के ईमेल का उपयोग करके पूर्व-निर्मित खाता बना सकते हैं। यदि शिकार बाद में लॉगिन के लिए किसी तीसरे पक्ष की सेवा का उपयोग करता है, तो अनुप्रयोग अनजाने में इस तीसरे पक्ष के खाते को हमलावर के पूर्व-निर्मित खाते से लिंक कर सकता है, जिससे अनधिकृत पहुंच हो सकती है।
2. OAuth ईमेल सत्यापन की लापरवाही का लाभ उठाना: हमलावर उन OAuth सेवाओं का लाभ उठा सकते हैं जो ईमेल की पुष्टि नहीं करती हैं, अपनी सेवा के साथ पंजीकरण करके और फिर खाते के ईमेल को शिकार के ईमेल में बदलकर। यह विधि भी पहले परिदृश्य के समान अनधिकृत खाता पहुंच का जोखिम उठाती है, लेकिन एक अलग हमले के वेक्टर के माध्यम से।

Disclosure of Secrets

गुप्त OAuth पैरामीटर की पहचान और सुरक्षा महत्वपूर्ण है। जबकि client_id को सुरक्षित रूप से प्रकट किया जा सकता है, client_secret का खुलासा महत्वपूर्ण जोखिम पैदा करता है। यदि client_secret से समझौता किया जाता है, तो हमलावर उपयोगकर्ता access_tokens और निजी जानकारी को चोरी करने के लिए अनुप्रयोग की पहचान और विश्वास का लाभ उठा सकते हैं।

एक सामान्य कमजोरी तब उत्पन्न होती है जब अनुप्रयोग गलती से ग्राहक-पक्ष पर access_token के लिए अधिकृत code के आदान-प्रदान को संभालते हैं, न कि सर्वर-पक्ष पर। यह गलती client_secret के उजागर होने का कारण बनती है, जिससे हमलावर अनुप्रयोग के बहाने access_tokens उत्पन्न कर सकते हैं। इसके अलावा, सामाजिक इंजीनियरिंग के माध्यम से, हमलावर OAuth अधिकृत में अतिरिक्त स्कोप जोड़कर विशेषाधिकार बढ़ा सकते हैं, जिससे अनुप्रयोग की विश्वसनीय स्थिति का और अधिक लाभ उठाया जा सकता है।

Client Secret Bruteforce

आप सेवा प्रदाता के पहचान प्रदाता के साथ client_secret को ब्रूटफोर्स करने का प्रयास कर सकते हैं ताकि खातों को चुराने की कोशिश की जा सके।
BF के लिए अनुरोध इस तरह दिख सकता है:

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

एक बार जब क्लाइंट के पास कोड और स्टेट हो, यदि यह Referer हेडर के अंदर परिलक्षित होता है जब वह किसी अन्य पृष्ठ पर जाता है, तो यह कमजोर है।

Access Token Stored in Browser History

ब्राउज़र इतिहास पर जाएं और जांचें कि क्या एक्सेस टोकन वहां सहेजा गया है।

Everlasting Authorization Code

अधिकार कोड को केवल कुछ समय के लिए जीवित रहना चाहिए ताकि हमलावर द्वारा चुराए जाने और उपयोग किए जाने के समय की खिड़की को सीमित किया जा सके।

Authorization/Refresh Token not bound to client

यदि आप अधिकार कोड प्राप्त कर सकते हैं और इसे एक अलग क्लाइंट के साथ उपयोग कर सकते हैं, तो आप अन्य खातों पर नियंत्रण कर सकते हैं।

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

Check this post

AWS Cognito

इस बग बाउंटी रिपोर्ट में: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ आप देख सकते हैं कि टोकन जो AWS Cognito उपयोगकर्ता को वापस देता है, उसमें उपयोगकर्ता डेटा को ओवरराइट करने के लिए पर्याप्त अनुमतियाँ हो सकती हैं। इसलिए, यदि आप एक अलग उपयोगकर्ता ईमेल के लिए उपयोगकर्ता ईमेल बदल सकते हैं, तो आप अन्य खातों पर नियंत्रण कर सकते हैं।

# 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 - HackTricks Cloud

Abusing other Apps tokens

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

यह इसलिए है क्योंकि एक हमलावर एक ऐप्लिकेशन बना सकता है जो OAuth का समर्थन करता है और फेसबुक के साथ लॉगिन करता है (उदाहरण के लिए) अपने स्वयं के ऐप में। फिर, जब एक पीड़ित फेसबुक के साथ हमलावर के ऐप में लॉगिन करता है, तो हमलावर उपयोगकर्ता के OAuth टोकन को प्राप्त कर सकता है जो उसके ऐप को दिया गया है, और इसका उपयोग पीड़ित OAuth ऐप में लॉगिन करने के लिए कर सकता है।

Two links & cookie

इस लेख के अनुसार, यह संभव था कि एक पीड़ित एक पृष्ठ खोले जिसमें returnUrl हमलावर के होस्ट की ओर इशारा करता है। यह जानकारी एक कुकी (RU) में स्टोर की जाएगी और बाद के चरण में प्रॉम्प्ट उपयोगकर्ता से पूछेगा कि क्या वह उस हमलावर के होस्ट को एक्सेस देने के लिए तैयार है।

इस प्रॉम्प्ट को बायपास करने के लिए, एक टैब खोलना संभव था ताकि Oauth प्रवाह को शुरू किया जा सके जो इस RU कुकी को returnUrl का उपयोग करके सेट करेगा, प्रॉम्प्ट दिखाए जाने से पहले टैब को बंद करें, और बिना उस मान के एक नया टैब खोलें। तब, प्रॉम्प्ट हमलावर के होस्ट के बारे में जानकारी नहीं देगा, लेकिन कुकी को इसके लिए सेट किया जाएगा, इसलिए टोकन हमलावर के होस्ट को रीडायरेक्शन में भेजा जाएगा।

Prompt Interaction Bypass

जैसा कि इस वीडियो में समझाया गया है, कुछ OAuth कार्यान्वयन prompt GET पैरामीटर को None (&prompt=none) के रूप में इंगित करने की अनुमति देते हैं ताकि उपयोगकर्ताओं को दिए गए एक्सेस की पुष्टि करने के लिए प्रॉम्प्ट में पूछा न जाए यदि वे पहले से ही प्लेटफॉर्म में लॉगिन कर चुके हैं।

response_mode

जैसा कि इस वीडियो में समझाया गया है, यह संभव हो सकता है कि response_mode पैरामीटर को इंगित किया जाए कि आप अंतिम URL में कोड कहां प्राप्त करना चाहते हैं:

• response_mode=query -> कोड एक GET पैरामीटर के अंदर प्रदान किया जाता है: ?code=2397rf3gu93f
• response_mode=fragment -> कोड URL फ़्रैगमेंट पैरामीटर #code=2397rf3gu93f के अंदर प्रदान किया जाता है
• response_mode=form_post -> कोड एक POST फॉर्म के अंदर प्रदान किया जाता है जिसमें एक इनपुट होता है जिसे code कहा जाता है और मान होता है
• response_mode=web_message -> कोड एक पोस्ट संदेश में भेजा जाता है: window.opener.postMessage({"code": "asdasdasd...

OAuth ROPC flow - 2 FA bypass

इस ब्लॉग पोस्ट के अनुसार, यह एक OAuth प्रवाह है जो उपयोगकर्ता नाम और पासवर्ड के माध्यम से OAuth में लॉगिन करने की अनुमति देता है। यदि इस सरल प्रवाह के दौरान एक टोकन लौटाया जाता है जिसमें सभी क्रियाओं तक पहुंच होती है जो उपयोगकर्ता कर सकता है, तो उस टोकन का उपयोग करके 2FA को बायपास करना संभव है।

ATO on web page redirecting based on open redirect to referrer

यह ब्लॉगपोस्ट बताता है कि कैसे एक ओपन रीडायरेक्ट का दुरुपयोग करके रेफरर के मान से OAuth का दुरुपयोग करके ATO किया जा सकता है। हमला इस प्रकार था:

1. पीड़ित हमलावर के वेब पृष्ठ पर पहुंचता है
2. पीड़ित दुर्भावनापूर्ण लिंक खोलता है और एक ओपनर Google OAuth प्रवाह को response_type=id_token,code&prompt=none के रूप में अतिरिक्त पैरामीटर के साथ शुरू करता है, रेफरर के रूप में हमलावर की वेबसाइट का उपयोग करते हुए।
3. ओपनर में, जब प्रदाता पीड़ित को अधिकृत करता है, तो यह उन्हें redirect_uri पैरामीटर (पीड़ित वेब) के मान पर वापस भेजता है जिसमें 30X कोड होता है जो अभी भी हमलावर की वेबसाइट को रेफरर में रखता है।
4. पीड़ित वेबसाइट रेफरर के आधार पर ओपन रीडायरेक्ट को ट्रिगर करती है जो पीड़ित उपयोगकर्ता को हमलावर की वेबसाइट पर रीडायरेक्ट करती है, क्योंकि respose_type id_token,code था, कोड हमलावर को URL के फ़्रैगमेंट में वापस भेजा जाएगा जिससे वह पीड़ित की साइट पर Google के माध्यम से उपयोगकर्ता के खाते पर नियंत्रण प्राप्त कर सके।

SSRFs parameters

इस शोध की जांच करें इस तकनीक के आगे के विवरण के लिए।

OAuth में डायनामिक क्लाइंट रजिस्ट्रेशन सुरक्षा कमजोरियों के लिए एक कम स्पष्ट लेकिन महत्वपूर्ण वेक्टर के रूप में कार्य करता है, विशेष रूप से सर्वर-साइड अनुरोध धोखाधड़ी (SSRF) हमलों के लिए। यह एंडपॉइंट OAuth सर्वरों को क्लाइंट ऐप्लिकेशनों के बारे में विवरण प्राप्त करने की अनुमति देता है, जिसमें संवेदनशील URLs शामिल हैं जिन्हें शोषित किया जा सकता है।

मुख्य बिंदु:

• डायनामिक क्लाइंट रजिस्ट्रेशन अक्सर /register पर मैप किया जाता है और इसमें client_name, client_secret, redirect_uris, और लोगो या JSON वेब कुंजी सेट (JWKs) के लिए URLs जैसे विवरण POST अनुरोधों के माध्यम से स्वीकार करता है।
• यह सुविधा RFC7591 और OpenID कनेक्ट रजिस्ट्रेशन 1.0 में निर्धारित विनिर्देशों का पालन करती है, जिसमें पैरामीटर शामिल हैं जो SSRF के लिए संभावित रूप से कमजोर हो सकते हैं।
• रजिस्ट्रेशन प्रक्रिया अनजाने में कई तरीकों से सर्वरों को SSRF के लिए उजागर कर सकती है:
• logo_uri: क्लाइंट ऐप्लिकेशन के लोगो के लिए एक URL जिसे सर्वर द्वारा प्राप्त किया जा सकता है, SSRF को ट्रिगर कर सकता है या यदि URL को गलत तरीके से संभाला गया तो XSS का कारण बन सकता है।
• jwks_uri: क्लाइंट के JWK दस्तावेज़ के लिए एक URL, जिसे यदि दुर्भावनापूर्ण तरीके से तैयार किया गया हो, तो सर्वर को हमलावर-नियंत्रित सर्वर पर आउटबाउंड अनुरोध करने के लिए मजबूर कर सकता है।
• sector_identifier_uri: redirect_uris के JSON एरे को संदर्भित करता है, जिसे सर्वर द्वारा प्राप्त किया जा सकता है, जिससे SSRF का अवसर उत्पन्न होता है।
• request_uris: क्लाइंट के लिए अनुमत अनुरोध URIs की सूची, जिन्हें यदि सर्वर इन URIs को प्राधिकरण प्रक्रिया की शुरुआत में प्राप्त करता है तो शोषित किया जा सकता है।

शोषण रणनीति:

• SSRF को logo_uri, jwks_uri, या sector_identifier_uri जैसे पैरामीटर में दुर्भावनापूर्ण URLs के साथ नए क्लाइंट को पंजीकृत करके ट्रिगर किया जा सकता है।
• जबकि request_uris के माध्यम से सीधे शोषण को व्हाइटलिस्ट नियंत्रणों द्वारा कम किया जा सकता है, एक पूर्व-पंजीकृत, हमलावर-नियंत्रित request_uri प्रदान करना प्राधिकरण चरण के दौरान SSRF को सुविधाजनक बना सकता है।

OAuth providers Race Conditions

यदि आप जिस प्लेटफॉर्म का परीक्षण कर रहे हैं वह एक OAuth प्रदाता है संभावित रेस कंडीशंस के लिए इसे पढ़ें.

Mutable Claims Attack

OAuth में, सब फ़ील्ड एक उपयोगकर्ता की अद्वितीय पहचान करता है, लेकिन इसका प्रारूप प्राधिकरण सर्वर द्वारा भिन्न होता है। उपयोगकर्ता पहचान को मानकीकृत करने के लिए, कुछ क्लाइंट ईमेल या उपयोगकर्ता हैंडल का उपयोग करते हैं। हालाँकि, यह जोखिम भरा है क्योंकि:

• कुछ प्राधिकरण सर्वर यह सुनिश्चित नहीं करते हैं कि ये गुण (जैसे ईमेल) अपरिवर्तनीय रहें।
• कुछ कार्यान्वयनों में—जैसे "Microsoft के साथ लॉगिन"—क्लाइंट ईमेल फ़ील्ड पर निर्भर करता है, जो Entra ID में उपयोगकर्ता द्वारा नियंत्रित होता है और सत्यापित नहीं होता।
• एक हमलावर इसका लाभ उठाकर अपना Azure AD संगठन (जैसे, doyensectestorg) बना सकता है और इसका उपयोग Microsoft लॉगिन करने के लिए कर सकता है।
• भले ही ऑब्जेक्ट आईडी (जो सब में संग्रहीत होता है) अपरिवर्तनीय और सुरक्षित है, एक परिवर्तनीय ईमेल फ़ील्ड पर निर्भरता एक खाता अधिग्रहण को सक्षम कर सकती है (उदाहरण के लिए, victim@gmail.com जैसे खाते को हाईजैक करना)।

Client Confusion Attack

एक Client Confusion Attack में, एक ऐप्लिकेशन जो OAuth इम्प्लिसिट फ्लो का उपयोग करता है, यह सत्यापित करने में विफल रहता है कि अंतिम एक्सेस टोकन विशेष रूप से इसके अपने क्लाइंट आईडी के लिए उत्पन्न किया गया है। एक हमलावर एक सार्वजनिक वेबसाइट स्थापित करता है जो Google के OAuth इम्प्लिसिट फ्लो का उपयोग करती है, हजारों उपयोगकर्ताओं को लॉगिन करने के लिए धोखा देती है और इस प्रकार हमलावर की साइट के लिए अभिगम टोकन एकत्र करती है। यदि इन उपयोगकर्ताओं के पास किसी अन्य कमजोर वेबसाइट पर भी खाते हैं जो टोकन के क्लाइंट आईडी को मान्य नहीं करती है, तो हमलावर एकत्रित टोकनों का पुन: उपयोग करके पीड़ितों का अनुकरण कर सकता है और उनके खातों पर नियंत्रण प्राप्त कर सकता है।

Scope Upgrade Attack

Authorization Code Grant प्रकार उपयोगकर्ता डेटा को संप्रेषित करने के लिए सुरक्षित सर्वर-से-सर्वर संचार में शामिल होता है। हालाँकि, यदि Authorization Server एक्सेस टोकन अनुरोध में एक स्कोप पैरामीटर पर निहित विश्वास करता है (एक पैरामीटर जो RFC में परिभाषित नहीं है), तो एक दुर्भावनापूर्ण ऐप्लिकेशन एक उच्च स्कोप का अनुरोध करके प्राधिकरण कोड के विशेषाधिकारों को अपग्रेड कर सकता है। एक बार जब Access Token उत्पन्न हो जाता है, तो Resource Server को इसकी पुष्टि करनी चाहिए: JWT टोकनों के लिए, इसमें JWT हस्ताक्षर की जांच करना और क्लाइंट_आईडी और स्कोप जैसे डेटा को निकालना शामिल है, जबकि यादृच्छिक स्ट्रिंग टोकनों के लिए, सर्वर को टोकन के विवरण प्राप्त करने के लिए Authorization Server से पूछताछ करनी चाहिए।

Redirect Scheme Hijacking

मोबाइल OAuth कार्यान्वयनों में, ऐप्स कस्टम URI स्कीम का उपयोग करते हैं ताकि प्राधिकरण कोड के साथ रीडायरेक्ट प्राप्त किया जा सके। हालाँकि, क्योंकि कई ऐप्स एक डिवाइस पर समान स्कीम को पंजीकृत कर सकते हैं, यह धारणा कि केवल वैध क्लाइंट रीडायरेक्ट URI को नियंत्रित करता है, का उल्लंघन होता है। उदाहरण के लिए, Android पर, एक Intent URI जैसे com.example.app:// oauth स्कीम और ऐप के intent-filter में परिभाषित वैकल्पिक फ़िल्टर के आधार पर पकड़ा जाता है। चूंकि Android का इरादा समाधान व्यापक हो सकता है—विशेष रूप से यदि केवल स्कीम निर्दिष्ट की गई हो—तो एक हमलावर एक दुर्भावनापूर्ण ऐप को एक सावधानीपूर्वक तैयार किए गए इरादे के फ़िल्टर के साथ पंजीकृत कर सकता है ताकि प्राधिकरण कोड को हाईजैक किया जा सके। यह खाता अधिग्रहण को सक्षम कर सकता है या तो उपयोगकर्ता इंटरैक्शन के माध्यम से (जब कई ऐप इरादे को संभालने के लिए पात्र होते हैं) या बायपास तकनीकों के माध्यम से जो अत्यधिक विशिष्ट फ़िल्टरों का शोषण करती हैं, जैसा कि Ostorlab के मूल्यांकन फ्लोचार्ट में विस्तृत किया गया है।

References

• https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1
• https://portswigger.net/research/hidden-oauth-attack-vectors
• https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html