# OAuth to Account takeover {{#include ../banners/hacktricks-training.md}} ## Basic Information OAuth विभिन्न संस्करणों की पेशकश करता है, जिनकी मौलिक जानकारी [OAuth 2.0 documentation](https://oauth.net/2/) पर उपलब्ध है। यह चर्चा मुख्य रूप से व्यापक रूप से उपयोग किए जाने वाले [OAuth 2.0 authorization code grant type](https://oauth.net/2/grant-types/authorization-code/) पर केंद्रित है, जो एक **authorization framework प्रदान करता है जो एक एप्लिकेशन को किसी अन्य एप्लिकेशन में उपयोगकर्ता के खाते तक पहुंचने या उस पर क्रियाएं करने की अनुमति देता है** (authorization server)। एक काल्पनिक वेबसाइट _**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:** एक गोपनीय कुंजी, जो केवल एप्लिकेशन और authorization server को ज्ञात होती है, जिसका उपयोग `access_tokens` उत्पन्न करने के लिए किया जाता है। - **response_type**: एक मान जो **अनुरोधित टोकन के प्रकार को निर्दिष्ट करता है**, जैसे `code`। - **scope**: **उपयोगकर्ता से `client application` द्वारा अनुरोधित पहुंच का स्तर**। - **redirect_uri**: **URL जिस पर उपयोगकर्ता अनुमोदन के बाद पुनर्निर्देशित होता है**। यह आमतौर पर पूर्व-पंजीकृत पुनर्निर्देशित URL के साथ मेल खाना चाहिए। - **state**: एक पैरामीटर जो **उपयोगकर्ता के अनुमोदन सर्वर पर जाने और लौटने के दौरान डेटा बनाए रखने के लिए** होता है। इसकी विशिष्टता **CSRF सुरक्षा तंत्र** के रूप में कार्य करने के लिए महत्वपूर्ण है। - **grant_type**: एक पैरामीटर जो **अनुदान प्रकार और लौटाए जाने वाले टोकन के प्रकार को इंगित करता है**। - **code**: `authorization server` से प्राप्त अनुमोदन कोड, जिसका उपयोग `client_id` और `client_secret` के साथ `client application` द्वारा `access_token` प्राप्त करने के लिए किया जाता है। - **access_token**: **टोकन जो `client application` API अनुरोधों के लिए उपयोग करता है** `resource owner` की ओर से। - **refresh_token**: एप्लिकेशन को **बिना उपयोगकर्ता को फिर से प्रॉम्प्ट किए एक नया `access_token` प्राप्त करने की अनुमति देता है**। ### Flow **वास्तविक OAuth प्रवाह** इस प्रकार है: 1. आप [https://example.com](https://example.com) पर जाते हैं और “Integrate with Social Media” बटन का चयन करते हैं। 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 ### 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](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html) यह संभव हो सकता है कि पुनर्निर्देशित **URL सर्वर के उत्तर में परिलक्षित हो रहा है** उपयोगकर्ता के प्रमाणीकरण के बाद, **XSS के प्रति संवेदनशील**। परीक्षण के लिए संभावित पेलोड: ``` https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard

test

