hacktricks/pentesting-web/oauth-to-account-takeover.md

OAuth से Account takeover

AWS हैकिंग सीखें शून्य से लेकर हीरो तक htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks का समर्थन करने के अन्य तरीके:

• यदि आप चाहते हैं कि आपकी कंपनी का विज्ञापन HackTricks में दिखाई दे या HackTricks को PDF में डाउनलोड करें, तो सब्सक्रिप्शन प्लान्स देखें!
• आधिकारिक PEASS & HackTricks स्वैग प्राप्त करें
• The PEASS Family की खोज करें, हमारा विशेष NFTs संग्रह
• 💬 Discord group में शामिल हों या telegram group में या Twitter पर 🐦 @carlospolopm को फॉलो करें.
• HackTricks के github repos और HackTricks Cloud में PRs सबमिट करके अपनी हैकिंग ट्रिक्स साझा करें।

मूल जानकारी

OAuth के कुछ अलग-अलग संस्करण हैं, आप https://oauth.net/2/ पर जाकर बुनियादी समझ प्राप्त कर सकते हैं।

इस लेख में, हम आज आपको जो सबसे आम प्रवाह मिलेगा, उस पर ध्यान केंद्रित करेंगे, जो है OAuth 2.0 authorization code grant type। मूल रूप से, OAuth डेवलपर्स को एक अधिकृत मेकेनिज्म प्रदान करता है जो एक एप्लिकेशन को आपके खाते के खिलाफ डेटा एक्सेस करने या कुछ क्रियाएं करने की अनुमति देता है, दूसरे एप्लिकेशन से (अधिकृत सर्वर)।

उदाहरण के लिए, मान लीजिए वेबसाइट https://yourtweetreader.com में कार्यक्षमता है आपके द्वारा भेजे गए सभी ट्वीट्स को प्रदर्शित करने की, निजी ट्वीट्स सहित। इसे करने के लिए, OAuth 2.0 का परिचय दिया गया है। https://yourtweetreader.com आपसे उनके Twitter एप्लिकेशन को आपके सभी Tweets तक पहुंचने की अनुमति देने के लिए कहेगा। एक सहमति पृष्ठ https://twitter.com पर पॉप अप होगा जो दिखाएगा कि कौन सी अनुमतियां मांगी जा रही हैं, और विकासकर्ता कौन है जो इसे मांग रहा है। एक बार जब आप अनुरोध को अधिकृत कर देते हैं, https://yourtweetreader.com आपकी ओर से आपके Tweets तक पहुंचने में सक्षम हो जाएगा।

OAuth 2.0 संदर्भ में समझने के लिए महत्वपूर्ण तत्व:

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

वास्तविक उदाहरण

इस सब को एक साथ रखते हुए, यहाँ एक वास्तविक OAuth प्रवाह कैसा दिखता है:

1. आप https://yourtweetreader.com पर जाते हैं और "Integrate with Twitter" बटन पर क्लिक करते हैं।
2. https://yourtweetreader.com https://twitter.com को एक अनुरोध भेजता है जिसमें आपसे, संसाधन मालिक से, अनुमति मांगी जाती है कि आप https://yourtweetreader.com के Twitter एप्लिकेशन को आपके Tweets तक पहुंचने दें। अनुरोध इस तरह दिखेगा:

https://twitter.com/auth
?response_type=code
&client_id=yourtweetreader_clientId
&redirect_uri=https%3A%2F%2Fyourtweetreader.com%2Fcallback
&scope=readTweets
&state=kasodk9d1jd992k9klaskdh123

3. आपको एक सहमति पृष्ठ दिखाई देगा:

4. स्वीकार करने के बाद, Twitter redirect_uri पर code और state पैरामीटर्स के साथ एक अनुरोध वापस भेजेगा:

https://yourtweetreader.com?code=asd91j3jd91j92j1j9d1&state=kasodk9d1jd992k9klaskdh123

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

POST /oauth/access_token
Host: twitter.com
...{"client_id": "yourtweetreader_clientId", "client_secret": "yourtweetreader_clientSecret", "code": "asd91j3jd91j92j1j9d1", "grant_type": "authorization_code"}

