mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/domain-subdomain-takeover.md', 'src/pent
This commit is contained in:
Translator
parent
2e4594e4dd
commit
2f115d9d33
@ -5,11 +5,11 @@
|
||||
|
||||
## Domain takeover
|
||||
|
||||
यदि आप किसी डोमेन (domain.tld) का पता लगाते हैं जो **किसी सेवा द्वारा उपयोग किया जा रहा है** लेकिन **कंपनी** ने **उसका स्वामित्व खो दिया है**, तो आप इसे **रजिस्टर** करने की कोशिश कर सकते हैं (यदि यह सस्ता हो) और कंपनी को सूचित कर सकते हैं। यदि यह डोमेन कुछ **संवेदनशील जानकारी** प्राप्त कर रहा है जैसे कि एक सत्र कुकी **GET** पैरामीटर के माध्यम से या **Referer** हेडर में, तो यह निश्चित रूप से एक **कमजोरी** है।
|
||||
यदि आप किसी डोमेन (domain.tld) का पता लगाते हैं जो **किसी सेवा द्वारा उपयोग किया जा रहा है** लेकिन **कंपनी** ने **उसका स्वामित्व खो दिया है**, तो आप इसे **पंजीकृत** करने की कोशिश कर सकते हैं (यदि यह सस्ता हो) और कंपनी को सूचित कर सकते हैं। यदि यह डोमेन कुछ **संवेदनशील जानकारी** प्राप्त कर रहा है जैसे कि एक सत्र कुकी **GET** पैरामीटर के माध्यम से या **Referer** हेडर में, तो यह निश्चित रूप से एक **कमजोरी** है।
|
||||
|
||||
### Subdomain takeover
|
||||
|
||||
कंपनी का एक उपडोमेन एक **तीसरे पक्ष की सेवा की ओर इशारा कर रहा है जिसका नाम पंजीकृत नहीं है**। यदि आप इस **तीसरे पक्ष की सेवा** में **खाता** **बनाने** और उपयोग में हो रहे **नाम** को **रजिस्टर** करने में सक्षम हैं, तो आप उपडोमेन टेकओवर कर सकते हैं।
|
||||
कंपनी का एक उपडोमेन **एक तीसरे पक्ष की सेवा की ओर इशारा कर रहा है जिसका नाम पंजीकृत नहीं है**। यदि आप इस **तीसरे पक्ष की सेवा** में **खाता** **बनाने** और उपयोग में हो रहे **नाम** को **पंजीकृत** कर सकते हैं, तो आप उपडोमेन टेकओवर कर सकते हैं।
|
||||
|
||||
संभावित टेकओवर की जांच के लिए कई उपकरण हैं जिनमें शब्दकोश होते हैं:
|
||||
|
||||
@ -29,19 +29,19 @@
|
||||
|
||||
### Subdomain Takeover Generation via DNS Wildcard
|
||||
|
||||
जब किसी डोमेन में DNS वाइल्डकार्ड का उपयोग किया जाता है, तो उस डोमेन का कोई भी अनुरोधित उपडोमेन जो स्पष्ट रूप से एक अलग पते की ओर इशारा नहीं करता है, उसे **एक ही जानकारी** पर **हल** किया जाएगा। यह एक A आईपी पता, एक CNAME हो सकता है...
|
||||
जब किसी डोमेन में DNS वाइल्डकार्ड का उपयोग किया जाता है, तो उस डोमेन का कोई भी अनुरोधित उपडोमेन जो स्पष्ट रूप से एक अलग पते पर नहीं है, **एक ही जानकारी** पर **हल किया जाएगा**। यह एक A आईपी पता, एक CNAME हो सकता है...
|
||||
|
||||
उदाहरण के लिए, यदि `*.testing.com` को `1.1.1.1` पर वाइल्डकार्ड किया गया है। तब, `not-existent.testing.com` `1.1.1.1` की ओर इशारा करेगा।
|
||||
|
||||
हालांकि, यदि आईपी पते की ओर इशारा करने के बजाय, सिस्टम प्रशासक इसे **CNAME के माध्यम से एक तीसरी पार्टी सेवा** की ओर इशारा करता है, जैसे कि एक G**ithub उपडोमेन** उदाहरण के लिए (`sohomdatta1.github.io`)। एक हमलावर **अपना खुद का तीसरा पक्ष का पृष्ठ** (इस मामले में Gihub में) बना सकता है और कह सकता है कि `something.testing.com` वहां इशारा कर रहा है। क्योंकि, **CNAME वाइल्डकार्ड** सहमत होगा कि हमलावर **अपने पृष्ठों की ओर इशारा करने वाले पीड़ित के डोमेन के लिए मनमाने उपडोमेन उत्पन्न करने में सक्षम होगा**।
|
||||
हालांकि, यदि आईपी पते की ओर इशारा करने के बजाय, सिस्टम प्रशासक इसे **CNAME के माध्यम से एक तीसरे पक्ष की सेवा** की ओर इशारा करता है, जैसे कि एक G**ithub उपडोमेन** उदाहरण के लिए (`sohomdatta1.github.io`)। एक हमलावर **अपना खुद का तीसरा पक्ष का पृष्ठ** (इस मामले में Gihub में) बना सकता है और कह सकता है कि `something.testing.com` वहां इशारा कर रहा है। क्योंकि, **CNAME वाइल्डकार्ड** सहमत होगा कि हमलावर **अपने पृष्ठों की ओर इशारा करने वाले पीड़ित के डोमेन के लिए मनमाने उपडोमेन उत्पन्न करने में सक्षम होगा**।
|
||||
|
||||
आप इस कमजोरी का एक उदाहरण CTF लेख में पा सकते हैं: [https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api](https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api)
|
||||
आप इस कमजोरी का एक उदाहरण CTF लेखन में पा सकते हैं: [https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api](https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api)
|
||||
|
||||
## Exploiting a subdomain takeover
|
||||
|
||||
उपडोमेन टेकओवर मूल रूप से इंटरनेट पर एक विशिष्ट डोमेन के लिए DNS धोखाधड़ी है, जिससे हमलावरों को एक डोमेन के लिए A रिकॉर्ड सेट करने की अनुमति मिलती है, जिससे ब्राउज़र हमलावर के सर्वर से सामग्री प्रदर्शित करते हैं। यह **पारदर्शिता** ब्राउज़रों में डोमेन को फ़िशिंग के प्रति संवेदनशील बनाती है। हमलावर [_typosquatting_](https://en.wikipedia.org/wiki/Typosquatting) या [_Doppelganger domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger) का उपयोग कर सकते हैं। विशेष रूप से संवेदनशील वे डोमेन हैं जहां फ़िशिंग ईमेल में URL वैध प्रतीत होता है, उपयोगकर्ताओं को धोखा देता है और डोमेन की अंतर्निहित विश्वसनीयता के कारण स्पैम फ़िल्टरों से बचता है।
|
||||
उपडोमेन टेकओवर मूल रूप से इंटरनेट पर एक विशिष्ट डोमेन के लिए DNS धोखाधड़ी है, जिससे हमलावरों को एक डोमेन के लिए A रिकॉर्ड सेट करने की अनुमति मिलती है, जिससे ब्राउज़र हमलावर के सर्वर से सामग्री प्रदर्शित करते हैं। यह **पारदर्शिता** ब्राउज़रों में डोमेन को फ़िशिंग के प्रति संवेदनशील बनाती है। हमलावर [_typosquatting_](https://en.wikipedia.org/wiki/Typosquatting) या [_Doppelganger domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger) का उपयोग कर सकते हैं। विशेष रूप से संवेदनशील वे डोमेन हैं जहां फ़िशिंग ईमेल में URL वैध प्रतीत होता है, उपयोगकर्ताओं को धोखा देता है और डोमेन की अंतर्निहित विश्वसनीयता के कारण स्पैम फ़िल्टर से बचता है।
|
||||
|
||||
इस [पोस्ट में आगे के विवरण के लिए](https://0xpatrik.com/subdomain-takeover/)
|
||||
इस [पोस्ट को आगे की जानकारी के लिए देखें](https://0xpatrik.com/subdomain-takeover/)
|
||||
|
||||
### **SSL Certificates**
|
||||
|
||||
@ -49,27 +49,43 @@ SSL प्रमाणपत्र, यदि हमलावरों द्व
|
||||
|
||||
### **Cookie Security and Browser Transparency**
|
||||
|
||||
ब्राउज़र की पारदर्शिता कुकी सुरक्षा तक भी फैली हुई है, जिसे [Same-origin policy](https://en.wikipedia.org/wiki/Same-origin_policy) जैसी नीतियों द्वारा नियंत्रित किया जाता है। कुकीज़, जो अक्सर सत्रों का प्रबंधन करने और लॉगिन टोकन को स्टोर करने के लिए उपयोग की जाती हैं, उपडोमेन टेकओवर के माध्यम से शोषित की जा सकती हैं। हमलावर **सत्र कुकीज़** को केवल उपयोगकर्ताओं को एक समझौता किए गए उपडोमेन पर निर्देशित करके एकत्र कर सकते हैं, जिससे उपयोगकर्ता डेटा और गोपनीयता को खतरा होता है।
|
||||
ब्राउज़र की पारदर्शिता कुकी सुरक्षा तक भी फैली हुई है, जिसे [Same-origin policy](https://en.wikipedia.org/wiki/Same-origin_policy) जैसी नीतियों द्वारा नियंत्रित किया जाता है। कुकीज़, जो अक्सर सत्रों का प्रबंधन करने और लॉगिन टोकन को स्टोर करने के लिए उपयोग की जाती हैं, उपडोमेन टेकओवर के माध्यम से शोषित की जा सकती हैं। हमलावर **सत्र कुकीज़** को केवल उपयोगकर्ताओं को एक समझौता किए गए उपडोमेन पर निर्देशित करके इकट्ठा कर सकते हैं, जिससे उपयोगकर्ता डेटा और गोपनीयता को खतरा होता है।
|
||||
|
||||
### CORS Bypass
|
||||
|
||||
यह संभव हो सकता है कि हर उपडोमेन को मुख्य डोमेन या अन्य उपडोमेन से CORS संसाधनों तक पहुंचने की अनुमति हो। इसका उपयोग एक हमलावर द्वारा **संवेदनशील जानकारी** तक पहुंचने के लिए CORS अनुरोधों का दुरुपयोग करने के लिए किया जा सकता है।
|
||||
|
||||
### CSRF - Same-Site Cookies bypass
|
||||
|
||||
यह संभव हो सकता है कि उपडोमेन को डोमेन या अन्य उपडोमेन को कुकीज़ भेजने की अनुमति हो, जिसे कुकीज़ के `Same-Site` विशेषता द्वारा रोका गया था। हालाँकि, ध्यान दें कि एंटी-CSRF टोकन अभी भी इस हमले को रोकेंगे यदि उन्हें सही तरीके से लागू किया गया हो।
|
||||
|
||||
### OAuth tokens redirect
|
||||
|
||||
यह संभव हो सकता है कि समझौता किया गया उपडोमेन OAuth प्रवाह के `redirect_uri` URL में उपयोग करने की अनुमति हो। इसका उपयोग एक हमलावर द्वारा **OAuth टोकन** चुराने के लिए किया जा सकता है।
|
||||
|
||||
### CSP Bypass
|
||||
|
||||
यह संभव हो सकता है कि समझौता किया गया उपडोमेन (या हर उपडोमेन) को CSP के `script-src` के लिए उपयोग करने की अनुमति हो। इसका उपयोग एक हमलावर द्वारा **दुष्ट स्क्रिप्टों को इंजेक्ट करने** और संभावित XSS कमजोरियों का दुरुपयोग करने के लिए किया जा सकता है।
|
||||
|
||||
### **Emails and Subdomain Takeover**
|
||||
|
||||
उपडोमेन टेकओवर का एक और पहलू ईमेल सेवाएँ हैं। हमलावर **MX रिकॉर्ड** में हेरफेर कर सकते हैं ताकि वे एक वैध उपडोमेन से ईमेल प्राप्त या भेज सकें, जिससे फ़िशिंग हमलों की प्रभावशीलता बढ़ती है।
|
||||
उपडोमेन टेकओवर का एक और पहलू ईमेल सेवाओं से संबंधित है। हमलावर **MX रिकॉर्ड** को हेरफेर कर सकते हैं ताकि वे एक वैध उपडोमेन से ईमेल प्राप्त या भेज सकें, जिससे फ़िशिंग हमलों की प्रभावशीलता बढ़ती है।
|
||||
|
||||
### **Higher Order Risks**
|
||||
|
||||
अन्य जोखिमों में **NS रिकॉर्ड टेकओवर** शामिल हैं। यदि एक हमलावर एक डोमेन के एक NS रिकॉर्ड पर नियंत्रण प्राप्त करता है, तो वे संभावित रूप से ट्रैफ़िक के एक हिस्से को अपने नियंत्रण में एक सर्वर की ओर निर्देशित कर सकते हैं। यदि हमलावर DNS रिकॉर्ड के लिए उच्च **TTL (Time to Live)** सेट करता है, तो यह जोखिम बढ़ जाता है, जिससे हमले की अवधि बढ़ जाती है।
|
||||
अन्य जोखिमों में **NS रिकॉर्ड टेकओवर** शामिल हैं। यदि एक हमलावर किसी डोमेन के एक NS रिकॉर्ड पर नियंत्रण प्राप्त करता है, तो वे संभावित रूप से ट्रैफ़िक के एक हिस्से को अपने नियंत्रण में सर्वर की ओर निर्देशित कर सकते हैं। यदि हमलावर DNS रिकॉर्ड के लिए उच्च **TTL (Time to Live)** सेट करता है, तो यह जोखिम बढ़ जाता है, जिससे हमले की अवधि बढ़ जाती है।
|
||||
|
||||
### CNAME Record Vulnerability
|
||||
|
||||
हमलावर उन अनियोजित CNAME रिकॉर्ड का शोषण कर सकते हैं जो अब उपयोग में नहीं हैं या जिन्हें बंद कर दिया गया है। इससे उन्हें विश्वसनीय डोमेन के तहत एक पृष्ठ बनाने की अनुमति मिलती है, जिससे फ़िशिंग या मैलवेयर वितरण को और बढ़ावा मिलता है।
|
||||
हमलावर उन अनक्लेम्ड CNAME रिकॉर्ड का शोषण कर सकते हैं जो अब उपयोग में नहीं हैं या जिन्हें बंद कर दिया गया है। इससे उन्हें विश्वसनीय डोमेन के तहत एक पृष्ठ बनाने की अनुमति मिलती है, जिससे फ़िशिंग या मैलवेयर वितरण को और बढ़ावा मिलता है।
|
||||
|
||||
### **Mitigation Strategies**
|
||||
|
||||
कमजोरियों को कम करने की रणनीतियों में शामिल हैं:
|
||||
|
||||
1. **कमजोर DNS रिकॉर्ड को हटाना** - यदि उपडोमेन की अब आवश्यकता नहीं है तो यह प्रभावी है।
|
||||
1. **कमजोर DNS रिकॉर्ड को हटाना** - यदि उपडोमेन अब आवश्यक नहीं है तो यह प्रभावी है।
|
||||
2. **डोमेन नाम का दावा करना** - संबंधित क्लाउड प्रदाता के साथ संसाधन को पंजीकृत करना या एक समाप्त डोमेन को फिर से खरीदना।
|
||||
3. **कमजोरियों के लिए नियमित निगरानी** - [aquatone](https://github.com/michenriksen/aquatone) जैसे उपकरण संवेदनशील डोमेन की पहचान करने में मदद कर सकते हैं। संगठनों को अपनी अवसंरचना प्रबंधन प्रक्रियाओं की भी समीक्षा करनी चाहिए, यह सुनिश्चित करते हुए कि DNS रिकॉर्ड निर्माण संसाधन निर्माण में अंतिम कदम और संसाधन विनाश में पहला कदम है।
|
||||
3. **कमजोरियों के लिए नियमित निगरानी** - [aquatone](https://github.com/michenriksen/aquatone) जैसे उपकरण संवेदनशील डोमेन की पहचान करने में मदद कर सकते हैं। संगठनों को अपनी अवसंरचना प्रबंधन प्रक्रियाओं की समीक्षा करनी चाहिए, यह सुनिश्चित करते हुए कि DNS रिकॉर्ड निर्माण संसाधन निर्माण में अंतिम कदम और संसाधन विनाश में पहला कदम है।
|
||||
|
||||
क्लाउड प्रदाताओं के लिए, डोमेन स्वामित्व की पुष्टि करना उपडोमेन टेकओवर को रोकने के लिए महत्वपूर्ण है। कुछ, जैसे कि [GitLab](https://about.gitlab.com/2018/02/05/gitlab-pages-custom-domain-validation/), ने इस समस्या को पहचाना है और डोमेन सत्यापन तंत्र लागू किए हैं।
|
||||
|
||||
@ -77,5 +93,6 @@ SSL प्रमाणपत्र, यदि हमलावरों द्व
|
||||
|
||||
- [https://0xpatrik.com/subdomain-takeover/](https://0xpatrik.com/subdomain-takeover/)
|
||||
- [https://www.stratussecurity.com/post/subdomain-takeover-guide](https://www.stratussecurity.com/post/subdomain-takeover-guide)
|
||||
- [https://www.hackerone.com/blog/guide-subdomain-takeovers-20](https://www.hackerone.com/blog/guide-subdomain-takeovers-20)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
|
||||
## Cookie Attributes
|
||||
|
||||
कुकीज़ कई विशेषताओं के साथ आती हैं जो उपयोगकर्ता के ब्राउज़र में उनके व्यवहार को नियंत्रित करती हैं। यहाँ इन विशेषताओं का एक संक्षिप्त विवरण है:
|
||||
कुकीज़ कई विशेषताओं के साथ आती हैं जो उपयोगकर्ता के ब्राउज़र में उनके व्यवहार को नियंत्रित करती हैं। यहाँ इन विशेषताओं का एक संक्षिप्त विवरण दिया गया है:
|
||||
|
||||
### Expires and Max-Age
|
||||
|
||||
@ -28,9 +28,9 @@
|
||||
### SameSite
|
||||
|
||||
- `SameSite` विशेषता यह निर्धारित करती है कि क्या कुकीज़ तीसरे पक्ष के डोमेन से उत्पन्न अनुरोधों पर भेजी जाती हैं। यह तीन सेटिंग्स प्रदान करती है:
|
||||
- **Strict**: तीसरे पक्ष के अनुरोधों पर कुकी भेजने से रोकता है।
|
||||
- **Lax**: तीसरे पक्ष की वेबसाइटों द्वारा आरंभ किए गए GET अनुरोधों के साथ कुकी भेजने की अनुमति देता है।
|
||||
- **None**: किसी भी तीसरे पक्ष के डोमेन से कुकी भेजने की अनुमति देता है।
|
||||
- **Strict**: तीसरे पक्ष के अनुरोधों पर कुकी को भेजने से रोकता है।
|
||||
- **Lax**: तीसरे पक्ष की वेबसाइटों द्वारा आरंभ किए गए GET अनुरोधों के साथ कुकी को भेजने की अनुमति देता है।
|
||||
- **None**: किसी भी तीसरे पक्ष के डोमेन से कुकी को भेजने की अनुमति देता है।
|
||||
|
||||
याद रखें, कुकीज़ को कॉन्फ़िगर करते समय, इन विशेषताओं को समझना यह सुनिश्चित करने में मदद कर सकता है कि वे विभिन्न परिदृश्यों में अपेक्षित रूप से व्यवहार करें।
|
||||
|
||||
@ -45,7 +45,7 @@
|
||||
| Image | \<img src="..."> | NetSet\*, None |
|
||||
|
||||
Table from [Invicti](https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/) and slightly modified.\
|
||||
एक कुकी जिसमें _**SameSite**_ विशेषता होगी, **CSRF हमलों को कम करेगी** जहाँ एक लॉग इन सत्र की आवश्यकता होती है।
|
||||
एक कुकी जिसमें _**SameSite**_ विशेषता होगी **CSRF हमलों को कम करेगी** जहाँ एक लॉग इन सत्र की आवश्यकता होती है।
|
||||
|
||||
**\*ध्यान दें कि Chrome80 (फरवरी/2019) से बिना कुकी सैमसाइट** **विशेषता वाली कुकी का डिफ़ॉल्ट व्यवहार लक्स होगा** ([https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/](https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/)).\
|
||||
ध्यान दें कि अस्थायी रूप से, इस परिवर्तन को लागू करने के बाद, **Chrome में बिना SameSite** **नीति वाली कुकीज़ को **पहले 2 मिनट के लिए None** के रूप में **व्यवहार किया जाएगा और फिर शीर्ष स्तर के क्रॉस-साइट POST अनुरोध के लिए Lax के रूप में।**
|
||||
@ -93,7 +93,7 @@ cookie-jar-overflow.md
|
||||
|
||||
<figure><img src="../../images/image (6) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
या PHP में कुकी नाम के प्रारंभ में **अन्य वर्ण जोड़ना** संभव था जो **अंडरस्कोर** वर्णों द्वारा **बदल दिए जाएंगे**, जिससे `__HOST-` कुकीज़ को ओवरराइट करने की अनुमति मिलती है:
|
||||
या PHP में कुकी नाम के प्रारंभ में **अन्य वर्ण जोड़ना** संभव था जो **अंडरस्कोर** वर्णों द्वारा **बदले जाएंगे**, जिससे `__HOST-` कुकीज़ को ओवरराइट करने की अनुमति मिलती है:
|
||||
|
||||
<figure><img src="../../images/image (7) (1) (1) (1) (1).png" alt="" width="373"><figcaption></figcaption></figure>
|
||||
|
||||
@ -113,7 +113,7 @@ cookie-jar-overflow.md
|
||||
|
||||
इस परिदृश्य में, एक हमलावर एक पीड़ित को एक विशिष्ट कुकी का उपयोग करके लॉग इन करने के लिए धोखा देता है। यदि एप्लिकेशन लॉगिन पर एक नई कुकी असाइन नहीं करता है, तो हमलावर, जो मूल कुकी रखता है, पीड़ित का अनुकरण कर सकता है। यह तकनीक इस पर निर्भर करती है कि पीड़ित हमलावर द्वारा प्रदान की गई कुकी के साथ लॉग इन करता है।
|
||||
|
||||
यदि आपने एक **XSS एक उपडोमेन में** पाया है या आप **एक उपडोमेन को नियंत्रित करते हैं**, तो पढ़ें:
|
||||
यदि आपने एक **XSS एक उपडोमेन में** पाया है या आप **एक उपडोमेन को नियंत्रित करते हैं**, पढ़ें:
|
||||
|
||||
{{#ref}}
|
||||
cookie-tossing.md
|
||||
@ -123,7 +123,7 @@ cookie-tossing.md
|
||||
|
||||
यहाँ, हमलावर पीड़ित को हमलावर की सत्र कुकी का उपयोग करने के लिए मनाता है। पीड़ित, यह मानते हुए कि वे अपने खाते में लॉग इन हैं, अनजाने में हमलावर के खाते के संदर्भ में क्रियाएँ करेगा।
|
||||
|
||||
यदि आपने एक **XSS एक उपडोमेन में** पाया है या आप **एक उपडोमेन को नियंत्रित करते हैं**, तो पढ़ें:
|
||||
यदि आपने एक **XSS एक उपडोमेन में** पाया है या आप **एक उपडोमेन को नियंत्रित करते हैं**, पढ़ें:
|
||||
|
||||
{{#ref}}
|
||||
cookie-tossing.md
|
||||
@ -137,11 +137,11 @@ JWT में संभावित दोषों को समझाने
|
||||
|
||||
### Cross-Site Request Forgery (CSRF)
|
||||
|
||||
यह हमला एक लॉग इन उपयोगकर्ता को एक वेब एप्लिकेशन पर अवांछित क्रियाएँ करने के लिए मजबूर करता है जिसमें वे वर्तमान में प्रमाणित हैं। हमलावर उन कुकीज़ का लाभ उठा सकते हैं जो कमजोर साइट पर हर अनुरोध के साथ स्वचालित रूप से भेजी जाती हैं।
|
||||
यह हमला एक लॉग इन उपयोगकर्ता को एक वेब एप्लिकेशन पर अवांछित क्रियाएँ करने के लिए मजबूर करता है जिसमें वे वर्तमान में प्रमाणित हैं। हमलावर उन कुकीज़ का लाभ उठा सकते हैं जो हर अनुरोध के साथ स्वचालित रूप से कमजोर साइट पर भेजी जाती हैं।
|
||||
|
||||
### Empty Cookies
|
||||
|
||||
(अधिक विवरण के लिए [मूल शोध](https://blog.ankursundara.com/cookie-bugs/) देखें) ब्राउज़रों को बिना नाम वाली कुकीज़ बनाने की अनुमति है, जिसे JavaScript के माध्यम से इस प्रकार प्रदर्शित किया जा सकता है:
|
||||
(अधिक विवरण के लिए [मूल शोध](https://blog.ankursundara.com/cookie-bugs/) देखें) ब्राउज़रों को बिना नाम वाली कुकीज़ बनाने की अनुमति होती है, जिसे JavaScript के माध्यम से इस प्रकार प्रदर्शित किया जा सकता है:
|
||||
```js
|
||||
document.cookie = "a=v1"
|
||||
document.cookie = "=test value;" // Setting an empty named cookie
|
||||
@ -157,9 +157,9 @@ setCookie("", "a=b") // Setting the empty cookie modifies another cookie's value
|
||||
```
|
||||
यह ब्राउज़र को एक कुकी हेडर भेजने की ओर ले जाता है जिसे हर वेब सर्वर द्वारा `a` नाम की कुकी के रूप में और `b` मान के साथ व्याख्यायित किया जाता है।
|
||||
|
||||
#### Chrome Bug: Unicode Surrogate Codepoint Issue
|
||||
#### Chrome बग: यूनिकोड सरोगेट कोडपॉइंट समस्या
|
||||
|
||||
Chrome में, यदि एक Unicode surrogate codepoint सेट कुकी का हिस्सा है, तो `document.cookie` भ्रष्ट हो जाता है, और इसके बाद एक खाली स्ट्रिंग लौटाता है:
|
||||
Chrome में, यदि एक यूनिकोड सरोगेट कोडपॉइंट सेट कुकी का हिस्सा है, तो `document.cookie` भ्रष्ट हो जाता है, और इसके बाद एक खाली स्ट्रिंग लौटाता है:
|
||||
```js
|
||||
document.cookie = "\ud800=meep"
|
||||
```
|
||||
@ -175,17 +175,43 @@ RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";
|
||||
|
||||
(Check further details in the[original research](https://blog.ankursundara.com/cookie-bugs/)) सर्वरों द्वारा कुकीज़ का गलत पार्सिंग, विशेष रूप से Undertow, Zope, और जो Python के `http.cookie.SimpleCookie` और `http.cookie.BaseCookie` का उपयोग करते हैं, कुकी इंजेक्शन हमलों के लिए अवसर पैदा करता है। ये सर्वर नए कुकीज़ की शुरुआत को सही तरीके से सीमित नहीं करते, जिससे हमलावरों को कुकीज़ को स्पूफ करने की अनुमति मिलती है:
|
||||
|
||||
- Undertow एक उद्धृत मान के तुरंत बाद एक नए कुकी की अपेक्षा करता है बिना सेमीकोलन के।
|
||||
- Zope अगले कुकी को पार्स करने के लिए एक अल्पविराम की तलाश करता है।
|
||||
- Undertow एक उद्धृत मान के तुरंत बाद एक नई कुकी की अपेक्षा करता है बिना सेमीकोलन के।
|
||||
- Zope अगली कुकी को पार्स करने के लिए एक अल्पविराम की तलाश करता है।
|
||||
- Python की कुकी कक्षाएँ एक स्पेस कैरेक्टर पर पार्सिंग शुरू करती हैं।
|
||||
|
||||
यह कमजोरियाँ विशेष रूप से उन वेब अनुप्रयोगों में खतरनाक हैं जो कुकी-आधारित CSRF सुरक्षा पर निर्भर करते हैं, क्योंकि यह हमलावरों को स्पूफ किए गए CSRF-टोकन कुकीज़ इंजेक्ट करने की अनुमति देता है, जो सुरक्षा उपायों को बायपास कर सकता है। समस्या Python के डुप्लिकेट कुकी नामों के प्रबंधन से बढ़ जाती है, जहां अंतिम घटना पहले वाले को ओवरराइड कर देती है। यह असुरक्षित संदर्भों में `__Secure-` और `__Host-` कुकीज़ के लिए चिंताएँ भी उठाता है और जब कुकीज़ को बैक-एंड सर्वरों पर भेजा जाता है जो स्पूफिंग के प्रति संवेदनशील होते हैं, तो यह प्राधिकरण बायपास का कारण बन सकता है।
|
||||
यह कमजोरी विशेष रूप से उन वेब अनुप्रयोगों में खतरनाक है जो कुकी-आधारित CSRF सुरक्षा पर निर्भर करते हैं, क्योंकि यह हमलावरों को स्पूफ किए गए CSRF-टोकन कुकीज़ इंजेक्ट करने की अनुमति देती है, जो सुरक्षा उपायों को बायपास कर सकती है। समस्या Python के डुप्लिकेट कुकी नामों के प्रबंधन से बढ़ जाती है, जहां अंतिम घटना पहले वाले को ओवरराइड कर देती है। यह `__Secure-` और `__Host-` कुकीज़ के लिए असुरक्षित संदर्भों में चिंताएँ भी उठाती है और जब कुकीज़ को बैक-एंड सर्वरों पर भेजा जाता है जो स्पूफिंग के प्रति संवेदनशील होते हैं, तो यह प्राधिकरण बायपास का कारण बन सकती है।
|
||||
|
||||
### कुकीज़ $version और WAF बायपास
|
||||
### कुकीज़ $version
|
||||
|
||||
According to [**this blogpost**](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie), यह संभव हो सकता है कि कुकी विशेषता **`$Version=1`** का उपयोग करके बैकएंड को कुकी पार्स करने के लिए पुरानी लॉजिक का उपयोग करने के लिए मजबूर किया जा सके, **RFC2109** के कारण। इसके अलावा, अन्य मान जैसे **`$Domain`** और **`$Path`** का उपयोग बैकएंड के व्यवहार को कुकी के साथ संशोधित करने के लिए किया जा सकता है।
|
||||
#### WAF बायपास
|
||||
|
||||
#### उद्धृत-शब्द एन्कोडिंग के साथ बायपासिंग मान विश्लेषण
|
||||
[**इस ब्लॉगपोस्ट**](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie) के अनुसार, यह संभव हो सकता है कि कुकी विशेषता **`$Version=1`** का उपयोग करके बैकएंड को कुकी पार्स करने के लिए पुरानी लॉजिक का उपयोग करने के लिए मजबूर किया जा सके, **RFC2109** के कारण। इसके अलावा, अन्य मान जैसे **`$Domain`** और **`$Path`** का उपयोग बैकएंड के व्यवहार को कुकी के साथ संशोधित करने के लिए किया जा सकता है।
|
||||
|
||||
#### कुकी सैंडविच हमला
|
||||
|
||||
[**इस ब्लॉगपोस्ट**](https://portswigger.net/research/stealing-httponly-cookies-with-the-cookie-sandwich-technique) के अनुसार, HttpOnly कुकीज़ चुराने के लिए कुकी सैंडविच तकनीक का उपयोग करना संभव है। ये आवश्यकताएँ और कदम हैं:
|
||||
|
||||
- एक जगह खोजें जहाँ एक स्पष्ट रूप से बेकार **कुकी प्रतिक्रिया में परिलक्षित होती है**
|
||||
- **`$Version`** नाम की एक कुकी बनाएं जिसका मान `1` हो (आप इसे JS से XSS हमले में कर सकते हैं) एक अधिक विशिष्ट पथ के साथ ताकि यह प्रारंभिक स्थिति प्राप्त कर सके (कुछ फ्रेमवर्क जैसे Python को इस कदम की आवश्यकता नहीं होती)
|
||||
- **उस कुकी को बनाएं जो परिलक्षित होती है** जिसका मान **खुले डबल कोट्स** को छोड़ता है और एक विशिष्ट पथ के साथ ताकि यह पिछले वाले (`$Version`) के बाद कुकी डेटाबेस में स्थित हो
|
||||
- फिर, वैध कुकी क्रम में अगली होगी
|
||||
- **एक डमी कुकी बनाएं जो डबल कोट्स को अपने मान के अंदर बंद करती है**
|
||||
|
||||
इस तरह, पीड़ित कुकी नए कुकी संस्करण 1 के अंदर फंस जाती है और जब भी यह परिलक्षित होती है, यह परिलक्षित हो जाएगी।
|
||||
e.g. from the post:
|
||||
```javascript
|
||||
document.cookie = `$Version=1;`;
|
||||
document.cookie = `param1="start`;
|
||||
// any cookies inside the sandwich will be placed into param1 value server-side
|
||||
document.cookie = `param2=end";`;
|
||||
```
|
||||
### WAF बायपास
|
||||
|
||||
#### कुकीज़ $version
|
||||
|
||||
पिछले अनुभाग की जांच करें।
|
||||
|
||||
#### उद्धृत-स्ट्रींग एन्कोडिंग के साथ मान विश्लेषण को बायपास करना
|
||||
|
||||
यह पार्सिंग कुकीज़ के अंदर एस्केप किए गए मानों को अनएस्केप करने का संकेत देती है, इसलिए "\a" "a" बन जाता है। यह WAFS को बायपास करने के लिए उपयोगी हो सकता है जैसे:
|
||||
|
||||
@ -194,7 +220,7 @@ According to [**this blogpost**](https://portswigger.net/research/bypassing-wafs
|
||||
|
||||
#### कुकी-नाम ब्लॉकलिस्ट को बायपास करना
|
||||
|
||||
RFC2109 में यह संकेत दिया गया है कि **कुकी मानों के बीच अल्पविराम का उपयोग किया जा सकता है**। और यह भी संभव है कि **बराबर के चिन्ह के पहले और बाद में स्पेस और टैब जोड़े जाएं**। इसलिए एक कुकी जैसे `$Version=1; foo=bar, abc = qux` कुकी `"foo":"bar, admin = qux"` उत्पन्न नहीं करता है बल्कि कुकीज़ `foo":"bar"` और `"admin":"qux"` उत्पन्न करता है। ध्यान दें कि 2 कुकीज़ उत्पन्न होती हैं और कैसे admin के बराबर के चिन्ह के पहले और बाद में स्पेस हटा दिया गया है।
|
||||
RFC2109 में यह संकेत दिया गया है कि **कुकी मानों के बीच में एक कॉमा को सेपरेटर के रूप में उपयोग किया जा सकता है**। और यह भी संभव है कि **बराबर के चिन्ह के पहले और बाद में स्पेस और टैब जोड़े जाएं**। इसलिए एक कुकी जैसे `$Version=1; foo=bar, abc = qux` कुकी `"foo":"bar, admin = qux"` उत्पन्न नहीं करती बल्कि कुकीज़ `foo":"bar"` और `"admin":"qux"` उत्पन्न करती है। ध्यान दें कि 2 कुकीज़ उत्पन्न होती हैं और कैसे admin के बराबर के चिन्ह के पहले और बाद में स्पेस हटा दिया गया है।
|
||||
|
||||
#### कुकी विभाजन के साथ मान विश्लेषण को बायपास करना
|
||||
|
||||
@ -218,7 +244,7 @@ Resulting cookie: name=eval('test//, comment') => allowed
|
||||
|
||||
- **कुकी** हर बार जब आप **लॉगिन** करते हैं, **एक जैसी** होती है।
|
||||
- लॉग आउट करें और उसी कुकी का उपयोग करने की कोशिश करें।
|
||||
- एक ही खाते में 2 उपकरणों (या ब्राउज़रों) के साथ उसी कुकी का उपयोग करके लॉग इन करने की कोशिश करें।
|
||||
- एक ही खाते में 2 उपकरणों (या ब्राउज़रों) के साथ उसी कुकी का उपयोग करके लॉगिन करने की कोशिश करें।
|
||||
- जांचें कि क्या कुकी में कोई जानकारी है और इसे संशोधित करने की कोशिश करें।
|
||||
- लगभग समान उपयोगकर्ता नाम के साथ कई खाते बनाने की कोशिश करें और देखें कि क्या आप समानताएँ देख सकते हैं।
|
||||
- यदि "**मुझे याद रखें**" विकल्प मौजूद है, तो देखें कि यह कैसे काम करता है। यदि यह मौजूद है और संवेदनशील हो सकता है, तो हमेशा **मुझे याद रखें** की कुकी का उपयोग करें बिना किसी अन्य कुकी के।
|
||||
@ -226,10 +252,10 @@ Resulting cookie: name=eval('test//, comment') => allowed
|
||||
|
||||
#### **उन्नत कुकीज हमले**
|
||||
|
||||
यदि कुकी लॉग इन करते समय समान (या लगभग समान) रहती है, तो इसका मतलब शायद यह है कि कुकी आपके खाते के किसी क्षेत्र से संबंधित है (संभवतः उपयोगकर्ता नाम)। फिर आप कर सकते हैं:
|
||||
यदि कुकी लॉगिन करते समय समान (या लगभग समान) रहती है, तो इसका मतलब शायद यह है कि कुकी आपके खाते के किसी क्षेत्र से संबंधित है (संभवतः उपयोगकर्ता नाम)। फिर आप कर सकते हैं:
|
||||
|
||||
- बहुत सारे **खाते** बनाने की कोशिश करें जिनके उपयोगकर्ता नाम बहुत **समान** हैं और यह अनुमान लगाने की कोशिश करें कि एल्गोरिदम कैसे काम कर रहा है।
|
||||
- **उपयोगकर्ता नाम को ब्रूटफोर्स** करने की कोशिश करें। यदि कुकी केवल आपके उपयोगकर्ता नाम के लिए प्रमाणीकरण विधि के रूप में सहेजी जाती है, तो आप "**Bmin**" उपयोगकर्ता नाम के साथ एक खाता बना सकते हैं और अपनी कुकी के हर एक **बिट** को **ब्रूटफोर्स** कर सकते हैं क्योंकि आप जो कुकी आजमाएंगे उनमें से एक "**admin**" की होगी।
|
||||
- बहुत सारे **खाते** बनाने की कोशिश करें जिनके उपयोगकर्ता नाम बहुत **समान** हैं और अनुमान लगाने की कोशिश करें कि एल्गोरिदम कैसे काम कर रहा है।
|
||||
- **उपयोगकर्ता नाम को ब्रूटफोर्स** करने की कोशिश करें। यदि कुकी केवल आपके उपयोगकर्ता नाम के लिए एक प्रमाणीकरण विधि के रूप में सहेजी जाती है, तो आप "**Bmin**" उपयोगकर्ता नाम के साथ एक खाता बना सकते हैं और अपनी कुकी के हर एक **बिट** को **ब्रूटफोर्स** कर सकते हैं क्योंकि आप जो कुकी आजमाएंगे उनमें से एक "**admin**" की होगी।
|
||||
- **पैडिंग** **ओरकल** की कोशिश करें (आप कुकी की सामग्री को डिक्रिप्ट कर सकते हैं)। **पैडबस्टर** का उपयोग करें।
|
||||
|
||||
**पैडिंग ओरकल - पैडबस्टर उदाहरण**
|
||||
@ -254,13 +280,13 @@ padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lB
|
||||
|
||||
**CBC-MAC**
|
||||
|
||||
शायद एक कुकी में कुछ मान हो सकता है और इसे CBC का उपयोग करके साइन किया जा सकता है। फिर, मान की अखंडता उस हस्ताक्षर द्वारा होती है जो उसी मान के साथ CBC का उपयोग करके बनाया गया है। चूंकि IV के रूप में एक शून्य वेक्टर का उपयोग करने की सिफारिश की जाती है, यह प्रकार की अखंडता जांच कमजोर हो सकती है।
|
||||
शायद एक कुकी में कुछ मान हो सकता है और इसे CBC का उपयोग करके साइन किया जा सकता है। फिर, मान की अखंडता वही हस्ताक्षर है जो उसी मान के साथ CBC का उपयोग करके बनाया गया है। चूंकि IV के रूप में एक शून्य वेक्टर का उपयोग करने की सिफारिश की जाती है, इसलिए इस प्रकार की अखंडता जांच कमजोर हो सकती है।
|
||||
|
||||
**हमला**
|
||||
|
||||
1. उपयोगकर्ता नाम का हस्ताक्षर प्राप्त करें **administ** = **t**
|
||||
2. उपयोगकर्ता नाम का हस्ताक्षर प्राप्त करें **rator\x00\x00\x00 XOR t** = **t'**
|
||||
3. कुकी में मान सेट करें **administrator+t'** (**t'** **(rator\x00\x00\x00 XOR t) XOR t** का एक मान्य हस्ताक्षर होगा = **rator\x00\x00\x00**
|
||||
1. उपयोगकर्ता नाम **administ** का हस्ताक्षर प्राप्त करें = **t**
|
||||
2. उपयोगकर्ता नाम **rator\x00\x00\x00 XOR t** का हस्ताक्षर प्राप्त करें = **t'**
|
||||
3. कुकी में मान सेट करें **administrator+t'** (**t'** एक मान्य हस्ताक्षर होगा **(rator\x00\x00\x00 XOR t) XOR t** = **rator\x00\x00\x00**
|
||||
|
||||
**ECB**
|
||||
|
||||
@ -271,7 +297,7 @@ padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lB
|
||||
|
||||
लगभग समान डेटा (उपयोगकर्ता नाम, पासवर्ड, ईमेल, आदि) के साथ 2 उपयोगकर्ता बनाएं और दिए गए कुकी के अंदर कुछ पैटर्न खोजने की कोशिश करें।
|
||||
|
||||
उदाहरण के लिए "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" नाम का एक उपयोगकर्ता बनाएं और देखें कि क्या कुकी में कोई पैटर्न है (चूंकि ECB हर ब्लॉक को एक ही कुंजी के साथ एन्क्रिप्ट करता है, यदि उपयोगकर्ता नाम एन्क्रिप्ट किया गया है तो समान एन्क्रिप्टेड बाइट्स दिखाई दे सकते हैं)।
|
||||
उदाहरण के लिए "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" नाम का एक उपयोगकर्ता बनाएं और देखें कि क्या कुकी में कोई पैटर्न है (चूंकि ECB हर ब्लॉक के लिए समान कुंजी के साथ एन्क्रिप्ट करता है, यदि उपयोगकर्ता नाम एन्क्रिप्ट किया गया है तो समान एन्क्रिप्टेड बाइट्स दिखाई दे सकते हैं)।
|
||||
|
||||
एक पैटर्न होना चाहिए (एक उपयोग किए गए ब्लॉक के आकार के साथ)। इसलिए, यह जानकर कि "a" का एक समूह कैसे एन्क्रिप्ट किया गया है, आप एक उपयोगकर्ता नाम बना सकते हैं: "a"\*(ब्लॉक का आकार)+"admin"। फिर, आप कुकी से "a" के एक ब्लॉक के एन्क्रिप्टेड पैटर्न को हटा सकते हैं। और आपके पास उपयोगकर्ता नाम "admin" की कुकी होगी।
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user