``` ### 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**](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 इस बग बाउंटी रिपोर्ट में: [**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.wiki/en/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.html {{#endref}} ### Abusing other Apps tokens जैसा कि [**इस लेख में उल्लेख किया गया है**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), OAuth प्रवाह जो **token** (और कोड नहीं) प्राप्त करने की अपेक्षा करते हैं, यदि वे यह नहीं जांचते कि टोकन ऐप का है, तो वे कमजोर हो सकते हैं। इसका कारण यह है कि एक **हमलावर** एक **ऐप्लिकेशन बना सकता है जो OAuth का समर्थन करता है और फेसबुक के साथ लॉगिन करता है** (उदाहरण के लिए) अपने स्वयं के ऐप में। फिर, जब एक पीड़ित फेसबुक के साथ **हमलावर के ऐप में लॉगिन करता है**, तो हमलावर **उपयोगकर्ता के OAuth टोकन को प्राप्त कर सकता है जो उसके ऐप को दिया गया है, और इसका उपयोग पीड़ित के OAuth ऐप में लॉगिन करने के लिए कर सकता है।** > [!CAUTION] > इसलिए, यदि हमलावर उपयोगकर्ता को अपने OAuth ऐप तक पहुंच प्राप्त करने में सफल हो जाता है, तो वह उन ऐप्स में पीड़ित के खाते पर नियंत्रण प्राप्त कर सकेगा जो टोकन की अपेक्षा कर रहे हैं और यह नहीं जांचते कि टोकन उनके ऐप आईडी को दिया गया था या नहीं। ### Two links & cookie [**इस लेख के अनुसार**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), यह संभव था कि एक पीड़ित एक पृष्ठ खोले जिसमें **returnUrl** हमलावर के होस्ट की ओर इशारा करता है। यह जानकारी **एक कुकी (RU)** में **स्टोर की जाएगी** और **बाद के चरण में** **प्रॉम्प्ट** **उपयोगकर्ता** से पूछेगा कि क्या वह उस हमलावर के होस्ट को एक्सेस देने के लिए तैयार है। इस प्रॉम्प्ट को बायपास करने के लिए, यह संभव था कि एक टैब खोला जाए ताकि **Oauth प्रवाह** को आरंभ किया जा सके जो इस RU कुकी को **returnUrl** का उपयोग करके सेट करेगा, प्रॉम्प्ट दिखाए जाने से पहले टैब बंद कर दें, और बिना उस मान के एक नया टैब खोलें। तब, **प्रॉम्प्ट हमलावर के होस्ट के बारे में सूचित नहीं करेगा**, लेकिन कुकी को इसके लिए सेट किया जाएगा, इसलिए **टोकन हमलावर के होस्ट को रीडायरेक्शन में भेजा जाएगा।** ### Prompt Interaction Bypass जैसा कि [**इस वीडियो में समझाया गया है**](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 flow - 2 FA bypass [**इस ब्लॉग पोस्ट के अनुसार**](https://cybxis.medium.com/a-bypass-on-gitlabs-login-email-verification-via-oauth-ropc-flow-e194242cad96), यह एक OAuth प्रवाह है जो **उपयोगकर्ता नाम** और **पासवर्ड** के माध्यम से OAuth में लॉगिन करने की अनुमति देता है। यदि इस सरल प्रवाह के दौरान एक **टोकन** लौटाया जाता है जिसमें सभी क्रियाओं तक पहुंच होती है जो उपयोगकर्ता कर सकता है, तो उस टोकन का उपयोग करके 2FA को बायपास करना संभव है। ### ATO on web page redirecting based on open redirect to referrer यह [**ब्लॉगपोस्ट**](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 parameters [**इस शोध की जांच करें**](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 providers Race Conditions यदि आप जिस प्लेटफॉर्म का परीक्षण कर रहे हैं वह एक OAuth प्रदाता है [**संभावित रेस कंडीशंस के लिए इसे पढ़ें**](race-condition.md). ## Mutable Claims Attack OAuth में, सब फ़ील्ड एक उपयोगकर्ता की अद्वितीय पहचान करता है, लेकिन इसका प्रारूप प्राधिकरण सर्वर द्वारा भिन्न होता है। उपयोगकर्ता पहचान को मानकीकृत करने के लिए, कुछ क्लाइंट ईमेल या उपयोगकर्ता हैंडल का उपयोग करते हैं। हालाँकि, यह जोखिम भरा है क्योंकि: - कुछ प्राधिकरण सर्वर यह सुनिश्चित नहीं करते हैं कि ये गुण (जैसे ईमेल) अपरिवर्तनीय रहें। - कुछ कार्यान्वयन—जैसे **"Microsoft के साथ लॉगिन"**—क्लाइंट ईमेल फ़ील्ड पर निर्भर करता है, जो **उपयोगकर्ता द्वारा Entra ID में नियंत्रित किया जाता है** और सत्यापित नहीं होता है। - एक हमलावर इसका लाभ उठाकर अपना Azure AD संगठन (जैसे, doyensectestorg) बना सकता है और इसका उपयोग Microsoft लॉगिन करने के लिए कर सकता है। - भले ही ऑब्जेक्ट आईडी (जो सब में संग्रहीत है) अपरिवर्तनीय और सुरक्षित है, एक परिवर्तनीय ईमेल फ़ील्ड पर निर्भरता एक खाता अधिग्रहण को सक्षम कर सकती है (उदाहरण के लिए, victim@gmail.com जैसे खाते को हाईजैक करना)। ## 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://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) - [**https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html**](https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html) {{#include ../banners/hacktricks-training.md}}