6. अंत में, प्रक्रिया पूरी हो जाती है और https://yourtweetreader.com आपके access_token के साथ Twitter को API कॉल करेगा ताकि आपके Tweets तक पहुँच सके।

बग बाउंटी निष्कर्ष

अब, दिलचस्प हिस्सा! OAuth कार्यान्वयन में कई चीजें गलत हो सकती हैं, यहाँ अलग-अलग श्रेणियों के बग्स हैं जो मैं अक्सर देखता हूँ:

कमजोर redirect_uri कॉन्फ़िगरेशन

redirect_uri बहुत महत्वपूर्ण है क्योंकि संवेदनशील डेटा, जैसे कि code इस URL में अधिकृत होने के बाद जोड़ा जाता है। यदि redirect_uri को हमलावर नियंत्रित सर्वर पर पुनर्निर्देशित किया जा सकता है, इसका मतलब है कि हमलावर संभावित रूप से पीड़ित के खाते को अपने नियंत्रण में ले सकता है code का उपयोग करके, और पीड़ित के डेटा तक पहुँच प्राप्त कर सकता है।

इसका शोषण कैसे किया जाएगा यह प्राधिकरण सर्वर द्वारा भिन्न होगा। कुछ केवल वही redirect_uri पथ स्वीकार करेंगे जो क्लाइंट एप्लिकेशन में निर्दिष्ट है, लेकिन कुछ किसी भी चीज़ को स्वीकार करेंगे जो redirect_uri के एक ही डोमेन या उपनिर्देशिका में हो।

सर्वर द्वारा संभाले गए तर्क के आधार पर, redirect_uri को बायपास करने के लिए कई तकनीकें हैं। जब redirect_uri https://yourtweetreader.com/callback हो, तो इनमें शामिल हैं:

• ओपन रीडायरेक्ट्स: https://yourtweetreader.com/callback?redirectUrl=https://evil.com
• पथ ट्रैवर्सल: https://yourtweetreader.com/callback/../redirect?url=https://evil.com
• कमजोर redirect_uri regexes: https://yourtweetreader.com.evil.com
• HTML इंजेक्शन और रेफरर हेडर के माध्यम से टोकन चुराना: https://yourtweetreader.com/callback/home/attackerimg.jpg

अन्य पैरामीटर जो ओपन रीडायरेक्ट्स के लिए संवेदनशील हो सकते हैं:

• client_uri - क्लाइंट एप्लिकेशन के होम पेज का URL
• policy_uri - URL जो भरोसेमंद पार्टी क्लाइंट एप्लिकेशन प्रदान करता है ताकि अंतिम उपयोगकर्ता यह पढ़ सके कि उनके प्रोफ़ाइल डेटा का उपयोग कैसे किया जाएगा।
• tos_uri - URL जो भरोसेमंद पार्टी क्लाइंट प्रदान करता है ताकि अंतिम उपयोगकर्ता भरोसेमंद पार्टी की सेवा की शर्तों के बारे में पढ़ सके।
• initiate_login_uri - URI जिसका उपयोग https स्कीम के साथ एक तृतीय पक्ष RP द्वारा लॉगिन शुरू करने के लिए किया जा सकता है। यह क्लाइंट-साइड रीडायरेक्शन के लिए भी उपयोग किया जाना चाहिए।

ये सभी पैरामीटर OAuth और OpenID विनिर्देशों के अनुसार वैकल्पिक हैं और हमेशा एक विशेष सर्वर पर समर्थित नहीं होते हैं, इसलिए यह हमेशा जांचने लायक है कि आपके सर्वर पर कौन से पैरामीटर समर्थित हैं।

यदि आप OpenID सर्वर को लक्षित करते हैं, तो **.well-known/openid-configuration** पर खोज एंडपॉइंट कभी-कभी पैरामीटर जैसे "registration_endpoint", "request_uri_parameter_supported", और "require_request_uri_registration" को समाविष्ट करता है। ये आपको पंजीकरण एंडपॉइंट और अन्य सर्वर कॉन्फ़िगरेशन मानों को खोजने में मदद कर सकते हैं।

