* क्या आप किसी **साइबर सुरक्षा कंपनी** में काम करते हैं? क्या आप अपनी कंपनी को **HackTricks में विज्ञापित** देखना चाहते हैं? या क्या आपको **PEASS की नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने का उपयोग** करना चाहिए? [**सदस्यता योजनाएं**](https://github.com/sponsors/carlospolop) की जांच करें!
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारा संग्रह विशेष [**NFTs**](https://opensea.io/collection/the-peass-family)
* [**आधिकारिक PEASS & HackTricks swag**](https://peass.creator-spring.com) प्राप्त करें
* [**💬**](https://emojipedia.org/speech-balloon/) [**Discord समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) में **शामिल हों** या मुझे **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)** का पालन करें**.
इस लेख में, हम उस सबसे सामान्य प्रवाह पर ध्यान केंद्रित करेंगे जिसका आप आजकल सामना करेंगे, जो है [OAuth 2.0 अधिकृती कोड ग्रांट प्रकार](https://oauth.net/2/grant-types/authorization-code/)। सारांश में, OAuth डेवलपर्स को एक **अधिकृती तंत्र प्रदान करता है जो किसी अन्य एप्लिकेशन** (अधिकृती सर्वर) से आपके खाते के खिलाफ डेटा तक पहुंच या कुछ कार्रवाई करने की अनुमति देता है।
उदाहरण के लिए, मान लें वेबसाइट _**https://yourtweetreader.com**_ में विशेषता है **आपके द्वारा कभी भी भेजे गए सभी ट्वीट्स को प्रदर्शित करना**, इसमें निजी ट्वीट्स भी शामिल हैं। इसके लिए, OAuth 2.0 का प्रयोग किया जाता है। _https://yourtweetreader.com_ आपसे कहेगा कि **उनके ट्विटर एप्लिकेशन को आपके सभी ट्वीट्स तक पहुंचने की अनुमति दें**। एक सहमति पृष्ठ _https://twitter.com_ पर उभरेगा जिसमें बताया जाएगा कि **कौन सी अनुमतियां मांगी जा रही हैं**, और उसका अनुरोध करने वाला डेवलपर कौन है। एक बार जब आप अनुमति देते हैं, _https://yourtweetreader.com_ आपके ट्वीट्स तक पहुंच सकेगा।
* **संसाधन मालिक**: `संसाधन मालिक` वह **उपयोगकर्ता/संगठन** है जो अपने संरक्षित संसाधन, जैसे उनके ट्विटर खाते के ट्वीट्स, के लिए पहुंच प्रदान करता है। इस उदाहरण में, यह आप होंगे।
* **संसाधन सर्वर**: `संसाधन सर्वर` एक **प्रमाणित अनुरोधों को संभालने वाला सर्वर** है जो एप्लिकेशन ने `संसाधन मालिक` के लिए `पहुंच टोकन` प्राप्त करने के बाद प्राथमिकता देता है। इस उदाहरण में, यह होगा **https://twitter.com**
* **क्लाइंट एप्लिकेशन**: `क्लाइंट एप्लिकेशन` एक **अनुमति का अनुरोध करने वाला एप्लिकेशन** है जो `संसाधन मालिक` से अनुमति मांगता है। इस उदाहरण में, यह होगा **https://yourtweetreader.com**।
* **अधिकृती सर्वर**: `अधिकृती सर्वर` एक **सर्वर है जो `संसाधन मालिक` की पहुंच को सफलतापूर्वक प्रमाणित करने के बाद `पहुंच टोकन` जारी करता है**`क्लाइंट एप्लिकेशन` को। उपरोक्त उदाहरण में, यह होगा **https://twitter.com**
* **client\_id**: `client_id` एक **एप्लिकेशन के लिए पहचानकर्ता**
5\. [https://yourtweetreader.com](https://yourtweetreader.com) फिर उस `code` को लेगी, और अपने एप्लिकेशन के `client_id` और `client_secret` का उपयोग करके, आपकी ओर से सर्वर से एक `access_token` प्राप्त करने के लिए एक अनुरोध करेगी, जिससे उन्हें आपकी सहमति प्राप्त की गई अनुमतियों तक पहुंच मिलेगी:
6\. अंत में, प्रवाह पूर्ण हो जाता है और [https://yourtweetreader.com](https://yourtweetreader.com) आपके `access_token` के साथ ट्विटर को API कॉल करेगा ताकि आपके ट्वीट्स तक पहुंच सकें।
`redirect_uri` बहुत महत्वपूर्ण है क्योंकि अधिकृति के बाद इस URL के बाद **संवेदनशील डेटा, जैसे कोड, जोड़ा जाता है**। यदि `redirect_uri` किसी **हमलावर्धक नियंत्रित सर्वर** पर पुनर्निर्देशित किया जा सकता है, तो इसका अर्थ है कि हमलावर `कोड` का उपयोग करके **पीड़ित के खाते को अधिकार में ले सकता है** और पीड़ित के डेटा तक पहुंच सकता है।
इसे उत्पन्न करने का तरीका अधिकृति सर्वर द्वारा भिन्न होगा। **कुछ** केवल उसी निर्दिष्ट **`redirect_uri` पथ को स्वीकार करेंगे** लेकिन कुछ ऐसा करेंगे **जो भी**`redirect_uri` के डोमेन या उपनिर्देशिका में होगा, उसे स्वीकार करेंगे।
सर्वर द्वारा संभाले जाने वाले तर्क के आधार पर, `redirect_uri` को बाईपास करने के कई तकनीक हैं। एक स्थिति में जहां `redirect_uri` [https://yourtweetreader.com](https://yourtweetreader.com)/callback है, इनमें शामिल हैं:
* **client\_uri** - ग्राहक अनुप्रयोग के होम पेज का URL
* **policy\_uri** - रिलायिंग पार्टी ग्राहक अनुप्रयोग द्वारा प्रदान किया गया URL ताकि अंत उपयोगकर्ता अपने प्रोफ़ाइल डेटा के बारे में पढ़ सकें।
* **tos\_uri** - रिलायिंग पार्टी ग्राहक द्वारा प्रदान किया गया URL ताकि अंत उपयोगकर्ता रिलायिंग पार्टी की सेवा की शर्तों के बारे में पढ़ सकें।
* **initiate\_login\_uri** - एक तृतीय पक्ष द्वारा उपयोग किया जा सकने वाला https योजना का URI जिसका उपयोग RP द्वारा लॉगिन प्रारंभ करने के लिए किया जा सकता है। यह ग्राहक-साइड पुनर्निर्देशन के लिए उपयोग किया जाना चाहिए।
ये सभी पैरामीटर **OAuth और OpenID** निर्देशिकाओं के अनुसार **वैकल्पिक हैं** और हमेशा एक विशेष सर्वर पर समर्थित नहीं होते हैं, इसलिए यह हमेशा महत्वपूर्ण है कि आपके सर्वर पर कौन से पैरामीटर समर्थित हैं, उन्हें पहचानना।
यदि आप एक OpenID सर्वर को लक्ष्य बनाते हैं, तो डिस्कवरी अंतबिंदु पर \*\*`.well-known/openid-configuration`\*\* कुछ पैरामीटर शामिल हो सकते हैं जैसे "_registration\_endpoint_", "_request\_uri\_parameter\_supported_", और "_require\_request\_uri\_registration_"। ये आपको पंजीकरण अंतबिंदु और अन्य सर्वर कॉन्फ़िगरेशन मानों को खोजने में मदद कर सकते हैं।
जैसा कि इस बग बाउंटी रिपोर्ट [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html) में उल्लेख किया गया है, संभवतः रीडायरेक्ट **URL को सर्वर के प्रतिक्रिया में प्रतिबिंबित किया जा रहा है**, जो **XSS के लिए संवेदनशील** हो सकता है। परीक्षण के लिए संभावित पेलोड:
अक्सर, **`state` पैरामीटर पूरी तरह से छोड़ दिया जाता है या गलत तरीके से उपयोग किया जाता है**। यदि एक स्थिति पैरामीटर **अस्तित्वहीन होता है**, **या एक स्थिर मान** होता है जो कभी नहीं बदलता है, तो OAuth फ्लो बहुत संभावित रूप से **CSRF के लिए संकटग्रस्त होगा**। कभी-कभी, यदि `state` पैरामीटर होता है, तो **एप्लिकेशन शायद ही पैरामीटर का कोई मान्यता प्रमाणीकरण नहीं करेगा** और हमला काम करेगा। इसे उत्पन्न करने का तरीका यह होगा कि अपने खाते पर प्राधिकरण प्रक्रिया के माध्यम से जाएं और प्राधिकरण करने के बाद ठहरें। फिर आपको एक अनुरोध के साथ सामने आना होगा जैसे:
इस अनुरोध को प्राप्त करने के बाद, आप फिर इस अनुरोध को **छोड़ सकते हैं क्योंकि ये कोड आमतौर पर एक बार का उपयोग होते हैं**। फिर आप इस URL को एक **लॉग इन किए हुए उपयोगकर्ता को भेज सकते हैं और यह आपके खाते को उनके खाते में जोड़ देगा**। पहले इसे बहुत संवेदनशील नहीं लग सकता है क्योंकि आप बस अपने खाते को पीड़ित के खाते में जोड़ रहे हैं। हालांकि, कई OAuth कार्यान्वयन साइन-इन के उद्देश्य के लिए होते हैं, इसलिए यदि आप अपने Google खाते को जोड़ सकते हैं जो लॉग इन करने के लिए उपयोग किया जाता है, तो आप एकल क्लिक के साथ एक **खाता हासिल कर सकते हैं** क्योंकि अपने Google खाते से लॉग इन करने से आपको पीड़ित के खाते तक पहुंच मिल जाएगी।
इसके बारे में एक **उदाहरण** आप [**CTF writeup**](https://github.com/gr455/ctf-writeups/blob/master/hacktivity20/notes\_surfer.md) और **HTB बॉक्स ओउच** में देख सकते हैं।
मैंने कई बार देखा है कि राज्य पैरामीटर को एक अतिरिक्त पुनर्निर्देश मान माना जाता है। आवेदन `redirect_uri` का उपयोग प्राथमिक पुनर्निर्देश के लिए करेगा, लेकिन फिर `state` पैरामीटर को दूसरे पुनर्निर्देश के रूप में उपयोग करेगा जिसमें क्वेरी पैरामीटर में `code` हो सकता है, या रेफरर हेडर में हो सकता है।
मैं देखता हूं कि एप्लिकेशन्स "X के साथ साइन इन करें" की अनुमति देते हैं, लेकिन उपयोगकर्ता नाम / पासवर्ड भी होते हैं। इसे हमला करने के दो अलग-अलग तरीके हैं:
1. यदि एप्लिकेशन **खाता बनाने पर ईमेल सत्यापन की आवश्यकता नहीं है**, तो पहले ही पीड़ित के ईमेल पते और हमलावर्धक पासवर्ड के साथ एक खाता बनाने का प्रयास करें। यदि **पीड़ित** फिर तीसरे पक्ष जैसे Google के साथ **रजिस्टर करने या साइन इन करने का प्रयास करता है**, तो संभवतः एप्लिकेशन एक लुकअप करेगा, देखेगा कि ईमेल पहले से ही रजिस्टर है, और फिर **उनके Google खाते को हमलावर्धक द्वारा बनाए गए खाते से लिंक करेगा**। यह एक "पहले खाता हासिल करने" है जहां हमलावर्धक को पीड़ित के खाते तक पहुंच होगी यदि वह उसे पहले ही रजिस्टर कर देता है।
2. यदि **OAuth ऐप ईमेल सत्यापन की आवश्यकता नहीं है**, तो उस OAuth ऐप के साथ साइन अप करने की कोशिश करें और फिर ईमेल पते को **पीड़ित के ईमेल पते के साथ बदलें**। उपरोक्त की तरही समस्या हो सकती है, लेकिन आप इसे उलटी दिशा से हमला कर रहे होंगे और खाता हासिल करने के लिए पीड़ित के खाते में पहुंच प्राप्त कर रहे होंगे।
यह बहुत महत्वपूर्ण है कि आप पहचानें **कौन से OAuth पैरामीटर गोपनीय होते हैं**, और उन्हें सुरक्षित रखें। उदाहरण के लिए, `client_id` लीक करना पूरी तरह से ठीक और आवश्यक है, लेकिन **`client_secret` लीक होना खतरनाक होता है**। यदि यह लीक हो जाता है, तो **हमलावर्धक** संभवतः **विश्वसनीय ग्राहक ऐप्लिकेशन के विश्वसनीयता और पहुंच की पहचान चोरी करने के लिए विश्वसनीय ग्राहक ऐप्लिकेशन का दुरुपयोग कर सकता है**। हमारे पहले उदाहरण पर वापस जाते हैं, मैंने देखा है कि इस कदम को क्लाइंट से किया जाता है, सर्वर से नहीं:
_5._ [_https://yourtweetreader.com_](https://yourtweetreader.com) _फिर उस `code` को ले लेगा, और अपने ऐप्लिकेशन के `client_id` और `client_secret` का उपयोग करके आपके लिए एक `access_token` प्राप्त करने के लिए सर्वर से एक अनुरोध करेगा, जिससे उन्हें आपकी सहमति
जब क्लाइंट के पास **कोड और स्थिति** होती है, और यदि वह एक अलग पृष्ठ पर ब्राउज़ करते समय **Referer हेडर में प्रतिबिंबित होती है**, तो यह संकटपूर्ण हो सकता है।
इस बग बाउंटी रिपोर्ट में: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) आप देख सकते हैं कि **AWS Cognito** उपयोगकर्ता को वापस देता है, जिसमें **उपयोगकर्ता डेटा को ओवरराइट करने के लिए पर्याप्त अनुमतियाँ हो सकती हैं**। इसलिए, यदि आप **एक अलग उपयोगकर्ता ईमेल के लिए उपयोगकर्ता ईमेल बदल सकते हैं**, तो आप अन्य खातों को **अधिकार में ले सकते हैं**।
[**इस लेख**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f) के अनुसार, एक हमलावर्धी के होस्ट की ओर इशारा करने वाले **returnUrl** के साथ एक पेज को पीड़ित को खोलना संभव था। यह जानकारी **कुकी (RU)** में **संग्रहीत की जाएगी** और एक **बाद के चरण** में **प्रॉम्प्ट** पूछेगा कि क्या उपयोगकर्ता उस हमलावर्धी के होस्ट को पहुंच देना चाहता है।
इस प्रॉम्प्ट को अनदेखा करने के लिए, एक टैब खोलना संभव था जिससे **Oauth फ्लो** शुरू होगा और यह RU कुकी **returnUrl** का उपयोग करके सेट करेगा, प्रॉम्प्ट दिखाई नहीं देगा, और इसके बाद एक नया टैब खोलेगा जिसमें वह मान्यता नहीं होगी। फिर, **प्रॉम्प्ट हमलावर्धी के होस्ट के बारे में सूचित नहीं करेगा**, लेकिन कुकी उसे सेट कर देगी, इसलिए **टोकन हमलावर्धी के होस्ट पर भेजा जाएगा** पुनर्निर्देशन में।
आप एक **डायनेमिक क्लाइंट पंजीकरण अंत बिंदु** को छूने के लिए छिपे हुए URL में से एक हैं। उपयोगकर्ताओं को सफलतापूर्वक प्रमाणित करने के लिए, ओआथ सर्वरों को ग्राहक एप्लिकेशन के बारे में विवरण जानने की आवश्यकता होती है, जैसे "client\_name", "client\_secret", "redirect\_uris" आदि। ये विवरण स्थानीय विन्यास के माध्यम से प्रदान किए जा सकते हैं, लेकिन ओआथ अधिकृति सर्वरों के पास एक **विशेष पंजीकरण अंत बिंदु** भी हो सकता है। यह अंत बिंदु सामान्यतः "/register" के लिए मैप किया जाता है और निम्नलिखित प्रारूप के साथ POST अनुरोधों को स्वीकार करता है:
इस अनुरोध में पैरामीटरों को परिभाषित करने वाले दो विनिर्देश हैं: [RFC7591](https://tools.ietf.org/html/rfc7591) ओआथ के लिए और [Openid Connect Registration 1.0](https://openid.net/specs/openid-connect-registration-1\_0.html#rfc.section.3.1) के लिए।
जैसा कि आप यहां देख सकते हैं, कई मानों को URL संदर्भ के माध्यम से पास किया जाता है और ये [सर्वर साइड रिक्वेस्ट फॉर्जरी](https://portswigger.net/web-security/ssrf) के लिए संभावित लक्ष्य लगते हैं। इसी बीच, हमने जितने भी सर्वरों का परीक्षण किया है, उनमें से अधिकांश सर्वर इन URL को तुरंत नहीं संग्रहीत करते हैं जब उन्हें एक पंजीकरण अनुरोध प्राप्त होता है। बजाय इसके, वे बस इन पैरामीटरों को सहेजते हैं और उन्हें ओआथ अधिकृति प्रवाह के दौरान बाद में उपयोग करते हैं। दूसरे शब्दों में, यह दूसरे क्रम की एसएसआरएफ है, जिससे काले-बॉक्स का पता लगाना मुश्किल हो जाता है।
* **logo\_uri** - एक URL जो एक क्लाइंट एप्लिकेशन के लिए एक **लोगो को संदर्भित करता है**। **एक क्लाइंट को पंजीकृत करने के बाद**, आप अपने नए "client\_id" का उपयोग करके ओआथ अधिकृति अंत बिंदु ("/authorize") को कॉल करने का प्रयास कर सकते हैं। लॉगिन के बाद, सर्वर आपसे अनुरोध को मंजूरी देने के लिए पूछेगा और **"logo\_uri" से छवि प्रदर्शित कर सकता है**। यदि **सर्वर खुद छवि को फ़ेच करता है**, तो इस चरण द्वारा एसएसआरएफ ट्रिगर होना चाहिए। वैकल्पिक रूप से, सर्वर केवल एक **क्लाइंट-साइड "\<img>" टैग** के माध्यम से लोगो को शामिल कर सकता है। यदि URL नहीं भागा जाता है, तो यह एसएसआरएफ नहीं लेकिन **एक्सएसएस हो सकता है अगर URL नहीं भागा जाता है**।
***jwks\_uri** - क्लाइंट के JSON वेब कुंजी सेट \[JWK] दस्तावेज़ के लिए URL। यह कुंजी सेट सर्वर पर आवेदित JWT का वैधीकरण करने के लिए आवश्यक होता है जब JWT का उपयोग करके ग्राहक प्रमाणीकरण के लिए टोकन अंत बिंदु पर बनाए गए अनुरोध किया जाता है \[RFC7523]। इस पैरामीटर में एसएसआरएफ के लिए परीक्षण करने के लिए, **एक दुष्ट "jwks\_uri" के साथ एक नया क्लाइंट एप्लिकेशन पंजीकृत करें**, किसी भी उपयोगकर्ता के लिए एक अधिकृति कोड प्राप्त करने के लिए अधिकृति प्रक्रिया का प्रदर्शन करें, और फिर निम्नलिखित बॉडी के साथ "/token" अंत बिंदु को फ़ेच करें:
यदि संकटग्रस्त है, तो **सर्वर को प्रदान की गई "jwks\_uri" के लिए सर्वर-से-सर्वर एचटीटीपी अनुरोध करना चाहिए** क्योंकि यह आपके अनुरोध में "client\_assertion" पैरामीटर की मान्यता की जांच करने के लिए इस कुंजी की आवश्यकता होती है। यह शायद केवल एक **अंधा एसएसआरएफ संकटग्रस्तता ही होगी**, क्योंकि सर्वर को एक उचित JSON प्रतिक्रिया की उम्मीद होती है।
* **sector\_identifier\_uri** - यह URL एक फ़ाइल का संदर्भ करता है जिसमें एक एकल **JSON एरे ऑफ़ रीडायरेक्ट
