# OAuth से खाता अधिग्रहण

{{#include ../banners/hacktricks-training.md}}

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

OAuth विभिन्न संस्करणों की पेशकश करता है, जिनकी मौलिक जानकारी [OAuth 2.0 दस्तावेज़ीकरण](https://oauth.net/2/) पर उपलब्ध है। यह चर्चा मुख्य रूप से व्यापक रूप से उपयोग किए जाने वाले [OAuth 2.0 प्राधिकरण कोड अनुदान प्रकार](https://oauth.net/2/grant-types/authorization-code/) पर केंद्रित है, जो **एक प्राधिकरण ढांचा प्रदान करता है जो एक एप्लिकेशन को किसी अन्य एप्लिकेशन में उपयोगकर्ता के खाते तक पहुँचने या क्रियाएँ करने की अनुमति देता है** (प्राधिकरण सर्वर)।

एक काल्पनिक वेबसाइट _**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**: **सर्वर जो `client application` को `access tokens` जारी करता है** `resource owner` की सफल प्रमाणीकरण और प्राधिकरण सुरक्षित करने के बाद, जैसे कि **https://socialmedia.com**।
- **client_id**: एप्लिकेशन के लिए एक सार्वजनिक, अद्वितीय पहचानकर्ता।
- **client_secret:** एक गोपनीय कुंजी, जो केवल एप्लिकेशन और प्राधिकरण सर्वर को ज्ञात है, जिसका उपयोग `access_tokens` उत्पन्न करने के लिए किया जाता है।
- **response_type**: एक मान जो **अनुरोधित टोकन के प्रकार** को निर्दिष्ट करता है, जैसे `code`।
- **scope**: **उपयोगकर्ता से `client application` द्वारा अनुरोधित पहुँच का स्तर**।
- **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` प्राप्त करने** की अनुमति देता है।

### प्रवाह

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

1. आप [https://example.com](https://example.com) पर जाते हैं और “सोशल मीडिया के साथ एकीकृत करें” बटन का चयन करते हैं।
2. साइट फिर [https://socialmedia.com](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 <a href="#id-323a" id="id-323a"></a>

### Open redirect_uri <a href="#cc36" id="cc36"></a>

`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 <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 - Improper handling of state parameter <a href="#bda5" id="bda5"></a>

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

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

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

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

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

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

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

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

एक सामान्य भेद्यता तब उत्पन्न होती है जब अनुप्रयोग गलती से ग्राहक-पक्ष पर `access_token` के लिए अधिकृत `code` के आदान-प्रदान को संभालते हैं, न कि सर्वर-पक्ष पर। यह गलती `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 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**](https://labs.detectify.com/writeups/account-hijacking-using-dirty-dancing-in-sign-in-oauth-flows/#gadget-2-xss-on-sandbox-third-party-domain-that-gets-the-url)

### 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** उपयोगकर्ता को वापस देता है, उसमें **उपयोगकर्ता डेटा को ओवरराइट करने के लिए पर्याप्त अनुमतियाँ हो सकती हैं**। इसलिए, यदि आप **एक उपयोगकर्ता ईमेल को एक अलग उपयोगकर्ता ईमेल के लिए बदल सकते हैं**, तो आप अन्य खातों पर **कब्जा कर सकते हैं**।
```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"
}
]
}
```
For more detailed info about how to abuse AWS cognito check:

{{#ref}}
https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum
{{#endref}}

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

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

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

> [!CAUTION]
> इसलिए, यदि हमलावर उपयोगकर्ता को अपने OAuth ऐप तक पहुंच प्राप्त करने में सफल हो जाता है, तो वह उन ऐप्स में पीड़ित के खाते पर नियंत्रण प्राप्त कर सकेगा जो टोकन की अपेक्षा कर रहे हैं और यह नहीं जांच रहे हैं कि टोकन उनके ऐप आईडी को दिया गया था या नहीं।

### दो लिंक और कुकी <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** का उपयोग करके सेट करेगा, प्रॉम्प्ट दिखाए जाने से पहले टैब बंद करें, और बिना उस मान के एक नया टैब खोलें। फिर, **प्रॉम्प्ट हमलावर के होस्ट के बारे में सूचित नहीं करेगा**, लेकिन कुकी इसे सेट कर दी जाएगी, इसलिए **टोकन हमलावर के होस्ट** पर पुनर्निर्देशन में भेजा जाएगा।

### प्रॉम्प्ट इंटरैक्शन बायपास <a href="#bda5" id="bda5"></a>

जैसा कि [**इस वीडियो में समझाया गया है**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), कुछ OAuth कार्यान्वयन **`prompt`** GET पैरामीटर को None (**`&prompt=none`**) के रूप में इंगित करने की अनुमति देते हैं ताकि **उपयोगकर्ताओं को दिए गए एक्सेस की पुष्टि करने के लिए प्रॉम्प्ट में पूछा न जाए** यदि वे पहले से ही प्लेटफॉर्म में लॉगिन कर चुके हैं।

### response_mode

जैसा कि [**इस वीडियो में समझाया गया है**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), यह संभव हो सकता है कि पैरामीटर **`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 प्रवाह - 2 FA बायपास <a href="#b440" id="b440"></a>

[**इस ब्लॉग पोस्ट के अनुसार**](https://cybxis.medium.com/a-bypass-on-gitlabs-login-email-verification-via-oauth-ropc-flow-e194242cad96), यह एक OAuth प्रवाह है जो **उपयोगकर्ता नाम** और **पासवर्ड** के माध्यम से OAuth में लॉगिन करने की अनुमति देता है। यदि इस सरल प्रवाह के दौरान एक **टोकन** लौटाया जाता है जिसमें सभी क्रियाओं तक पहुंच होती है जो उपयोगकर्ता कर सकता है, तो उस टोकन का उपयोग करके 2FA को बायपास करना संभव है।

### ओपन रीडायरेक्ट पर आधारित वेब पृष्ठ पर ATO <a href="#bda5" id="bda5"></a>

यह [**ब्लॉगपोस्ट**](https://blog.voorivex.team/oauth-non-happy-path-to-ato) बताता है कि कैसे एक **ओपन रीडायरेक्ट** का दुरुपयोग करके **रेफरर** के मान से 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 पैरामीटर <a href="#bda5" id="bda5"></a>

[**इस शोध की जांच करें**](https://portswigger.net/research/hidden-oauth-attack-vectors) **इस तकनीक के आगे के विवरण के लिए।**

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 प्रदाताओं की दौड़ की स्थितियाँ

यदि आप जिस प्लेटफॉर्म का परीक्षण कर रहे हैं वह एक 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)

{{#include ../banners/hacktricks-training.md}}