redirect कार्यान्वयन में XSS

जैसा कि इस बग बाउंटी रिपोर्ट 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 - स्टेट पैरामीटर का अनुचित संभाल

अक्सर, state पैरामीटर को पूरी तरह से छोड़ दिया जाता है या गलत तरीके से इस्तेमाल किया जाता है। यदि स्टेट पैरामीटर अनुपस्थित है, या एक स्थिर मूल्य है जो कभी नहीं बदलता, तो OAuth प्रवाह बहुत संभावना से CSRF के लिए संवेदनशील होगा। कभी-कभी, यहां तक कि अगर एक state पैरामीटर है, तो एप्लिकेशन पैरामीटर का कोई मान्यता नहीं कर सकता और एक हमला काम करेगा। इसका शोषण करने का तरीका यह होगा कि आप अपने खाते पर प्राधिकरण प्रक्रिया से गुजरें, और प्राधिकरण के ठीक बाद रुकें। तब आपको इस तरह का अनुरोध मिलेगा:

https://yourtweetreader.com?code=asd91j3jd91j92j1j9d1

इस अनुरोध को प्राप्त करने के बाद, आप अनुरोध को छोड़ सकते हैं क्योंकि ये कोड आमतौर पर एक बार के उपयोग के लिए होते हैं। फिर आप इस URL को एक लॉग-इन उपयोगकर्ता को भेज सकते हैं, और यह आपके खाते को उनके खाते में जोड़ देगा। पहली नजर में, यह बहुत संवेदनशील नहीं लग सकता है क्योंकि आप केवल अपने खाते को एक पीड़ित के खाते में जोड़ रहे हैं। हालांकि, कई OAuth कार्यान्वयन साइन-इन उद्देश्यों के लिए होते हैं, इसलिए यदि आप अपने Google खाते को जोड़ सकते हैं जिसका उपयोग लॉगिन के लिए किया जाता है, तो आप एक क्लिक के साथ Account Takeover कर सकते हैं क्योंकि अपने Google खाते से लॉगिन करने से आपको पीड़ित के खाते तक पहुंच मिल जाएगी।

इसके बारे में एक उदाहरण आप इस CTF writeup में और HTB box called Oouch में देख सकते हैं।

मैंने कई बार state पैरामीटर को एक अतिरिक्त रीडायरेक्ट मूल्य के रूप में इस्तेमाल होते देखा है। एप्लिकेशन प्रारंभिक रीडायरेक्ट के लिए redirect_uri का उपयोग करेगा, लेकिन फिर state पैरामीटर को दूसरे रीडायरेक्ट के रूप में इस्तेमाल करेगा जिसमें क्वेरी पैरामीटर्स के भीतर code हो सकता है, या referer header।

एक महत्वपूर्ण बात यह है कि यह केवल लॉगिन और खाता अधिग्रहण प्रकार की स्थितियों पर लागू नहीं होता है। मैंने मिसकॉन्फिगरेशन देखे हैं:

• Slack इंटीग्रेशन जो एक हमलावर को उनके Slack खाते को सभी नोटिफिकेशन/संदेशों के प्राप्तकर्ता के रूप में जोड़ने की अनुमति देते हैं
• Stripe इंटीग्रेशन जो एक हमलावर को भुगतान जानकारी को ओवरराइट करने और पीड़ित के ग्राहकों से भुगतान स्वीकार करने की अनुमति देते हैं
• PayPal इंटीग्रेशन जो एक हमलावर को उनके PayPal खाते को पीड़ित के खाते में जोड़ने की अनुमति देते हैं, जिससे पैसा हमलावर के PayPal में जमा होगा

Pre Account Takeover

एक अन्य आम समस्या जो मैं देखता हूं वह है जब एप्लिकेशन "Sign in with X" की अनुमति देते हैं लेकिन यूजरनेम/पासवर्ड भी। इस पर हमला करने के दो अलग-अलग तरीके हैं:

