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

# OAuth से Account takeover

<details>

<summary><strong>AWS हैकिंग सीखें शून्य से लेकर हीरो तक</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong> के साथ!</strong></summary>

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

* यदि आप चाहते हैं कि आपकी **कंपनी का विज्ञापन HackTricks में दिखाई दे** या **HackTricks को PDF में डाउनलोड करें**, तो [**सब्सक्रिप्शन प्लान्स**](https://github.com/sponsors/carlospolop) देखें!
* [**आधिकारिक PEASS & HackTricks स्वैग**](https://peass.creator-spring.com) प्राप्त करें
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारा विशेष [**NFTs**](https://opensea.io/collection/the-peass-family) संग्रह
* 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) में **शामिल हों** या [**telegram group**](https://t.me/peass) में या **Twitter** पर 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm) को **फॉलो करें**.
* **HackTricks** के [**github repos**](https://github.com/carlospolop/hacktricks) और [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) में PRs सबमिट करके अपनी हैकिंग ट्रिक्स साझा करें।

</details>

## मूल जानकारी <a href="#d4a8" id="d4a8"></a>

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

इस लेख में, हम आज आपको जो सबसे आम प्रवाह मिलेगा, उस पर ध्यान केंद्रित करेंगे, जो है [OAuth 2.0 authorization code grant type](https://oauth.net/2/grant-types/authorization-code/)। मूल रूप से, 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](https://yourtweetreader.com) पर जाते हैं और "Integrate with Twitter" बटन पर क्लिक करते हैं।
2. [https://yourtweetreader.com](https://yourtweetreader.com) [https://twitter.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\. आपको एक सहमति पृष्ठ दिखाई देगा:

![](https://miro.medium.com/max/1215/1\*y66EY3Fn2qn-NPI9nhZC7A.png)

4\. स्वीकार करने के बाद, Twitter `redirect_uri` पर `code` और `state` पैरामीटर्स के साथ एक अनुरोध वापस भेजेगा:
```
https://yourtweetreader.com?code=asd91j3jd91j92j1j9d1&state=kasodk9d1jd992k9klaskdh123
```
5\. [https://yourtweetreader.com](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](https://yourtweetreader.com) आपके `access_token` के साथ Twitter को API कॉल करेगा ताकि आपके Tweets तक पहुँच सके।

## बग बाउंटी निष्कर्ष <a href="#323a" id="323a"></a>

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

### कमजोर redirect\_uri कॉन्फ़िगरेशन <a href="#cc36" id="cc36"></a>

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

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

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

* ओपन रीडायरेक्ट्स: [`https://yourtweetreader.com`](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 <a href="#bda5" id="bda5"></a>

जैसा कि इस बग बाउंटी रिपोर्ट [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](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 - स्टेट पैरामीटर का अनुचित संभाल <a href="#bda5" id="bda5"></a>

अक्सर, **`state` पैरामीटर को पूरी तरह से छोड़ दिया जाता है या गलत तरीके से इस्तेमाल किया जाता है**। यदि स्टेट पैरामीटर **अनुपस्थित है**, **या एक स्थिर मूल्य** है जो कभी नहीं बदलता, तो OAuth प्रवाह बहुत संभावना से **CSRF के लिए संवेदनशील होगा**। कभी-कभी, यहां तक कि अगर एक `state` पैरामीटर है, तो **एप्लिकेशन पैरामीटर का कोई मान्यता नहीं कर सकता** और एक हमला काम करेगा। इसका शोषण करने का तरीका यह होगा कि आप अपने खाते पर प्राधिकरण प्रक्रिया से गुजरें, और प्राधिकरण के ठीक बाद रुकें। तब आपको इस तरह का अनुरोध मिलेगा:
```
https://yourtweetreader.com?code=asd91j3jd91j92j1j9d1
```
इस अनुरोध को प्राप्त करने के बाद, आप **अनुरोध को छोड़ सकते हैं क्योंकि ये कोड आमतौर पर एक बार के उपयोग के लिए होते हैं**। फिर आप इस URL को एक **लॉग-इन उपयोगकर्ता को भेज सकते हैं, और यह आपके खाते को उनके खाते में जोड़ देगा**। पहली नजर में, यह बहुत संवेदनशील नहीं लग सकता है क्योंकि आप केवल अपने खाते को एक पीड़ित के खाते में जोड़ रहे हैं। हालांकि, कई OAuth कार्यान्वयन साइन-इन उद्देश्यों के लिए होते हैं, इसलिए यदि आप अपने Google खाते को जोड़ सकते हैं जिसका उपयोग लॉगिन के लिए किया जाता है, तो आप एक क्लिक के साथ **Account Takeover** कर सकते हैं क्योंकि अपने Google खाते से लॉगिन करने से आपको पीड़ित के खाते तक पहुंच मिल जाएगी।

इसके बारे में एक **उदाहरण** आप इस [**CTF writeup**](https://github.com/gr455/ctf-writeups/blob/master/hacktivity20/notes\_surfer.md) में और **HTB box called Oouch** में देख सकते हैं।

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

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

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

### Pre Account Takeover <a href="#ebe4" id="ebe4"></a>

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

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

### Disclosure of Secrets <a href="#e177" id="e177"></a>

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

_5._ [_https://yourtweetreader.com_](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 <a href="#bda5" id="bda5"></a>

इस बग बाउंटी रिपोर्ट में: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) आप देख सकते हैं कि **AWS Cognito** द्वारा उपयोगकर्ता को वापस दिया गया **token** शायद **पर्याप्त अनुमतियां रखता है उपयोगकर्ता डेटा को ओवरराइट करने के लिए**। इसलिए, यदि आप **उपयोगकर्ता के ईमेल को एक अलग उपयोगकर्ता के ईमेल से बदल सकते हैं**, आप अन्य खातों का **अधिग्रहण** कर सकते हैं।
```bash
# 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" %}

### अन्य ऐप्स के टोकन का दुरुपयोग <a href="#bda5" id="bda5"></a>

जैसा कि [**इस लेख में उल्लेखित है**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), OAuth प्रवाह जो **टोकन** प्राप्त करने की अपेक्षा करते हैं (और कोड नहीं) वे कमजोर हो सकते हैं यदि वे यह जांच नहीं करते कि टोकन ऐप का है या नहीं।

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

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

### दो लिंक्स और कुकी <a href="#bda5" id="bda5"></a>

[**इस लेख के अनुसार**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), यह संभव था कि पीड़ित को एक पेज खोलने के लिए मजबूर किया जाए जिसमें **returnUrl** हमलावर के होस्ट की ओर इशारा करता हो। यह जानकारी **कुकी (RU)** में **संग्रहीत** की जाएगी और एक **बाद के चरण** में **प्रॉम्प्ट** यूजर से **पूछेगा** कि क्या वह उस हमलावर के होस्ट को एक्सेस देना चाहता है।

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

### SSRFs पैरामीटर्स <a href="#bda5" id="bda5"></a>

एक छिपा हुआ URL जिसे आप याद कर सकते हैं वह है **Dynamic Client Registration endpoint**। यूजर्स को सफलतापूर्वक प्रमाणित करने के लिए, OAuth सर्वरों को क्लाइंट ऐप्लिकेशन के बारे में विवरण जानने की आवश्यकता होती है, जैसे "client\_name", "client\_secret", "redirect\_uris", आदि। ये विवरण स्थानीय कॉन्फ़िगरेशन के माध्यम से प्रदान किए जा सकते हैं, लेकिन OAuth प्राधिकरण सर्वरों के पास एक **विशेष पंजीकरण एंडपॉइंट** भी हो सकता है। यह एंडपॉइंट सामान्यतः "/register" पर मैप किया जाता है और निम्नलिखित प्रारूप के साथ POST अनुरोध स्वीकार करता है:
```json
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](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 संदर्भों के माध्यम से पास किए जाते हैं और [Server Side Request Forgery](https://portswigger.net/web-security/ssrf) के लिए संभावित लक्ष्य की तरह दिखते हैं। साथ ही, हमने जिन अधिकांश सर्वरों का परीक्षण किया है, वे इन 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](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 प्रदाता है [**इसे पढ़ें संभावित रेस कंडीशन्स के लिए परीक्षण करने के लिए**](race-condition.md).

## संदर्भ

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

<details>

<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

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

* यदि आप अपनी **कंपनी को HackTricks में विज्ञापित** देखना चाहते हैं या **HackTricks को PDF में डाउनलोड** करना चाहते हैं तो [**सदस्यता योजनाएं**](https://github.com/sponsors/carlospolop) देखें!
* [**आधिकारिक PEASS & HackTricks स्वैग**](https://peass.creator-spring.com) प्राप्त करें
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारा संग्रह विशेष [**NFTs**](https://opensea.io/collection/the-peass-family)
* 💬 [**Discord समूह**](https://discord.gg/hRep4RUj7f) में **शामिल हों** या [**telegram समूह**](https://t.me/peass) या **Twitter** पर मुझे 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)** का पालन करें**।
* **HackTricks** के लिए PRs सबमिट करके अपनी हैकिंग ट्रिक्स साझा करें [**HackTricks**](https://github.com/carlosp