Learn & practice AWS Hacking:<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">\
Learn & practice GCP Hacking: <imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
Cross-Origin Resource Sharing (CORS) मानक **सर्वरों को यह परिभाषित करने की अनुमति देता है कि कौन उनके संसाधनों तक पहुँच सकता है** और **कौन से HTTP अनुरोध विधियाँ बाहरी स्रोतों से अनुमत हैं**।
एक **same-origin** नीति यह अनिवार्य करती है कि एक **सर्वर जो** एक संसाधन का अनुरोध कर रहा है और वह सर्वर जो **संसाधन** होस्ट कर रहा है, एक ही प्रोटोकॉल (जैसे, `http://`), डोमेन नाम (जैसे, `internal-web.com`), और **पोर्ट** (जैसे, 80) साझा करें। इस नीति के तहत, केवल एक ही डोमेन और पोर्ट से वेब पृष्ठों को संसाधनों तक पहुँचने की अनुमति है।
यह हेडर **कई उत्पत्ति** की अनुमति दे सकता है, एक **`null`** मान, या एक वाइल्डकार्ड **`*`**। हालाँकि, **कोई भी ब्राउज़र कई उत्पत्ति का समर्थन नहीं करता**, और वाइल्डकार्ड `*` का उपयोग **सीमाओं** के अधीन है। (वाइल्डकार्ड को अकेले उपयोग किया जाना चाहिए, और `Access-Control-Allow-Credentials: true` के साथ इसका उपयोग अनुमति नहीं है।)
यह हेडर **एक सर्वर द्वारा जारी किया जाता है** एक क्रॉस-डोमेन संसाधन अनुरोध के जवाब में जो एक वेबसाइट द्वारा आरंभ किया गया है, जिसमें ब्राउज़र स्वचालित रूप से एक `Origin` हेडर जोड़ता है।
**डिफ़ॉल्ट** रूप से, क्रॉस-उत्पत्ति अनुरोध बिना क्रेडेंशियल्स जैसे कुकीज़ या ऑथराइजेशन हेडर के किए जाते हैं। फिर भी, एक क्रॉस-डोमेन सर्वर प्रतिक्रिया को पढ़ने की अनुमति दे सकता है जब क्रेडेंशियल्स भेजे जाते हैं, `Access-Control-Allow-Credentials` हेडर को **`true`** सेट करके।
जब विशेष परिस्थितियों के तहत क्रॉस-डोमेन अनुरोध शुरू किया जाता है, जैसे कि **गैर-मानक HTTP विधि** (HEAD, GET, POST के अलावा कुछ भी) का उपयोग करना, नए **हेडर** पेश करना, या विशेष **Content-Type हेडर मान** का उपयोग करना, तो एक प्री-फ्लाइट अनुरोध की आवश्यकता हो सकती है। यह प्रारंभिक अनुरोध, **`OPTIONS`** विधि का उपयोग करते हुए, सर्वर को आगामी क्रॉस-ओरिजिन अनुरोध के इरादों के बारे में सूचित करने के लिए है, जिसमें HTTP विधियाँ और हेडर शामिल हैं जिनका वह उपयोग करने का इरादा रखता है।
**क्रॉस-ओरिजिन रिसोर्स शेयरिंग (CORS)** प्रोटोकॉल इस प्री-फ्लाइट जांच की मांग करता है ताकि अनुरोधित क्रॉस-ओरिजिन ऑपरेशन की व्यवहार्यता का निर्धारण किया जा सके, जो अनुमत विधियों, हेडरों और मूल की विश्वसनीयता की पुष्टि करता है। प्री-फ्लाइट अनुरोध की आवश्यकता से बचने के लिए किन परिस्थितियों का पालन किया जाता है, इसके लिए [**Mozilla Developer Network (MDN)**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests) द्वारा प्रदान किए गए व्यापक गाइड का संदर्भ लें।
यह ध्यान रखना महत्वपूर्ण है कि **प्री-फ्लाइट अनुरोध की अनुपस्थिति प्रतिक्रिया के लिए प्राधिकरण हेडर ले जाने की आवश्यकता को समाप्त नहीं करती है**। इन हेडरों के बिना, ब्राउज़र क्रॉस-ओरिजिन अनुरोध से प्रतिक्रिया को संसाधित करने में असमर्थ है।
`PUT` विधि का उपयोग करने के साथ-साथ `Special-Request-Header` नामक एक कस्टम हेडर का उपयोग करने के लिए प्री-फ्लाइट अनुरोध का निम्नलिखित चित्रण पर विचार करें:
* **`Access-Control-Allow-Headers`**: यह हेडर यह निर्दिष्ट करता है कि वास्तविक अनुरोध के दौरान कौन से हेडर का उपयोग किया जा सकता है। इसे सर्वर द्वारा सेट किया जाता है ताकि क्लाइंट से अनुरोधों में अनुमत हेडर का संकेत दिया जा सके।
* **`Access-Control-Expose-Headers`**: इस हेडर के माध्यम से, सर्वर क्लाइंट को सूचित करता है कि कौन से हेडर सरल प्रतिक्रिया हेडर के अलावा प्रतिक्रिया के हिस्से के रूप में उजागर किए जा सकते हैं।
* **`Access-Control-Max-Age`**: यह हेडर यह संकेत करता है कि प्री-फ्लाइट अनुरोध के परिणामों को कितनी देर तक कैश किया जा सकता है। सर्वर अधिकतम समय सेट करता है, सेकंड में, कि प्री-फ्लाइट अनुरोध द्वारा लौटाई गई जानकारी को कितनी बार पुन: उपयोग किया जा सकता है।
* **`Access-Control-Request-Headers`**: प्री-फ्लाइट अनुरोधों में उपयोग किया जाता है, यह हेडर क्लाइंट द्वारा सेट किया जाता है ताकि सर्वर को सूचित किया जा सके कि क्लाइंट वास्तविक अनुरोध में कौन से HTTP हेडर का उपयोग करना चाहता है।
* **`Access-Control-Request-Method`**: यह हेडर, जो प्री-फ्लाइट अनुरोधों में भी उपयोग किया जाता है, क्लाइंट द्वारा सेट किया जाता है ताकि यह संकेत दिया जा सके कि वास्तविक अनुरोध में कौन सा HTTP विधि का उपयोग किया जाएगा।
* **`Origin`**: यह हेडर स्वचालित रूप से ब्राउज़र द्वारा सेट किया जाता है और क्रॉस-ओरिजिन अनुरोध के मूल को इंगित करता है। इसका उपयोग सर्वर द्वारा यह आकलन करने के लिए किया जाता है कि क्या आने वाले अनुरोध को CORS नीति के आधार पर अनुमति दी जानी चाहिए या अस्वीकृत किया जाना चाहिए।
ध्यान दें कि आमतौर पर (सामग्री-प्रकार और सेट किए गए हेडर के आधार पर) एक **GET/POST अनुरोध में कोई प्री-फ्लाइट अनुरोध नहीं भेजा जाता** (अनुरोध **प्रत्यक्ष** भेजा जाता है), लेकिन यदि आप **प्रतिक्रिया के हेडर/शरीर** तक पहुंचना चाहते हैं, तो इसमें _Access-Control-Allow-Origin_ हेडर होना चाहिए जो इसकी अनुमति देता है।\
**इसलिए, CORS CSRF के खिलाफ सुरक्षा नहीं करता (लेकिन यह सहायक हो सकता है)।**
1.**`Access-Control-Request-Local-Network`**: यह हेडर क्लाइंट के अनुरोध में शामिल किया जाता है ताकि यह संकेत दिया जा सके कि पूछताछ एक स्थानीय नेटवर्क संसाधन के लिए है। यह सर्वर को सूचित करने के लिए एक मार्कर के रूप में कार्य करता है कि अनुरोध स्थानीय नेटवर्क के भीतर से उत्पन्न होता है।
2.**`Access-Control-Allow-Local-Network`**: इसके जवाब में, सर्वर इस हेडर का उपयोग यह संप्रेषित करने के लिए करते हैं कि अनुरोधित संसाधन को स्थानीय नेटवर्क के बाहर की संस्थाओं के साथ साझा करने की अनुमति है। यह विभिन्न नेटवर्क सीमाओं के पार संसाधनों को साझा करने के लिए एक हरी बत्ती के रूप में कार्य करता है, जबकि सुरक्षा प्रोटोकॉल को बनाए रखते हुए नियंत्रित पहुंच सुनिश्चित करता है।
एक **मान्य प्रतिक्रिया जो स्थानीय नेटवर्क अनुरोध की अनुमति देती है** को प्रतिक्रिया में हेडर `Access-Controls-Allow-Local_network: true` भी होना चाहिए:
ध्यान दें कि लिनक्स **0.0.0.0** आईपी इन आवश्यकताओं को **बायपास** करने के लिए काम करता है ताकि localhost तक पहुंचा जा सके क्योंकि उस आईपी पते को "स्थानीय" नहीं माना जाता है।
यदि आप **स्थानीय एंडपॉइंट** का **सार्वजनिक आईपी पता** (जैसे राउटर का सार्वजनिक आईपी) का उपयोग करते हैं तो **स्थानीय नेटवर्क आवश्यकताओं को बायपास करना** भी संभव है। क्योंकि कई अवसरों पर, भले ही **सार्वजनिक आईपी** तक पहुंचा जा रहा हो, यदि यह **स्थानीय नेटवर्क** से है, तो पहुंच दी जाएगी।
यह देखा गया है कि `Access-Control-Allow-Credentials` को **`true`** पर सेट करना अधिकांश **वास्तविक हमलों** के लिए एक पूर्वापेक्षा है। यह सेटिंग ब्राउज़र को क्रेडेंशियल्स भेजने और प्रतिक्रिया पढ़ने की अनुमति देती है, जिससे हमले की प्रभावशीलता बढ़ती है। इसके बिना, ब्राउज़र को अनुरोध जारी करने का लाभ स्वयं करने की तुलना में कम हो जाता है, क्योंकि उपयोगकर्ता के कुकीज़ का लाभ उठाना असंभव हो जाता है।
एक अपवाद है जहां पीड़ित का नेटवर्क स्थान प्रमाणीकरण के एक रूप के रूप में कार्य करता है। यह पीड़ित के ब्राउज़र का उपयोग प्रॉक्सी के रूप में करने की अनुमति देता है, आईपी-आधारित प्रमाणीकरण को दरकिनार करते हुए इंट्रानेट अनुप्रयोगों तक पहुँचने के लिए। यह विधि DNS रीबाइंडिंग के प्रभाव में समानताएँ साझा करती है लेकिन इसे शोषण करना सरल है।
वास्तविक परिदृश्य जहां `Origin` हेडर का मान `Access-Control-Allow-Origin` में परावर्तित होता है, सिद्धांत रूप से असंभव है क्योंकि इन हेडरों को संयोजित करने पर प्रतिबंध हैं। हालाँकि, डेवलपर्स जो कई URL के लिए CORS सक्षम करना चाहते हैं, वे `Origin` हेडर के मान को कॉपी करके `Access-Control-Allow-Origin` हेडर को गतिशील रूप से उत्पन्न कर सकते हैं। यह दृष्टिकोण कमजोरियों को पेश कर सकता है, विशेष रूप से जब एक हमलावर एक ऐसा डोमेन उपयोग करता है जिसका नाम वैध प्रतीत होने के लिए डिज़ाइन किया गया है, जिससे मान्यता लॉजिक को धोखा दिया जा सके।
`null` उत्पत्ति, जिसे रीडायरेक्ट या स्थानीय HTML फ़ाइलों जैसी स्थितियों के लिए निर्दिष्ट किया गया है, एक अद्वितीय स्थिति रखती है। कुछ अनुप्रयोग इस उत्पत्ति को स्थानीय विकास को सुविधाजनक बनाने के लिए व्हाइटलिस्ट करते हैं, जिससे अनजाने में किसी भी वेबसाइट को एक सैंडबॉक्स किए गए iframe के माध्यम से `null` उत्पत्ति की नकल करने की अनुमति मिलती है, इस प्रकार CORS प्रतिबंधों को बायपास किया जा सकता है।
जब एक डोमेन व्हाइटलिस्ट का सामना करना पड़ता है, तो बायपास के अवसरों का परीक्षण करना महत्वपूर्ण है, जैसे कि हमलावर के डोमेन को व्हाइटलिस्टेड डोमेन में जोड़ना या सबडोमेन टेकओवर कमजोरियों का लाभ उठाना। इसके अतिरिक्त, डोमेन मान्यता के लिए उपयोग की जाने वाली नियमित अभिव्यक्तियाँ डोमेन नामकरण परंपराओं में बारीकियों को नजरअंदाज कर सकती हैं, जिससे और भी बायपास के अवसर उत्पन्न होते हैं।
Regex पैटर्न आमतौर पर अल्फ़ान्यूमेरिक, डॉट (.), और हाइफ़न (-) वर्णों पर ध्यान केंद्रित करते हैं, अन्य संभावनाओं की अनदेखी करते हैं। उदाहरण के लिए, एक डोमेन नाम जो ऐसे वर्णों को शामिल करने के लिए तैयार किया गया है जिन्हें ब्राउज़रों और regex पैटर्न द्वारा अलग तरीके से व्याख्यायित किया जाता है, सुरक्षा जांचों को बायपास कर सकता है। Safari, Chrome, और Firefox द्वारा सबडोमेन में अंडरस्कोर वर्णों के प्रबंधन से यह स्पष्ट होता है कि कैसे ऐसे भिन्नताएँ डोमेन मान्यता तर्क को दरकिनार करने के लिए उपयोग की जा सकती हैं।
**इस बायपास जांच की अधिक जानकारी और सेटिंग्स के लिए:** [**https://www.corben.io/advanced-cors-techniques/**](https://www.corben.io/advanced-cors-techniques/) **और** [**https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397**](https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397)
डेवलपर्स अक्सर CORS शोषण से बचाने के लिए सुरक्षा तंत्र लागू करते हैं, उन डोमेन को व्हाइटलिस्ट करके जिन्हें जानकारी मांगने की अनुमति है। इन सावधानियों के बावजूद, सिस्टम की सुरक्षा पूरी तरह से सुरक्षित नहीं है। व्हाइटलिस्टेड डोमेनों के भीतर एक भी कमजोर सबडोमेन की उपस्थिति अन्य कमजोरियों, जैसे कि XSS (क्रॉस-साइट स्क्रिप्टिंग) के माध्यम से CORS शोषण के लिए दरवाजे खोल सकती है।
उदाहरण के लिए, उस परिदृश्य पर विचार करें जहाँ एक डोमेन, `requester.com`, को दूसरे डोमेन, `provider.com`, से संसाधनों तक पहुँचने के लिए व्हाइटलिस्ट किया गया है। सर्वर-साइड कॉन्फ़िगरेशन कुछ इस तरह दिख सकता है:
इस सेटअप में, `requester.com` के सभी सबडोमेन को एक्सेस की अनुमति है। हालाँकि, यदि कोई सबडोमेन, जैसे `sub.requester.com`, XSS कमजोरियों के साथ समझौता किया गया है, तो एक हमलावर इस कमजोरी का लाभ उठा सकता है। उदाहरण के लिए, `sub.requester.com` तक पहुँच रखने वाला एक हमलावर XSS कमजोरी का उपयोग करके CORS नीतियों को बायपास कर सकता है और `provider.com` पर संसाधनों तक दुर्भावनापूर्ण तरीके से पहुँच सकता है।
PortSwigger का [URL validation bypass cheat sheet](https://portswigger.net/research/introducing-the-url-validation-bypass-cheat-sheet) ने पाया कि कुछ ब्राउज़र डोमेन नामों के भीतर अजीब वर्णों का समर्थन करते हैं।
यह संभव है कि HTTP हेडर इंजेक्शन के माध्यम से सर्वर-साइड कैश पॉइज़निंग का लाभ उठाकर, एक संग्रहीत क्रॉस-साइट स्क्रिप्टिंग (XSS) भेद्यता उत्पन्न की जा सके। यह परिदृश्य तब सामने आता है जब एक एप्लिकेशन अवैध वर्णों के लिए `Origin` हेडर को साफ़ करने में विफल रहता है, जो विशेष रूप से इंटरनेट एक्सप्लोरर और एज उपयोगकर्ताओं के लिए एक भेद्यता उत्पन्न करता है। ये ब्राउज़र (0x0d) को एक वैध HTTP हेडर टर्मिनेटर के रूप में मानते हैं, जिससे HTTP हेडर इंजेक्शन भेद्यताएँ उत्पन्न होती हैं।
While directly exploiting this vulnerability by making a web browser send a malformed header is not feasible, a crafted request can be manually generated using tools like Burp Suite. This method could lead to a server-side cache saving the response and inadvertently serving it to others. The crafted payload aims to alter the page's character set to UTF-7, a character encoding often associated with XSS vulnerabilities due to its ability to encode characters in a way that can be executed as script in certain contexts.
**Note**: HTTP हेडर इंजेक्शन कमजोरियों का शोषण, विशेष रूप से सर्वर-साइड कैश पॉइज़निंग के माध्यम से, सभी उपयोगकर्ता-प्रदत्त इनपुट, जिसमें HTTP हेडर शामिल हैं, को मान्य और स्वच्छ करने के महत्व को उजागर करता है। हमेशा एक मजबूत सुरक्षा मॉडल का उपयोग करें जिसमें इनपुट मान्यता शामिल हो ताकि ऐसी कमजोरियों को रोका जा सके।
In this scenario, an instance of a web page reflecting the contents of a custom HTTP header without proper encoding is observed. Specifically, the web page reflects back the contents included in a `X-User-id` header, which could include malicious JavaScript, as demonstrated by the example where the header contains an SVG image tag designed to execute JavaScript code on load.
Cross-Origin Resource Sharing (CORS) नीतियाँ कस्टम हेडर भेजने की अनुमति देती हैं। हालांकि, CORS प्रतिबंधों के कारण यदि प्रतिक्रिया को सीधे ब्राउज़र द्वारा प्रस्तुत नहीं किया जाता है, तो ऐसी इंजेक्शन की उपयोगिता सीमित लग सकती है। महत्वपूर्ण बिंदु तब आता है जब ब्राउज़र के कैश व्यवहार पर विचार किया जाता है। यदि `Vary: Origin` हेडर निर्दिष्ट नहीं किया गया है, तो यह संभव हो जाता है कि दुर्भावनापूर्ण प्रतिक्रिया को ब्राउज़र द्वारा कैश किया जाए। इसके बाद, यह कैश की गई प्रतिक्रिया सीधे URL पर नेविगेट करते समय प्रस्तुत की जा सकती है, प्रारंभिक अनुरोध पर सीधे प्रस्तुत करने की आवश्यकता को दरकिनार करते हुए। यह तंत्र हमले की विश्वसनीयता को बढ़ाता है क्योंकि यह क्लाइंट-साइड कैशिंग का लाभ उठाता है।
To illustrate this attack, a JavaScript example is provided, designed to be executed in the environment of a web page, such as through a JSFiddle. This script performs a simple action: it sends a request to a specified URL with a custom header containing the malicious JavaScript. Upon successful request completion, it attempts to navigate to the target URL, potentially triggering the execution of the injected script if the response has been cached without proper handling of the `Vary: Origin` header.
XSSI, जिसे Cross-Site Script Inclusion के नाम से भी जाना जाता है, एक प्रकार की भेद्यता है जो इस तथ्य का लाभ उठाती है कि Same Origin Policy (SOP) का पालन नहीं किया जाता है जब संसाधनों को स्क्रिप्ट टैग का उपयोग करके शामिल किया जाता है। इसका कारण यह है कि स्क्रिप्ट को विभिन्न डोमेन से शामिल किया जा सकता है। यह भेद्यता एक हमलावर को स्क्रिप्ट टैग का उपयोग करके शामिल की गई किसी भी सामग्री को एक्सेस और पढ़ने की अनुमति देती है।
यह भेद्यता विशेष रूप से महत्वपूर्ण हो जाती है जब यह गतिशील JavaScript या JSONP (JSON with Padding) की बात आती है, विशेष रूप से जब ऑथेंटिकेशन के लिए कुकीज़ जैसी वातावरण-प्राधिकरण जानकारी का उपयोग किया जाता है। जब किसी अलग होस्ट से संसाधन का अनुरोध किया जाता है, तो कुकीज़ शामिल होती हैं, जिससे वे हमलावर के लिए उपलब्ध हो जाती हैं।
इस भेद्यता को बेहतर ढंग से समझने और कम करने के लिए, आप [https://github.com/kapytein/jsonp](https://github.com/kapytein/jsonp) पर उपलब्ध BurpSuite प्लगइन का उपयोग कर सकते हैं। यह प्लगइन आपकी वेब अनुप्रयोगों में संभावित XSSI भेद्यताओं की पहचान और समाधान में मदद कर सकता है।
अनुरोध में एक **`callback`** **पैरामीटर** जोड़ने का प्रयास करें। शायद पृष्ठ को JSONP के रूप में डेटा भेजने के लिए तैयार किया गया था। इस मामले में, पृष्ठ `Content-Type: application/javascript` के साथ डेटा वापस भेजेगा, जो CORS नीति को बायपास करेगा।
`Access-Control-Allow-Origin` प्रतिबंध को बायपास करने का एक तरीका यह है कि एक वेब अनुप्रयोग से आपके पक्ष में अनुरोध करने के लिए कहा जाए और प्रतिक्रिया वापस भेजी जाए। हालाँकि, इस परिदृश्य में, अंतिम पीड़ित के क्रेडेंशियल्स नहीं भेजे जाएंगे क्योंकि अनुरोध एक अलग डोमेन पर किया गया है।
1. [**CORS-escape**](https://github.com/shalvah/cors-escape): यह उपकरण एक प्रॉक्सी प्रदान करता है जो आपके अनुरोध को इसके हेडर के साथ आगे बढ़ाता है, जबकि अनुरोधित डोमेन से मेल खाने के लिए Origin हेडर को भी स्पूफ करता है। यह प्रभावी रूप से CORS नीति को बायपास करता है। यहाँ XMLHttpRequest के साथ एक उदाहरण उपयोग है:
2. [**simple-cors-escape**](https://github.com/shalvah/simple-cors-escape): यह उपकरण अनुरोधों को प्रॉक्सी करने के लिए एक वैकल्पिक दृष्टिकोण प्रदान करता है। आपके अनुरोध को जैसा है वैसा पास करने के बजाय, सर्वर निर्दिष्ट पैरामीटर के साथ अपना स्वयं का अनुरोध करता है।
आप **CORS जांचों** जैसे `e.origin === window.origin` को **एक iframe बनाकर** और **उससे एक नई विंडो खोलकर****बायपास** कर सकते हैं। अधिक जानकारी के लिए निम्नलिखित पृष्ठ में देखें:
TTL के माध्यम से DNS रीबाइंडिंग एक तकनीक है जिसका उपयोग DNS रिकॉर्ड को हेरफेर करके कुछ सुरक्षा उपायों को बायपास करने के लिए किया जाता है। यह कैसे काम करता है:
1. हमलावर एक वेब पृष्ठ बनाता है और पीड़ित को इसे एक्सेस करने के लिए कहता है।
2. फिर हमलावर अपने डोमेन का DNS (IP) बदलता है ताकि यह पीड़ित के वेब पृष्ठ की ओर इशारा करे।
3. पीड़ित का ब्राउज़र DNS प्रतिक्रिया को कैश करता है, जिसमें TTL (Time to Live) मान हो सकता है जो यह दर्शाता है कि DNS रिकॉर्ड को कितनी देर तक मान्य माना जाना चाहिए।
4. जब TTL समाप्त होता है, तो पीड़ित का ब्राउज़र एक नया DNS अनुरोध करता है, जिससे हमलावर को पीड़ित के पृष्ठ पर JavaScript कोड निष्पादित करने की अनुमति मिलती है।
DNS रीबाइंडिंग पीड़ित द्वारा किए गए स्पष्ट IP जांचों को बायपास करने के लिए या उन परिदृश्यों के लिए उपयोगी हो सकती है जहां एक उपयोगकर्ता या बॉट लंबे समय तक एक ही पृष्ठ पर रहता है, जिससे कैश समाप्त हो जाता है।
यदि आपको DNS रीबाइंडिंग का दुरुपयोग करने का एक त्वरित तरीका चाहिए, तो आप [https://lock.cmpxchg8b.com/rebinder.html](https://lock.cmpxchg8b.com/rebinder.html) जैसी सेवाओं का उपयोग कर सकते हैं।
अपने स्वयं के DNS रीबाइंडिंग सर्वर को चलाने के लिए, आप **DNSrebinder** ([https://github.com/mogwailabs/DNSrebinder](https://github.com/mogwailabs/DNSrebinder)) जैसे उपकरणों का उपयोग कर सकते हैं। इसमें आपके स्थानीय पोर्ट 53/udp को उजागर करना, इसके लिए एक A रिकॉर्ड बनाना (जैसे, ns.example.com), और पहले बनाए गए A उपडोमेन (जैसे, ns.example.com) की ओर इशारा करने वाला एक NS रिकॉर्ड बनाना शामिल है। ns.example.com उपडोमेन का कोई भी उपडोमेन तब आपके होस्ट द्वारा हल किया जाएगा।
आप आगे की समझ और प्रयोग के लिए [http://rebind.it/singularity.html](http://rebind.it/singularity.html) पर एक सार्वजनिक रूप से चलने वाले सर्वर का भी अन्वेषण कर सकते हैं।
DNS कैश बाढ़ के माध्यम से DNS रीबाइंडिंग एक और तकनीक है जिसका उपयोग ब्राउज़रों के कैशिंग तंत्र को बायपास करने और एक दूसरा DNS अनुरोध करने के लिए किया जाता है। यह कैसे काम करता है:
2. कैशिंग रक्षा को बायपास करने के लिए, हमलावर एक सेवा कार्यकर्ता का लाभ उठाता है। सेवा कार्यकर्ता DNS कैश को बाढ़ करता है, जो प्रभावी रूप से कैश किए गए हमलावर सर्वर नाम को हटा देता है।
सेवा कार्यकर्ता के साथ DNS कैश को बाढ़ करके, हमलावर DNS समाधान प्रक्रिया को हेरफेर कर सकता है और पीड़ित के ब्राउज़र को एक दूसरा अनुरोध करने के लिए मजबूर कर सकता है, इस बार हमलावर के इच्छित IP पते पर हल किया जा रहा है।
6. दूसरे IP पते तक पहुँचकर, ब्राउज़र Same Origin Policy (SOP) को बायपास करता है, जिससे हमलावर को इसका दुरुपयोग करने और जानकारी एकत्र करने और निकालने की अनुमति मिलती है।
यह तकनीक उन ब्राउज़रों के व्यवहार का लाभ उठाती है जब एक डोमेन के लिए कई IP पते प्रदान किए जाते हैं। प्रतिक्रियाओं को रणनीतिक रूप से नियंत्रित करके और ब्राउज़र के IP पते के चयन में हेरफेर करके, एक हमलावर SOP का शोषण कर सकता है और पीड़ित से जानकारी प्राप्त कर सकता है।
ध्यान दें कि लोकलहोस्ट तक पहुँचने के लिए आपको Windows में **127.0.0.1** और Linux में **0.0.0.0** को रीबाइंड करने का प्रयास करना चाहिए।\
जैसे godaddy या cloudflare जैसे प्रदाताओं ने मुझे IP 0.0.0.0 का उपयोग करने की अनुमति नहीं दी, लेकिन AWS route53 ने मुझे 2 IPs के साथ एक A रिकॉर्ड बनाने की अनुमति दी, जिनमें से एक "0.0.0.0" है।
अधिक जानकारी के लिए आप [https://unit42.paloaltonetworks.com/dns-rebinding/](https://unit42.paloaltonetworks.com/dns-rebinding/) देख सकते हैं।
### Other Common Bypasses
* यदि **आंतरिक IPs की अनुमति नहीं है**, तो वे **0.0.0.0 को प्रतिबंधित करना भूल सकते हैं** (Linux और Mac पर काम करता है)
* यदि **आंतरिक IPs की अनुमति नहीं है**, तो **localhost** के लिए एक **CNAME** के साथ उत्तर दें (Linux और Mac पर काम करता है)
* यदि **आंतरिक IPs को DNS प्रतिक्रियाओं के रूप में अनुमति नहीं है**, तो आप **आंतरिक सेवाओं के लिए CNAMEs** के साथ उत्तर दे सकते हैं जैसे www.corporate.internal।
आप पिछले बायपास तकनीकों और निम्नलिखित उपकरण का उपयोग कैसे करें, इसके बारे में अधिक जानकारी [Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference](https://www.youtube.com/watch?v=y9-0lICNjOQ) में पा सकते हैं।
[**`Singularity of Origin`**](https://github.com/nccgroup/singularity) एक उपकरण है जो [DNS रीबाइंडिंग](https://en.wikipedia.org/wiki/DNS\_rebinding) हमलों को करने के लिए है। इसमें हमलावर सर्वर DNS नाम के IP पते को लक्षित मशीन के IP पते पर रीबाइंड करने और लक्षित मशीन पर कमजोर सॉफ़्टवेयर का शोषण करने के लिए हमलावर पेलोड प्रदान करने के लिए आवश्यक घटक शामिल हैं।
* [https://wicg.github.io/private-network-access/](https://wicg.github.io/private-network-access/): प्रस्ताव जब सार्वजनिक सर्वर आंतरिक सर्वरों तक पहुँच प्राप्त करना चाहते हैं तो हमेशा एक प्री-फ्लाइट अनुरोध भेजने के लिए
Learn & practice AWS Hacking:<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">\
Learn & practice GCP Hacking: <imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