1. यदि एप्लिकेशन खाता निर्माण पर ईमेल सत्यापन की आवश्यकता नहीं रखता है, तो पीड़ित के ईमेल पते और हमलावर के पासवर्ड के साथ एक खाता बनाने का प्रयास करें इससे पहले कि पीड़ित ने पंजीकृत किया हो। यदि पीड़ित फिर पंजीकरण करने का प्रयास करता है या तृतीय पक्ष के साथ साइन इन करता है, जैसे कि Google, तो संभव है कि एप्लिकेशन एक लुकअप करेगा, देखेगा कि ईमेल पहले से पंजीकृत है, फिर उनके Google खाते को हमलावर द्वारा बनाए गए खाते से जोड़ देगा। यह एक "pre account takeover" है जहां एक हमलावर के पास पीड़ित के खाते तक पहुंच होगी यदि उन्होंने पीड़ित के पंजीकरण से पहले इसे बनाया हो।
2. यदि कोई OAuth ऐप ईमेल सत्यापन की आवश्यकता नहीं रखता है, तो उस OAuth ऐप के साथ साइन अप करने का प्रयास करें और फिर ईमेल पते को पीड़ित के ईमेल पते के साथ बदलें। ऊपर वर्णित समस्या वही हो सकती है, लेकिन आप इसे दूसरी दिशा से हमला कर रहे होंगे और खाता अधिग्रहण के लिए पीड़ित के खाते तक पहुंच प्राप्त करेंगे।

Disclosure of Secrets

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

5. https://yourtweetreader.com फिर उस code को लेगा, और उनके एप्लिकेशन के client_id और client_secret का उपयोग करके, आपकी ओर से एक access_token प्राप्त करने के लिए सर्वर से एक अनुरोध करेगा, जो उन्हें आपकी सहमति दी गई अनुमतियों तक पहुंचने की अनुमति देगा।

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

Client Secret Bruteforce

आप किसी सेवा प्रदाता के client_secret को bruteforce करने का प्रयास कर सकते हैं ताकि खातों को चुराने का प्रयास किया जा सके।
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 में Code + State का लीक होना

एक बार जब क्लाइंट के पास code और state होते हैं, अगर यह Referer header में प्रतिबिंबित होता है जब वह एक अलग पेज पर जाता है, तो यह संवेदनशील है।

ब्राउज़र हिस्ट्री में Access Token का संग्रहण

ब्राउज़र हिस्ट्री में जाएं और जांचें कि क्या access token वहां संग्रहीत है।

स्थायी Authorization Code

Authorization code को केवल कुछ समय के लिए जीवित रहना चाहिए ताकि हमलावर द्वारा इसे चुराने और उपयोग करने की समय सीमा सीमित रहे।

Authorization/Refresh Token क्लाइंट से नहीं जुड़ा हुआ

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

Happy Paths, XSS, Iframes & Post Messages का उपयोग करके code & state मानों का लीक होना

AWS Cognito

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

# 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"
}
]
}

AWS cognito का दुरुपयोग करने के बारे में अधिक विस्तृत जानकारी के लिए देखें:

{% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %}

अन्य ऐप्स के टोकन का दुरुपयोग

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

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

{% hint style="danger" %} इसलिए, यदि हमलावर यूजर को अपने OAuth ऐप्लिकेशन तक पहुंचने का प्रबंधन करता है, तो वह उन ऐप्लिकेशनों के पीड़ित के खाते पर कब्जा करने में सक्षम होगा जो एक टोकन की अपेक्षा करते हैं और यह जांच नहीं करते हैं कि टोकन उनके ऐप ID को दिया गया था या नहीं। {% endhint %}

दो लिंक्स और कुकी

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

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

SSRFs पैरामीटर्स

एक छिपा हुआ URL जिसे आप याद कर सकते हैं वह है Dynamic Client Registration endpoint। यूजर्स को सफलतापूर्वक प्रमाणित करने के लिए, OAuth सर्वरों को क्लाइंट ऐप्लिकेशन के बारे में विवरण जानने की आवश्यकता होती है, जैसे "client_name", "client_secret", "redirect_uris", आदि। ये विवरण स्थानीय कॉन्फ़िगरेशन के माध्यम से प्रदान किए जा सकते हैं, लेकिन OAuth प्राधिकरण सर्वरों के पास एक विशेष पंजीकरण एंडपॉइंट भी हो सकता है। यह एंडपॉइंट सामान्यतः "/register" पर मैप किया जाता है और निम्नलिखित प्रारूप के साथ POST अनुरोध स्वीकार करता है:

