mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/generic-methodologies-and-resources/external-recon-meth
This commit is contained in:
Translator
parent
1d7e18bef4
commit
77bc0a8c51
@ -2,16 +2,13 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
अब जब हमने अपने दायरे के संपत्तियों की सूची बना ली है, तो कुछ OSINT कम-से-कम फलों की खोज करने का समय है।
|
||||
|
||||
### पहले से लीक के लिए खोजी गई प्लेटफार्म
|
||||
|
||||
- [https://trufflesecurity.com/blog/introducing-forager/](https://trufflesecurity.com/blog/introducing-forager/)
|
||||
|
||||
### Github में Api keys लीक
|
||||
### गिट रिपोजिटरी और फ़ाइल सिस्टम में रहस्यों को खोजने के लिए उपकरण
|
||||
|
||||
- [https://github.com/dxa4481/truffleHog](https://github.com/dxa4481/truffleHog)
|
||||
- [https://github.com/gitleaks/gitleaks](https://github.com/gitleaks/gitleaks)
|
||||
- [https://github.com/praetorian-inc/noseyparker](https://github.com/praetorian-inc/noseyparker)
|
||||
- [https://github.com/GitGuardian/ggshield](https://github.com/GitGuardian/ggshield)
|
||||
- [https://github.com/JaimePolop/RExpository](https://github.com/JaimePolop/RExpository)
|
||||
- [https://github.com/Yelp/detect-secrets](https://github.com/Yelp/detect-secrets)
|
||||
- [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber)
|
||||
- [https://github.com/eth0izzle/shhgit](https://github.com/eth0izzle/shhgit)
|
||||
|
||||
@ -4,25 +4,25 @@
|
||||
|
||||
## Basic Information <a href="#d4a8" id="d4a8"></a>
|
||||
|
||||
OAuth विभिन्न संस्करणों की पेशकश करता है, जिनकी मौलिक जानकारी [OAuth 2.0 documentation](https://oauth.net/2/) पर उपलब्ध है। यह चर्चा मुख्य रूप से व्यापक रूप से उपयोग किए जाने वाले [OAuth 2.0 authorization code grant type](https://oauth.net/2/grant-types/authorization-code/) पर केंद्रित है, जो **एक प्राधिकरण ढांचा प्रदान करता है जो एक एप्लिकेशन को किसी अन्य एप्लिकेशन में उपयोगकर्ता के खाते तक पहुंचने या उस पर क्रियाएँ करने की अनुमति देता है** (प्राधिकरण सर्वर)।
|
||||
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_ को **आपकी ओर से आपके पोस्ट तक पहुंचने की क्षमता मिलती है**।
|
||||
एक काल्पनिक वेबसाइट _**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**।
|
||||
- **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:** एक गोपनीय कुंजी, जो केवल एप्लिकेशन और प्राधिकरण सर्वर को ज्ञात होती है, जिसका उपयोग `access_tokens` उत्पन्न करने के लिए किया जाता है।
|
||||
- **response_type**: एक मान जो **मांगी गई टोकन के प्रकार** को निर्दिष्ट करता है, जैसे `code`।
|
||||
- **scope**: **एक्सेस का स्तर** जो `client application` `resource owner` से मांग रहा है।
|
||||
- **redirect_uri**: **URL जिस पर उपयोगकर्ता प्राधिकरण के बाद पुनर्निर्देशित होता है**। यह आमतौर पर पूर्व-पंजीकृत पुनर्निर्देशित URL के साथ मेल खाना चाहिए।
|
||||
- **state**: एक पैरामीटर जो **उपयोगकर्ता के प्राधिकरण सर्वर पर जाने और लौटने के दौरान डेटा बनाए रखने के लिए** होता है। इसकी विशिष्टता **CSRF सुरक्षा तंत्र** के रूप में कार्य करने के लिए महत्वपूर्ण है।
|
||||
- **grant_type**: एक पैरामीटर जो **अनुदान प्रकार और लौटाए जाने वाले टोकन के प्रकार** को इंगित करता है।
|
||||
- **code**: `authorization server` से प्राधिकरण कोड, जिसका उपयोग `client_id` और `client_secret` के साथ `access_token` प्राप्त करने के लिए किया जाता है।
|
||||
- **access_token**: **टोकन जो `client application` API अनुरोधों के लिए `resource owner` की ओर से उपयोग करता है**।
|
||||
- **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
|
||||
@ -30,7 +30,7 @@ OAuth 2.0 ढांचे के भीतर निम्नलिखित घ
|
||||
**वास्तविक OAuth प्रवाह** इस प्रकार है:
|
||||
|
||||
1. आप [https://example.com](https://example.com) पर जाते हैं और “Integrate with Social Media” बटन का चयन करते हैं।
|
||||
2. साइट फिर [https://socialmedia.com](https://socialmedia.com) पर आपके प्राधिकरण के लिए अनुरोध भेजती है ताकि https://example.com के एप्लिकेशन को आपके पोस्ट तक पहुंचने की अनुमति मिल सके। अनुरोध इस प्रकार संरचित है:
|
||||
2. साइट फिर [https://socialmedia.com](https://socialmedia.com) पर आपके अनुमोदन के लिए अनुरोध भेजती है ताकि https://example.com के एप्लिकेशन को आपके पोस्ट तक पहुंचने की अनुमति मिल सके। अनुरोध इस प्रकार संरचित है:
|
||||
```
|
||||
https://socialmedia.com/auth
|
||||
?response_type=code
|
||||
@ -40,7 +40,7 @@ https://socialmedia.com/auth
|
||||
&state=randomString123
|
||||
```
|
||||
3. आपको फिर एक सहमति पृष्ठ प्रस्तुत किया जाता है।
|
||||
4. आपकी स्वीकृति के बाद, Social Media `redirect_uri` को `code` और `state` पैरामीटर के साथ एक प्रतिक्रिया भेजता है:
|
||||
4. आपकी स्वीकृति के बाद, Social Media `redirect_uri` पर `code` और `state` पैरामीटर के साथ एक प्रतिक्रिया भेजता है:
|
||||
```
|
||||
https://example.com?code=uniqueCode123&state=randomString123
|
||||
```
|
||||
@ -66,15 +66,15 @@ Host: socialmedia.com
|
||||
|
||||
### 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://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 कार्यान्वयन में, **`state` parameter** का दुरुपयोग या अनुपस्थिति **Cross-Site Request Forgery (CSRF)** हमलों के जोखिम को काफी बढ़ा सकती है। यह भेद्यता तब उत्पन्न होती है जब `state` parameter या तो **उपयोग नहीं किया जाता, स्थिर मान के रूप में उपयोग किया जाता है, या लॉगिन करते समय उपयोगकर्ताओं के सत्र के साथ सही ढंग से मान्य या संबद्ध नहीं किया जाता** है, जिससे हमलावर CSRF सुरक्षा को बायपास कर सकते हैं।
|
||||
|
||||
हमलावर इसको अधिकृत प्रक्रिया को इंटरसेप्ट करके पीड़ित के खाते के साथ अपने खाते को लिंक करने के लिए उपयोग कर सकते हैं, जिससे संभावित **खाते का अधिग्रहण** हो सकता है। यह विशेष रूप से उन अनुप्रयोगों में महत्वपूर्ण है जहाँ OAuth का उपयोग **प्रमाणीकरण उद्देश्यों** के लिए किया जाता है।
|
||||
हमलावर इसको अधिकृत प्रक्रिया को इंटरसेप्ट करके शिकार के खाते के साथ अपने खाते को लिंक करने के लिए उपयोग कर सकते हैं, जिससे संभावित **खाते पर कब्जा** हो सकता है जब एक उपयोगकर्ता हमलावर के लगभग पूर्ण OAuth प्रवाह के साथ लॉगिन करता है। यह विशेष रूप से उन अनुप्रयोगों में महत्वपूर्ण है जहाँ OAuth का उपयोग **प्रमाणीकरण उद्देश्यों** के लिए किया जाता है।
|
||||
|
||||
इस भेद्यता के वास्तविक दुनिया के उदाहरण विभिन्न **CTF चुनौतियों** और **हैकिंग प्लेटफार्मों** में दस्तावेजीकृत किए गए हैं, जो इसके व्यावहारिक प्रभावों को उजागर करते हैं। यह समस्या तीसरे पक्ष की सेवाओं जैसे **Slack**, **Stripe**, और **PayPal** के साथ एकीकरण तक भी फैली हुई है, जहाँ हमलावर सूचनाओं या भुगतानों को अपने खातों में पुनर्निर्देशित कर सकते हैं।
|
||||
|
||||
@ -82,8 +82,8 @@ OAuth कार्यान्वयन में, **`state` parameter** का
|
||||
|
||||
### Pre Account Takeover <a href="#ebe4" id="ebe4"></a>
|
||||
|
||||
1. **खाते के निर्माण पर ईमेल सत्यापन के बिना**: हमलावर पीड़ित के ईमेल का उपयोग करके पूर्व-निर्मित खाता बना सकते हैं। यदि पीड़ित बाद में लॉगिन के लिए किसी तीसरे पक्ष की सेवा का उपयोग करता है, तो अनुप्रयोग अनजाने में इस तीसरे पक्ष के खाते को हमलावर के पूर्व-निर्मित खाते से लिंक कर सकता है, जिससे अनधिकृत पहुंच हो सकती है।
|
||||
2. **OAuth ईमेल सत्यापन की लापरवाही का लाभ उठाना**: हमलावर उन OAuth सेवाओं का लाभ उठा सकते हैं जो ईमेल की पुष्टि नहीं करती हैं, अपनी सेवा के साथ पंजीकरण करके और फिर खाते के ईमेल को पीड़ित के ईमेल में बदलकर। यह विधि भी अनधिकृत खाता पहुंच का जोखिम उठाती है, पहले परिदृश्य के समान लेकिन एक अलग हमले के वेक्टर के माध्यम से।
|
||||
1. **खाते के निर्माण पर ईमेल सत्यापन के बिना**: हमलावर शिकार के ईमेल का उपयोग करके पूर्व-निर्मित खाता बना सकते हैं। यदि शिकार बाद में लॉगिन के लिए किसी तीसरे पक्ष की सेवा का उपयोग करता है, तो अनुप्रयोग अनजाने में इस तीसरे पक्ष के खाते को हमलावर के पूर्व-निर्मित खाते से लिंक कर सकता है, जिससे अनधिकृत पहुंच हो सकती है।
|
||||
2. **OAuth ईमेल सत्यापन की लापरवाही का लाभ उठाना**: हमलावर उन OAuth सेवाओं का लाभ उठा सकते हैं जो ईमेल की पुष्टि नहीं करती हैं, अपनी सेवा के साथ पंजीकरण करके और फिर खाते के ईमेल को शिकार के ईमेल में बदलकर। यह विधि भी पहले परिदृश्य के समान अनधिकृत खाता पहुंच का जोखिम उठाती है, लेकिन एक अलग हमले के वेक्टर के माध्यम से।
|
||||
|
||||
### Disclosure of Secrets <a href="#e177" id="e177"></a>
|
||||
|
||||
@ -93,7 +93,7 @@ OAuth कार्यान्वयन में, **`state` parameter** का
|
||||
|
||||
### Client Secret Bruteforce
|
||||
|
||||
आप सेवा प्रदाता के साथ पहचान प्रदाता का **client_secret** **bruteforce** करने का प्रयास कर सकते हैं ताकि खातों को चुराने की कोशिश की जा सके।\
|
||||
आप सेवा प्रदाता के साथ पहचान प्रदाता का **client_secret** ब्रूटफोर्स करने की कोशिश कर सकते हैं ताकि खातों को चुराने का प्रयास किया जा सके।\
|
||||
BF के लिए अनुरोध इस प्रकार का हो सकता है:
|
||||
```
|
||||
POST /token HTTP/1.1
|
||||
@ -114,7 +114,7 @@ code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=au
|
||||
|
||||
### Everlasting Authorization Code
|
||||
|
||||
**अधिकार कोड को केवल कुछ समय के लिए जीवित रहना चाहिए ताकि हमलावर इसे चुराने और उपयोग करने के लिए समय की खिड़की को सीमित कर सके**।
|
||||
**अधिकार कोड को केवल कुछ समय के लिए जीवित रहना चाहिए ताकि हमलावर इसे चुराने और उपयोग करने के लिए समय की खिड़की को सीमित किया जा सके**।
|
||||
|
||||
### Authorization/Refresh Token not bound to client
|
||||
|
||||
@ -126,7 +126,7 @@ code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=au
|
||||
|
||||
### 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** उपयोगकर्ता को वापस देता है, उसमें **उपयोगकर्ता डेटा को ओवरराइट करने के लिए पर्याप्त अनुमतियाँ हो सकती हैं**। इसलिए, यदि आप **एक उपयोगकर्ता ईमेल को एक अलग उपयोगकर्ता ईमेल के लिए बदल सकते हैं**, तो आप अन्य खातों पर **कब्जा कर सकते हैं**।
|
||||
इस बग बाउंटी रिपोर्ट में: [**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[...]
|
||||
@ -151,30 +151,30 @@ https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-unauthenticat
|
||||
|
||||
### Abusing other Apps tokens <a href="#bda5" id="bda5"></a>
|
||||
|
||||
जैसा कि [**इस लेख में उल्लेख किया गया है**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), OAuth प्रवाह जो **token** (और न कि कोड) प्राप्त करने की अपेक्षा करते हैं, वे कमजोर हो सकते हैं यदि वे यह नहीं जांचते कि टोकन ऐप का है।
|
||||
जैसा कि [**इस लेख में उल्लेख किया गया है**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), OAuth प्रवाह जो **token** (और कोड नहीं) प्राप्त करने की अपेक्षा करते हैं, यदि वे यह नहीं जांचते कि टोकन ऐप का है, तो वे कमजोर हो सकते हैं।
|
||||
|
||||
यह इसलिए है क्योंकि एक **हमलावर** एक **ऐप्लिकेशन बना सकता है जो OAuth का समर्थन करता है और फेसबुक के साथ लॉगिन करता है** (उदाहरण के लिए) अपने स्वयं के ऐप में। फिर, जब एक पीड़ित फेसबुक के साथ **हमलावर के ऐप में लॉगिन करता है**, तो हमलावर **उपयोगकर्ता के OAuth टोकन को प्राप्त कर सकता है जो उसके ऐप को दिया गया है, और इसका उपयोग पीड़ित OAuth ऐप में पीड़ित के उपयोगकर्ता टोकन का उपयोग करके लॉगिन करने के लिए कर सकता है**।
|
||||
इसका कारण यह है कि एक **हमलावर** एक **ऐप्लिकेशन बना सकता है जो OAuth का समर्थन करता है और फेसबुक के साथ लॉगिन करता है** (उदाहरण के लिए) अपने स्वयं के ऐप में। फिर, जब एक पीड़ित फेसबुक के साथ **हमलावर के ऐप में लॉगिन करता है**, तो हमलावर **उपयोगकर्ता के OAuth टोकन को प्राप्त कर सकता है जो उसके ऐप को दिया गया है, और इसका उपयोग पीड़ित के OAuth ऐप में लॉगिन करने के लिए कर सकता है।**
|
||||
|
||||
> [!CAUTION]
|
||||
> इसलिए, यदि हमलावर उपयोगकर्ता को अपने OAuth ऐप तक पहुंच प्राप्त करने में सफल हो जाता है, तो वह उन ऐप्स में पीड़ित के खाते पर नियंत्रण प्राप्त कर सकेगा जो टोकन की अपेक्षा कर रहे हैं और यह नहीं जांचते कि टोकन उनके ऐप आईडी को दिया गया था या नहीं।
|
||||
|
||||
### Two links & cookie <a href="#bda5" id="bda5"></a>
|
||||
|
||||
[**इस लेख के अनुसार**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), यह संभव था कि एक पीड़ित एक पृष्ठ खोले जिसमें **returnUrl** हमलावर के होस्ट की ओर इशारा करता है। यह जानकारी **एक कुकी (RU)** में **स्टोर** की जाएगी और **बाद के चरण में** **प्रॉम्प्ट** **उपयोगकर्ता** से पूछेगा कि क्या वह उस हमलावर के होस्ट को एक्सेस देने के लिए चाहता है।
|
||||
[**इस लेख के अनुसार**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), यह संभव था कि एक पीड़ित एक पृष्ठ खोले जिसमें **returnUrl** हमलावर के होस्ट की ओर इशारा करता है। यह जानकारी **एक कुकी (RU)** में **स्टोर की जाएगी** और **बाद के चरण में** **प्रॉम्प्ट** **उपयोगकर्ता** से पूछेगा कि क्या वह उस हमलावर के होस्ट को एक्सेस देने के लिए तैयार है।
|
||||
|
||||
इस प्रॉम्प्ट को बायपास करने के लिए, यह संभव था कि एक टैब खोला जाए ताकि **Oauth प्रवाह** को आरंभ किया जा सके जो इस RU कुकी को **returnUrl** का उपयोग करके सेट करेगा, प्रॉम्प्ट दिखाए जाने से पहले टैब बंद करें, और बिना उस मान के एक नया टैब खोलें। फिर, **प्रॉम्प्ट हमलावर के होस्ट के बारे में जानकारी नहीं देगा**, लेकिन कुकी इसे सेट कर दी जाएगी, इसलिए **टोकन हमलावर के होस्ट** पर पुनर्निर्देशित किया जाएगा।
|
||||
इस प्रॉम्प्ट को बायपास करने के लिए, यह संभव था कि एक टैब खोला जाए ताकि **Oauth प्रवाह** को आरंभ किया जा सके जो इस RU कुकी को **returnUrl** का उपयोग करके सेट करेगा, प्रॉम्प्ट दिखाए जाने से पहले टैब बंद कर दें, और बिना उस मान के एक नया टैब खोलें। तब, **प्रॉम्प्ट हमलावर के होस्ट के बारे में सूचित नहीं करेगा**, लेकिन कुकी को इसके लिए सेट किया जाएगा, इसलिए **टोकन हमलावर के होस्ट को रीडायरेक्शन में भेजा जाएगा।**
|
||||
|
||||
### Prompt Interaction Bypass <a href="#bda5" id="bda5"></a>
|
||||
|
||||
जैसा कि [**इस वीडियो में समझाया गया है**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), कुछ OAuth कार्यान्वयन **`prompt`** GET पैरामीटर को None (**`&prompt=none`**) के रूप में इंगित करने की अनुमति देते हैं ताकि **उपयोगकर्ताओं को दिए गए एक्सेस की पुष्टि करने के लिए प्रॉम्प्ट में पूछा न जाए** यदि वे पहले से ही प्लेटफॉर्म में लॉगिन कर चुके हैं।
|
||||
जैसा कि [**इस वीडियो में समझाया गया है**](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=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 <a href="#b440" id="b440"></a>
|
||||
@ -186,9 +186,9 @@ https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-unauthenticat
|
||||
यह [**ब्लॉगपोस्ट**](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 के फ़्रैगमेंट** में वापस भेजा जाएगा जिससे वह पीड़ित साइट पर उपयोगकर्ता के खाते पर नियंत्रण प्राप्त कर सके।
|
||||
2. पीड़ित दुर्भावनापूर्ण लिंक खोलता है और एक ओपनर Google OAuth प्रवाह को `response_type=id_token,code&prompt=none` के रूप में अतिरिक्त पैरामीटर के साथ आरंभ करता है, **रेफरर के रूप में हमलावर की वेबसाइट** का उपयोग करते हुए।
|
||||
3. ओपनर में, जब प्रदाता पीड़ित को अधिकृत करता है, तो यह उन्हें `redirect_uri` पैरामीटर (पीड़ित वेब) के मान पर वापस भेजता है जिसमें 30X कोड होता है जो अभी भी रेफरर में हमलावर की वेबसाइट को बनाए रखता है।
|
||||
4. पीड़ित **वेबसाइट रेफरर के आधार पर ओपन रीडायरेक्ट को ट्रिगर करती है** जो पीड़ित उपयोगकर्ता को हमलावर की वेबसाइट पर रीडायरेक्ट करती है, क्योंकि **`respose_type`** **`id_token,code`** था, कोड हमलावर को **URL के फ़्रैगमेंट** में वापस भेजा जाएगा जिससे वह पीड़ित की साइट पर Google के माध्यम से उपयोगकर्ता के खाते पर नियंत्रण प्राप्त कर सके।
|
||||
|
||||
### SSRFs parameters <a href="#bda5" id="bda5"></a>
|
||||
|
||||
@ -199,12 +199,12 @@ OAuth में डायनामिक क्लाइंट रजिस्
|
||||
**मुख्य बिंदु:**
|
||||
|
||||
- **डायनामिक क्लाइंट रजिस्ट्रेशन** अक्सर `/register` पर मैप किया जाता है और इसमें `client_name`, `client_secret`, `redirect_uris`, और लोगो या JSON वेब कुंजी सेट (JWKs) के लिए URLs जैसे विवरण POST अनुरोधों के माध्यम से स्वीकार करता है।
|
||||
- यह सुविधा **RFC7591** और **OpenID कनेक्ट रजिस्ट्रेशन 1.0** में निर्धारित विनिर्देशों का पालन करती है, जिसमें ऐसे पैरामीटर शामिल हैं जो SSRF के प्रति संवेदनशील हो सकते हैं।
|
||||
- रजिस्ट्रेशन प्रक्रिया अनजाने में कई तरीकों से सर्वरों को SSRF के प्रति उजागर कर सकती है:
|
||||
- **`logo_uri`**: क्लाइंट ऐप्लिकेशन के लोगो के लिए एक URL जो सर्वर द्वारा प्राप्त किया जा सकता है, SSRF को ट्रिगर कर सकता है या यदि URL को गलत तरीके से संभाला गया तो XSS का कारण बन सकता है।
|
||||
- यह सुविधा **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 को प्राधिकरण प्रक्रिया की शुरुआत में प्राप्त करता है तो शोषित किया जा सकता है।
|
||||
- **`sector_identifier_uri`**: `redirect_uris` के JSON एरे को संदर्भित करता है, जिसे सर्वर लाने की संभावना है, जिससे SSRF का अवसर बनता है।
|
||||
- **`request_uris`**: क्लाइंट के लिए अनुमत अनुरोध URIs की सूची, जिन्हें यदि सर्वर इन URIs को प्राधिकरण प्रक्रिया की शुरुआत में लाता है तो शोषित किया जा सकता है।
|
||||
|
||||
**शोषण रणनीति:**
|
||||
|
||||
@ -215,9 +215,31 @@ OAuth में डायनामिक क्लाइंट रजिस्
|
||||
|
||||
यदि आप जिस प्लेटफॉर्म का परीक्षण कर रहे हैं वह एक 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}}
|
||||
|
||||
@ -10,7 +10,7 @@
|
||||
|
||||
Unicode सामान्यीकरण तब होता है जब **unicode वर्णों को ascii वर्णों में सामान्यीकृत** किया जाता है।
|
||||
|
||||
इस प्रकार की कमजोरी का एक सामान्य परिदृश्य तब होता है जब सिस्टम **उपयोगकर्ता के इनपुट को** किसी न किसी तरह **संशोधित** करता है **जांचने के बाद**। उदाहरण के लिए, कुछ भाषाओं में **इनपुट को बड़े या छोटे अक्षरों में** बनाने के लिए एक साधारण कॉल दिए गए इनपुट को सामान्यीकृत कर सकता है और **unicode ASCII में परिवर्तित** हो जाएगा, जिससे नए वर्ण उत्पन्न होंगे।\
|
||||
इस प्रकार की कमजोरी का एक सामान्य परिदृश्य तब होता है जब सिस्टम **उपयोगकर्ता के इनपुट को** किसी न किसी तरह **संशोधित** करता है **जांचने के बाद**। उदाहरण के लिए, कुछ भाषाओं में **इनपुट को अपरकेस या लोअरकेस** बनाने के लिए एक साधारण कॉल दिए गए इनपुट को सामान्यीकृत कर सकता है और **unicode ASCII में परिवर्तित** हो जाएगा, जिससे नए वर्ण उत्पन्न होंगे।\
|
||||
अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
@ -19,7 +19,7 @@ unicode-normalization.md
|
||||
|
||||
## `\u` to `%`
|
||||
|
||||
Unicode वर्ण आमतौर पर **`\u` उपसर्ग** के साथ प्रदर्शित होते हैं। उदाहरण के लिए, वर्ण `㱋` है `\u3c4b`([check it here](https://unicode-explorer.com/c/3c4B)). यदि एक बैकएंड **`\u` उपसर्ग को `%` में परिवर्तित** करता है, तो परिणामी स्ट्रिंग `%3c4b` होगी, जिसे URL डिकोड किया गया है: **`<4b`**। और, जैसा कि आप देख सकते हैं, एक **`<` वर्ण इंजेक्ट** किया गया है।\
|
||||
Unicode वर्ण आमतौर पर **`\u` उपसर्ग** के साथ प्रदर्शित होते हैं। उदाहरण के लिए, वर्ण `㱋` है `\u3c4b`([यहां जांचें](https://unicode-explorer.com/c/3c4B)). यदि एक बैकएंड **`\u` उपसर्ग को `%` में परिवर्तित** करता है, तो परिणामी स्ट्रिंग `%3c4b` होगी, जिसे URL डिकोड किया गया है: **`<4b`**। और, जैसा कि आप देख सकते हैं, एक **`<` वर्ण इंजेक्ट किया गया है**।\
|
||||
यदि बैकएंड कमजोर है तो आप इस तकनीक का उपयोग **किसी भी प्रकार के वर्ण को इंजेक्ट** करने के लिए कर सकते हैं।\
|
||||
आपको आवश्यक वर्ण खोजने के लिए [https://unicode-explorer.com/](https://unicode-explorer.com/) देखें।
|
||||
|
||||
@ -27,10 +27,10 @@ Unicode वर्ण आमतौर पर **`\u` उपसर्ग** के
|
||||
|
||||
## Emoji Injection
|
||||
|
||||
बैक-एंड कुछ अजीब तरीके से व्यवहार करते हैं जब वे **इमोजी प्राप्त करते हैं**। यही [**इस लेख**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209) में हुआ जहां शोधकर्ता ने एक पेलोड जैसे: `💋img src=x onerror=alert(document.domain)//💛` के साथ XSS प्राप्त करने में सफल रहा।
|
||||
बैक-एंड कुछ अजीब तरीके से व्यवहार करते हैं जब वे **इमोजी प्राप्त करते हैं**। यही [**इस लेख**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209) में हुआ, जहां शोधकर्ता ने एक पेलोड जैसे: `💋img src=x onerror=alert(document.domain)//💛` के साथ XSS प्राप्त करने में सफल रहा।
|
||||
|
||||
इस मामले में, त्रुटि यह थी कि सर्वर ने दुर्भावनापूर्ण वर्णों को हटाने के बाद **Windows-1252 से UTF-8 में UTF-8 स्ट्रिंग को परिवर्तित** किया (बुनियादी रूप से इनपुट एन्कोडिंग और एन्कोडिंग से परिवर्तित करने में असंगति)। फिर यह एक उचित < नहीं देता, केवल एक अजीब unicode: `‹`\
|
||||
``तो उन्होंने इस आउटपुट को लिया और **अब UTF-8 से ASCII में फिर से परिवर्तित किया**। इसने `‹` को ` < ` में **सामान्यीकृत** किया, इस प्रकार यह उस सिस्टम पर कैसे काम कर सकता था।\
|
||||
इस मामले में, त्रुटि यह थी कि सर्वर ने दुर्भावनापूर्ण वर्णों को हटाने के बाद **Windows-1252 से UTF-8 में UTF-8 स्ट्रिंग को परिवर्तित** किया (बुनियादी रूप से इनपुट एन्कोडिंग और एन्कोडिंग रूपांतरण असंगत थे)। फिर यह एक उचित < नहीं देता, केवल एक अजीब unicode: `‹`\
|
||||
``तो उन्होंने इस आउटपुट को लिया और **अब UTF-8 से ASCII में फिर से परिवर्तित किया**। इसने `‹` को ` < ` में **सामान्यीकृत** किया, यही कारण है कि यह प्रणाली पर एक्सप्लॉइट काम कर सका।\
|
||||
यह क्या हुआ:
|
||||
```php
|
||||
<?php
|
||||
@ -42,9 +42,23 @@ $str = iconv("UTF-8", "ASCII//TRANSLIT", $str);
|
||||
|
||||
echo "String: " . $str;
|
||||
```
|
||||
इमोजी सूचियाँ:
|
||||
Emoji lists:
|
||||
|
||||
- [https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv](https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv)
|
||||
- [https://unicode.org/emoji/charts-14.0/full-emoji-list.html](https://unicode.org/emoji/charts-14.0/full-emoji-list.html)
|
||||
|
||||
## Windows Best-Fit/Worst-fit
|
||||
|
||||
जैसा कि **[इस शानदार पोस्ट](https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/)** में बताया गया है, Windows में **Best-Fit** नामक एक विशेषता है जो **unicode वर्णों** को ASCII मोड में प्रदर्शित नहीं किया जा सकने वाले समान वर्णों से **बदल देती है**। इससे **अप्रत्याशित व्यवहार** हो सकता है जब बैकएंड **एक विशिष्ट वर्ण** की अपेक्षा करता है लेकिन उसे एक अलग वर्ण प्राप्त होता है।
|
||||
|
||||
**[https://worst.fit/mapping/](https://worst.fit/mapping/)** में सबसे अच्छे फिट वर्णों को ढूंढना संभव है।
|
||||
|
||||
चूंकि Windows आमतौर पर unicode स्ट्रिंग्स को ASCII स्ट्रिंग्स में निष्पादन के अंतिम भागों में परिवर्तित करता है (आमतौर पर "W" प्रत्यय वाले API से "A" प्रत्यय वाले API जैसे `GetEnvironmentVariableA` और `GetEnvironmentVariableW` में जाता है), यह हमलावरों को सुरक्षा को बायपास करने की अनुमति देगा, unicode वर्ण भेजकर जो अंततः ASCII वर्णों में परिवर्तित होंगे जो अप्रत्याशित क्रियाएँ करेंगे।
|
||||
|
||||
ब्लॉग पोस्ट में **काले सूची के वर्णों** का उपयोग करके कमजोरियों को बायपास करने के लिए प्रस्तावित विधियाँ हैं, [“/“ (0x2F)](https://worst.fit/mapping/#to%3A0x2f) के लिए मैप किए गए वर्णों का उपयोग करके **पथ यात्रा** का शोषण करना और [“\“ (0x5C)](https://worst.fit/mapping/#to%3A0x5c) के लिए मैप किए गए वर्णों का उपयोग करना या यहां तक कि PHP के `escapeshellarg` या Python के `subprocess.run` जैसे शेल एस्केप सुरक्षा को बायपास करना, यह उदाहरण के लिए **पूर्ण चौड़ाई के डबल उद्धरण (U+FF02)** का उपयोग करके किया गया था ताकि अंत में जो 1 तर्क जैसा दिखता था वह 2 तर्कों में परिवर्तित हो गया।
|
||||
|
||||
**ध्यान दें कि किसी ऐप को कमजोर होने के लिए "W" Windows APIs का उपयोग करना आवश्यक है लेकिन अंततः "A" Windows API को कॉल करना आवश्यक है ताकि unicode स्ट्रिंग का "Best-fit" बनाया जा सके।**
|
||||
|
||||
**कई खोजी गई कमजोरियों को ठीक नहीं किया जाएगा क्योंकि लोग इस मुद्दे को ठीक करने के लिए सहमत नहीं हैं।**
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user