* क्या आप किसी **साइबर सुरक्षा कंपनी** में काम करते हैं? क्या आप अपनी कंपनी को **हैकट्रिक्स में विज्ञापित** देखना चाहते हैं? या क्या आपको **PEASS की नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने का उपयोग** करने की इच्छा है? [**सदस्यता योजनाएं**](https://github.com/sponsors/carlospolop) की जांच करें!
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारा विशेष [**NFT संग्रह**](https://opensea.io/collection/the-peass-family)
* [**आधिकारिक PEASS & HackTricks swag**](https://peass.creator-spring.com) प्राप्त करें
* [**💬**](https://emojipedia.org/speech-balloon/) [**Discord समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) में **शामिल** हों या मुझे **Twitter** पर **फ़ॉलो** करें [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) का उपयोग करें और आसानी से **वर्कफ़्लो बनाएं** जो दुनिया के **सबसे उन्नत समुदाय उपकरणों** द्वारा संचालित होते हैं।\
यदि आपको कंपनी के एक डोमेन (domain.tld) का पता चलता है जो **स्कोप के भीतर किसी सेवा द्वारा उपयोग किया जा रहा है**, लेकिन **कंपनी** ने इसके **स्वामित्व** को खो दिया है, तो आप इसे **रजिस्टर** करने का प्रयास कर सकते हैं (यदि यह पर्याप्त सस्ता हो) और कंपनी को बता सकते हैं। यदि इस डोमेन के माध्यम से कुछ **संवेदनशील जानकारी** जैसे कि एक सत्र कुकी या **GET** पैरामीटर या **Referer** हैडर के माध्यम से प्राप्त हो रही है, तो यह निश्चित रूप से एक **सुरक्षा कमजोरी** है।
कंपनी का एक सबडोमेन एक **तृतीय-पक्ष सेवा को पॉइंट कर रहा है जिसका नाम पंजीकृत नहीं है**। यदि आप इस **तृतीय-पक्ष सेवा** में एक **खाता बना सकते हैं** और उपयोग में होने वाले **नाम** को **रजिस्टर** कर सकते हैं, तो आप सबडोमेन टेकओवर कर सकते हैं।
BBOT के डिफ़ॉल्ट सबडोमेन जाँच में सबडोमेन टेकओवर शामिल हैं। हस्ताक्षर सीधे [https://github.com/EdOverflow/can-i-take-over-xyz](https://github.com/EdOverflow/can-i-take-over-xyz) से लिए जाते हैं।
जब एक डोमेन में DNS वाइल्डकार्ड का उपयोग किया जाता है, तो उस डोमेन के किसी भी अनुरोधित सबडोमेन को जो कि विशेष रूप से अलग पता नहीं है, **एक ही जानकारी पर पहुंचाया जाएगा**। इसमें एक A IP पता, एक CNAME... हो सकता है।
हालांकि, यदि इसे एक IP पते की बजाय, सिसएडमिन इसे **CNAME के माध्यम से तीसरी पक्ष सेवा पर पॉइंट** करता है, जैसे कि एक **github सबडोमेन** उदाहरण के लिए (`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)
हाल ही में, मैंने [लिखा](https://0xpatrik.com/subdomain-takeover-basics/) है सबडोमेन टेकओवर के बारे में। हालांकि इस अवधारणा को अब सामान्य रूप से समझा जाता है, मुझे यह दिखा कि लोग सबडोमेन टेकओवर के लायक जोखिमों को समझने में अक्सर संघर्ष करते हैं। इस पोस्ट में, मैं गहराई से जाता हूँ और मेरे दृष्टिकोण से सबडोमेन टेकओवर के सबसे प्रमुख जोखिमों को कवर करता हूँ।
_नोट: कुछ जोखिमों को बादल प्रदाता ने स्वतः ही कम किया जाता है। उदाहरण के लिए, जब सबडोमेन टेकओवर अमेज़ॅन क्लाउडफ्रंट पर संभव होता है, तो आप SPF जांचों को छलना करने के लिए TXT रिकॉर्ड सेट कर सकते हैं। इसलिए, पोस्ट का उद्देश्य सामान्य सबडोमेन टेकओवर पर जोखिम प्रदान करना है। फिर भी, इनमें से अधिकांश क्लाउड प्रदाताओं पर लागू होते हैं।_
ध्यान दें कि चरण #7_sub.example.com_ की बजाय _anotherdomain.com_ का अनुरोध करता है। यह इसलिए है क्योंकि वेब ब्राउज़र को यह भी पता नहीं होता है कि _anotherdomain.com_ मौजूद है या नहीं। हालांकि CNAME रिकॉर्ड का उपयोग किया जाता है, ब्राउज़र के URL बार में अभी भी _sub.example.com_ होता है। यह ब्राउज़र के लिए **पारदर्शिता** है। इसके बारे में सोचें, ब्राउज़र डोमेन के बारे में सटीक जानकारी प्रदान करने के लिए DNS रिज़ॉल्वर पर पूरा विश्वास रखता है। सरलता से कहें तो, सबडोमेन टेकओवर इंटरनेट पर एक विशेष डोमेन के लिए DNS स्पूफिंग है। क्योंकि किसी भी असरित डोमेन पर DNS संकलन करने वाला ब्राउज़र एक हमलावर द्वारा सेट किए गए A रिकॉर्ड प्राप्त करता है। फिर ब्राउज़र खुशी-खुशी इस सर्वर से प्राप्त किसी भी जानकारी को दिखाता है (यह सोचता है कि यह वैध है)।
यह ब्राउज़र पारदर्शिता के साथ हाथ मिलाता है लेकिन इसके परिणाम अलग होते हैं। वेब ब्राउज़र खतरनाक वेबसाइटों को हानि पहुंचाने से रोकने के लिए कई सुरक्षा नीतियों को लागू करता है। इसमें [समान-मूल नीति](https://en.wikipedia.org/wiki/Same-origin\_policy) जैसी चीजें शामिल होती हैं। ब्राउज़र की प्राथमिक सुरक्षा जिम्मेदारी में सहेजे गए कुकीज़ को सुरक्षित करना शामिल होता है। क्यों? HTTP एक राष्ट्रहीन प्रोटोकॉल होता है, लेकिन कुकीज़ का उपयोग सत्रों को ट्रैक करने के लिए किया जाता है। सुविधा के लिए, उपयोगकर्ता अक्सर कुकीज़ को लंबे समय तक सहेजते हैं ताकि हर बार लॉगिन करने की जरूरत न हो। इन कुकीज़ को लॉगिन टोकन के रूप में उपयोग किया जाता है जो वेब सर्वर को प्रस्तुत किया जाता है और उपयोगकर्ता की पहचान होती है। [_सत्र हाइजैकिंग_](https://en.wikipedia.org/wiki/Session\_hijacking) जैसे हमले इसी अवधारणा से विकसित हुए हैं।
ब्राउज़र स्वचालित रूप से संग्रहीत कुकीज़ को हर अनुरोध के साथ प्रस्तुत करता है जो उन्हें जारी करने वाले डोमेन के लिए हैं। इसमें एक ऐसा अपवाद होता है कि कुकीज़ सबडोमेन के बीच साझा की जा सकती हैं ([यहां पढ़ें](https://tools.ietf.org/html/rfc6265#section-8.6), इसके अलावा ध्यान दें सेक्शन 8.7)। यह आमतौर पर तब होता है जब वेबसाइट कुकीज़-आधारित [एकल प्रवेश](https://en.wikipedia.org/wiki/Single\_sign-on) (SSO) प्रणाली का उपयोग करती है। SSO का उपयोग करके, उपयोगकर्ता एक सबडोमेन का उपयोग करके लॉगिन कर सकता है और एक विस्तृत सबडोमेन समूह के बीच समान सत्र टोकन साझा कर सकता है। एक नियमित कुकी सेट करने के लिए निम्नलिखित वाक्यांश का उपयोग किया जाता है:
यदि यह कुकी _example.com_ पर निवास करने वाले वेब सर्वर द्वारा जारी की जाती है, तो बाद में केवल यह सर्वर इस कुकी तक पहुंच सकता है। हालांकि, कुकी वाइल्डकार्ड डोमेन के लिए जारी की जा सकती है (ऊपर बताए गए कारणों के लिए) निम्नलिखित तरीके से:
कुकी HTTP अनुरोधों में _example.com_ के साथ शामिल होगी, लेकिन इसके अलावा _subdomain.example.com_ जैसे किसी भी उप-डोमेन में भी शामिल होगी। यह व्यवहार सबडोमेन टेकओवर का उपयोग करके उच्च गंभीरता वाले हमलों की संभावना बनाता है। मान लीजिए कि कुछ विशेष डोमेन वाइल्डकार्ड डोमेन के लिए सत्र कुकीज़ का उपयोग कर रहा है। यदि कोई सबडोमेन सबडोमेन टेकओवर के लिए संकटग्रस्त है, तो उपयोगकर्ता के सत्र टोकन को इकट्ठा करने के लिए उसे विकल्प सबडोमेन पर आमंत्रित करना होगा। सत्र कुकी HTTP अनुरोध के साथ स्वचालित रूप से भेजी जाती है।
* **HttpOnly कुकी** - कुकीज़ को डिफ़ॉल्ट रूप से वेबसाइट के संदर्भ में चल रहे जावास्क्रिप्ट कोड द्वारा एक्सेस किया जा सकता है जो कुकीज़ बनाने वाली वेबसाइट में चल रहा है। जावास्क्रिप्ट कुकीज़ को पढ़ सकता है, अपडेट कर सकता है और हटा सकता है। वेब सर्वर द्वारा सेट किए गए _HttpOnly_ कुकी फ़्लैग इसका संकेत देता है कि विशेष कुकी को जावास्क्रिप्ट कोड द्वारा एक्सेस नहीं किया जा सकता है। इसे केवल HTTP अनुरोध और प्रतिक्रिया हेडर के माध्यम से प्राप्त किया जा सकता है।
* **सुरक्षित कुकी** - जब कुकीज़ को वेब सर्वर द्वारा सेट किए गए _सुरक्षित_ फ़्लैग के साथ, तो इसे केवल जब HTTPS का उपयोग किया जाता है, वेब सर्वर को संदेश भेजा जा सकता है।
यदि डोमेन सबडोमेन टेकओवर के लिए संकटग्रस्त है, तो हमलावर उस डोमेन द्वारा जारी की गई कुकीज़ को आसानी से इकट्ठा कर सकता है, बस उपयोगकर्ता को विकल्प सबडोमेन पर आमंत्रित करना होगा। HttpOnly और सुरक्षित फ़्लैग मदद नहीं करते क्योंकि कुकी जावास्क्रिप्ट का उपयोग नहीं करके एक्सेस नहीं किया जा रहा है और लिया गया डोमेन के लिए SSL प्रमाणपत्र आसानी से उत्पन्न किया जा सकता है।
टेकओवर का उपयोग करके कुकी चोरी को अर्ने स्विनेन द्वारा बग बाउंटी [रिपोर्ट](https://hackerone.com/reports/172137) में समझाया गया था। रिपोर्ट में एक _Ubiquiti Networks_ सबडोमेन (_ping.ubnt.com_) की समस्या का वर्णन किया गया था। यह सबडोमेन सबडोमेन टेकओवर के लिए संकटग्रस्त था, जो अदावत नहीं किए गए AWS CloudFront वितरण को निशानित कर रहा था। Ubiquiti Networks वाइल्डकार्ड सत्र कुकीज़ के साथ SSO का उपयोग कर रहा है, इसलिए _ping.ubnt.com_ पर जाने वाले सभी उपयोगकर्ताओं की सत्र कुकीज़ चोरी हो सकती थी। हालांकि यह डोमेन AWS CloudFront को निशानित कर रहा है, CloudFront वितरण सेटिंग्स प्रत्येक अनुरोध के साथ कुकीज़ को लॉग करने की अनुमति देती हैं। इसलिए सभी सबडोमेन AWS CloudFront को निशानित करने के साथ भी सत्र कुकीज़ को निकालने की स्थिति पूरी तरह संभव है। 2017 में, अर्ने ने [उबर के SSO सिस्टम](https://www.arneswinnen.net/2017/06/authentication-bypass-on-ubers-sso-via-subdomain-takeover/) के खिलाफ समान हमला वेक्टर भी प्रदर्शित किया।
* **प्रभावित DNS रिकॉर्ड को हटाएं** - सबसे सरल समाधान है कि DNS ज़ोन से प्रभावित रिकॉर्ड को हटा दें। यह कदाचित संगठन के लिए उपयुक्त होता है जब संगठन निष्कर्ष करता है कि प्रभावित स्रोत डोमेन नाम अब आवश्यक नहीं है।
* **डोमेन नाम को दावा करें** - इसका अर्थ है कि विशेष बादल प्रदाता में पंजीकरण करना या एक साधारण इंटरनेट डोमेन के मामले में, समाप्त हो गए डोमेन को फिर से खरीदना।
भविष्य में सबडोमेन ले विरोध को रोकने के लिए, संगठनों को अपने अवसंरचना में संसाधनों को बनाने और नष्ट करने की प्रक्रिया में परिवर्तन करने की आवश्यकता होती है। संसाधन बनाने के मामले में, DNS रिकॉर्ड निर्माण को इस प्रक्रिया का _अंतिम कदम_ होना चाहिए। यह शर्त किसी भी समय डीएनएस रिकॉर्ड को एक अस्तित्वहीन डोमेन पर पहुंचाने से रोकती है। संसाधन नष्टि के मामले में, उल्टा होता है: DNS रिकॉर्ड को इस प्रक्रिया का _पहला कदम_ हटा देना चाहिए। [aquatone](https://github.com/michenriksen/aquatone) जैसे उपकरण सबडोमेन ले विरोध के लिए जांच शामिल करते हैं। संगठन की सुरक्षा टीम द्वारा यह जांच नियमित रूप से की जानी चाहिए कि कोई भी विकल्पशील डोमेन नहीं है। अधिकांश संगठनों में उज्ज्वल टीमों के कारण, उज्ज्वल डोमेन नामों के लिए केंद्रीय संग्रह की प्रक्रियाएं आमतौर पर प्रभावी नहीं होती हैं और बाहरी मॉनिटरिंग आमतौर पर सबसे अच्छा तरीका होता है।
बादल प्रदाताओं के लिए रोकथाम रणनीति को भी विचार किया जाना चाहिए। बादल सेवाएं डोमेन स्वामित्व की पुष्टि नहीं कर रही हैं। इसके पीछे का कारण प्राथमिकता की अवस्था है। बादल प्रदाता किसी भी स्रोत डोमेन नाम के स्वामित्व की पुष्टि नहीं करके कोई भी भयंकरता नहीं ला रहा है। इसलिए उपयोगकर्ता को अपने DNS रिकॉर्ड का मॉनिटरिंग करना होता है। एक और कारण यह है कि जब बादल संसाधन हटा दिया जाता है, तो उपयोगकर्ता आमतौर पर उस सेवा का ग्राहक नहीं रहता है। तो बादल प्रदाताओं का सवाल यह है: हमें इसे क्यों चिंता करनी चाहिए?
[GitLab](https://about.gitlab.com/2018/02/05/gitlab-pages-custom-domain-validation/) जैसे प्रदाताओं ने यह समझा कि सबडोमेन ले विरोध एक मुद्दा है और एक डोमेन सत्यापन मेकेनिज़्म को लागू किया है।
[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) का उपयोग करें और दुनिया के **सबसे उन्नत** समुदाय उपकरणों द्वारा संचालित **वर्कफ़्लो** आसानी से बनाएं और स्वचालित करें।\
* क्या आप किसी **साइबर सुरक्षा कंपनी** में काम करते हैं? क्या आप चाहते हैं कि आपकी **कंपनी HackTricks में विज्ञापित** की जाए? या क्या आप **PEASS के नवीनतम संस्करण का उपयोग करना चाहते हैं या HackTricks को PDF में डाउनलोड करना चाहते हैं**? [**सदस्यता योजनाएं**](https://github.com/sponsors/carlospolop) देखें!
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारा विशेष [**NFT**](https://opensea.io/collection/the-peass-family) संग्रह
* [**आधिकारिक PEASS & HackTricks swag**](https://peass.creator-spring.com) प्राप्त करें
* [**💬**](https://emojipedia.org/speech-balloon/) [**Discord समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) में **शामिल** हों या मुझे **ट्विटर** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)** का**