POST /connect/register HTTP/1.1
Content-Type: application/json
Host: server.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ...

{
"application_type": "web",
"redirect_uris": ["https://client.example.org/callback"],
"client_name": "My Example",
"logo_uri": "https://client.example.org/logo.png",
"subject_type": "pairwise",
"sector_identifier_uri": "https://example.org/rdrct_uris.json",
"token_endpoint_auth_method": "client_secret_basic",
"jwks_uri": "https://client.example.org/public_keys.jwks",
"contacts": ["ve7jtb@example.org"],
"request_uris": ["https://client.example.org/rf.txt"]
}

इस अनुरोध में पैरामीटर्स को परिभाषित करने वाले दो विनिर्देश हैं: OAuth के लिए RFC7591 और Openid Connect Registration 1.0.

जैसा कि आप यहाँ देख सकते हैं, इन मूल्यों में से कई URL संदर्भों के माध्यम से पास किए जाते हैं और Server Side Request Forgery के लिए संभावित लक्ष्य की तरह दिखते हैं। साथ ही, हमने जिन अधिकांश सर्वरों का परीक्षण किया है, वे इन URL को पंजीकरण अनुरोध प्राप्त होने पर तुरंत हल नहीं करते हैं। इसके बजाय, वे बस इन पैरामीटर्स को सहेजते हैं और उन्हें OAuth प्राधिकरण प्रवाह के दौरान बाद में उपयोग करते हैं। दूसरे शब्दों में, यह एक दूसरे-क्रम का SSRF अधिक है, जो कि ब्लैक-बॉक्स पता लगाने को कठिन बनाता है।

निम्नलिखित पैरामीटर्स SSRF हमलों के लिए विशेष रूप से दिलचस्प हैं:

• logo_uri - URL जो क्लाइंट एप्लिकेशन के लोगो का संदर्भ देता है। क्लाइंट पंजीकृत करने के बाद, आप अपने नए "client_id" का उपयोग करके OAuth प्राधिकरण एंडपॉइंट ("/authorize") को कॉल करने का प्रयास कर सकते हैं। लॉगिन के बाद, सर्वर आपसे अनुरोध को मंजूरी देने के लिए कहेगा और "logo_uri" से छवि प्रदर्शित कर सकता है। यदि सर्वर स्वयं छवि को प्राप्त करता है, तो इस चरण से SSRF ट्रिगर होना चाहिए। वैकल्पिक रूप से, सर्वर केवल क्लाइंट-साइड "<img>" टैग के माध्यम से लोगो को शामिल कर सकता है। हालांकि यह SSRF की ओर नहीं ले जाता है, यह XSS की ओर ले जा सकता है यदि URL बच नहीं है।
• jwks_uri - क्लाइंट के JSON Web Key Set [JWK] दस्तावेज़ के लिए URL। जब JWTs का उपयोग करके क्लाइंट प्रमाणीकरण के लिए हस्ताक्षरित अनुरोधों को मान्य करने के लिए इस की सेट की सर्वर पर आवश्यकता होती है [RFC7523]। इस पैरामीटर में SSRF के लिए परीक्षण करने के लिए, एक दुर्भावनापूर्ण "jwks_uri" के साथ एक नया क्लाइंट एप्लिकेशन पंजीकृत करें, प्राधिकरण प्रक्रिया को पूरा करें ताकि किसी भी उपयोगकर्ता के लिए एक प्राधिकरण कोड प्राप्त किया जा सके, और फिर निम्नलिखित बॉडी के साथ "/token" एंडपॉइंट को प्राप्त करें:

POST /oauth/token HTTP/1.1
...
``
grant_type=authorization_code&code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&client_assertion=eyJhbGci...

यदि संवेदनशील है, तो सर्वर को आपके द्वारा प्रदान किए गए "jwks_uri" के लिए सर्वर-से-सर्वर HTTP अनुरोध करना चाहिए क्योंकि इसे आपके अनुरोध में "client_assertion" पैरामीटर की वैधता की जांच करने के लिए इस की की आवश्यकता होती है। यह शायद केवल एक अंधा SSRF संवेदनशीलता होगी, क्योंकि सर्वर एक उचित JSON प्रतिक्रिया की अपेक्षा करता है।

• sector_identifier_uri - यह URL एक फ़ाइल का संदर्भ देता है जिसमें एकल JSON ऐरे ऑफ़ redirect_uri मूल्य होते हैं। यदि समर्थित है, तो सर्वर आपके द्वारा गतिशील पंजीकरण अनुरोध सबमिट करते ही इस मूल्य को प्राप्त कर सकता है। यदि यह तुरंत प्राप्त नहीं किया जाता है, तो सर्वर पर इस क्लाइंट के लिए प्राधिकरण करने का प्रयास करें। चूंकि इसे प्राधिकरण प्रवाह को पूरा करने के लिए redirect_uris को जानने की आवश्यकता होती है, इससे सर्वर को आपके दुर्भावनापूर्ण sector_identifier_uri के लिए अनुरोध करने के लिए मजबूर किया जाएगा।
• request_uris - इस क्लाइंट के लिए अनुमत request_uris का एक ऐरे। "request_uri" पैरामीटर को प्राधिकरण एंडपॉइंट पर समर्थित किया जा सकता है ताकि अनुरोध जानकारी के साथ JWT युक्त URL प्रदान किया जा सके (देखें https://openid.net/specs/openid-connect-core-1_0.html#rfc.section.6.2)।

यदि गतिशील क्लाइंट पंजीकरण सक्षम नहीं है, या इसके लिए प्रमाणीकरण की आवश्यकता है, हम "request_uri" का उपयोग करके प्राधिकरण एंडपॉइंट पर SSRF का प्रदर्शन करने का प्रयास कर सकते हैं:\

GET /authorize?response_type=code%20id_token&client_id=sclient1&request_uri=https://ybd1rc7ylpbqzygoahtjh6v0frlh96.burpcollaborator.net/request.jwt

नोट: इस पैरामीटर को "redirect_uri" के साथ भ्रमित न करें। "redirect_uri" का उपयोग प्राधिकरण के बाद पुनर्निर्देशन के लिए किया जाता है, जबकि "request_uri" को सर्वर द्वारा प्राधिकरण प्रक्रिया की शुरुआत में प्राप्त किया जाता है।

साथ ही, हमने जिन कई सर्वरों को देखा है, वे मनमाने "request_uri" मूल्यों की अनुमति नहीं देते हैं: वे केवल सफेद सूची में डाले गए URL की अनुमति देते हैं जो क्लाइंट पंजीकरण प्रक्रिया के दौरान पहले से पंजीकृत किए गए थे। इसलिए हमें पहले "request_uris": "https://ybd1rc7ylpbqzygoahtjh6v0frlh96.burpcollaborator.net/request.jwt" प्रदान करने की आवश्यकता है।

OAuth प्रदाता रेस कंडीशन्स

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

संदर्भ

• https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1
• https://portswigger.net/research/hidden-oauth-attack-vectors

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!

HackTricks का समर्थन करने के अन्य तरीके:

• यदि आप अपनी कंपनी को HackTricks में विज्ञापित देखना चाहते हैं या HackTricks को PDF में डाउनलोड करना चाहते हैं तो सदस्यता योजनाएं देखें!
• आधिकारिक PEASS & HackTricks स्वैग प्राप्त करें
• The PEASS Family की खोज करें, हमारा संग्रह विशेष NFTs
• 💬 Discord समूह में शामिल हों या telegram समूह या Twitter पर मुझे 🐦 @carlospolopm** का पालन करें**।
• HackTricks के लिए PRs सबमिट करके अपनी हैकिंग ट्रिक्स साझा करें [HackTricks](https://github.com/carlosp