[**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) की खोज करें, हमारा विशेष संग्रह [**NFTs**](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)** का पालन करें**.
* **अपने हैकिंग ट्रिक्स को** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **और** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud) **में PR जमा करके अपना योगदान दें।**
* **विकल्पशील वेब**: यह वेब है जहां से हम कुछ जानकारी बाहर निकालना चाहते हैं
* **हमलावर वेब**: यह वेब है जिसे हमलावर निर्मित करता है जिसमें दुर्भाग्यपूर्ण होता है और पीड़ित उपयोगकर्ता उपयोग करता है
* **सम्मिलन विधि**: यह विधि होती है जिसका उपयोग विकल्पशील वेब को हमलावर वेब से लोड करने के लिए किया जाता है (जैसे window.open, iframe, fetch, href के साथ HTML टैग...)
* **लीक तकनीक**: विकल्पशील वेब तक पहुंचने के बाद, एक तकनीक का उपयोग किया जाएगा जो सम्मिलन विधि के द्वारा प्राप्त की गई जानकारी के आधार पर वेब की संभावित स्थिति के बीच अंतर करने के लिए उपयोग किया जाएगा।
* **अवस्थाएं**: पीड़ित को जिस व्यक्ति के बीच अंतर करना चाहते हैं, उसके आधार पर विकल्पशील वेब की 2 संभावित स्थितियां हो सकती हैं।
* **पता लगाने योग्य अंतर**: यह जानकारी होती है जिसे हमलावर को विकल्पशील वेब की स्थिति का निर्णय लेने के लिए प्रयास करना होता है
* **स्थिति कोड**. एक हमलावर विकल्पशील पृष्ठ को पहचान सकता है **विभिन्न HTTP प्रतिक्रिया स्थिति कोड** के द्वारा (उदाहरण के लिए, सर्वर त्रुटियां, ग्राहक त्रुटियां या प्रमाणीकरण त्रुटियां)।
* **API उपयोग**. यह पता लगाने योग्य अंतर हमलावर को यह संदेश देता है कि क्रॉस-उत्पादन पृष्ठ एक विशिष्ट JavaScript वेब API का उपयोग कर रहा है या नहीं।
* **पुनर्निर्देशन**. यह संभव है कि एक वेब एप्लिकेशन ने उपयोगकर्ता को **एक अलग पृष्ठ पर नेविगेट किया** हो। इसमें केवल HTTP पुनर्निर्देशों से सीमित नही
* **इवेंट हैंडलर**. इवेंट हैंडलर को XS-Leaks के लिए क्लासिकल लीक तकनीक के रूप में देखा जा सकता है। ये विभिन्न जानकारी के स्रोत के रूप में जाने जाते हैं। उदाहरण के लिए, **onload** का ट्रिगर सफलतापूर्वक संसाधन लोड होने की ओर इशारा करता है जबकि onerror इवेंट इसके विपरीत होता है।
* **त्रुटि संदेश**. इवेंट हैंडलर के अलावा, त्रुटि संदेश **जावास्क्रिप्ट अपवाद** और **विशेष त्रुटि पेज** के रूप में हो सकते हैं। त्रुटि संदेश विभिन्न चरणों में फेंके जा सकते हैं, उदाहरण के लिए, लीक तकनीक द्वारा सीधे फेंके जा सकते हैं। लीक तकनीक या तो त्रुटि संदेश में सीधे शामिल **जानकारी** का उपयोग कर सकती है या त्रुटि संदेश की **उपस्थिति और अनुपस्थिति के बीच भेद कर सकती है**।
* **वैश्विक सीमाएं**. हर कंप्यूटर की अपनी भौतिक सीमाएं होती हैं, इसी तरह ब्राउज़र की भी होती हैं। उदाहरण के लिए, उपलब्ध मेमोरी की मात्रा एक ब्राउज़र के चल रहे टैब्स की सीमा होती है। इसी तरह अन्य ब्राउज़र सीमाएं भी हैं जो पूरे ब्राउज़र के लिए प्रयोजित की जाती हैं। यदि हमलावर सीमा कब पहुंची है यह निर्धारित कर सकता है तो इसे लीक तकनीक के रूप में उपयोग किया जा सकता है।
* **वैश्विक स्थिति**. ब्राउज़र में **वैश्विक स्थिति होती है जिसमें सभी पेज संचरण कर सकते हैं**। यदि हमलावर की वेबसाइट से इस संचरण को पता लगाया जा सकता है, तो इसे लीक तकनीक के रूप में उपयोग किया जा सकता है। उदाहरण के लिए, **इतिहास** इंटरफ़ेस एक टैब या फ्रेम में देखे गए पेज के संचरण को संशोधित करने की अनुमति देता है। इससे एक वैश्विक स्थिति बनती है क्योंकि **एंट्रीज़ की संख्या** हमलावर को अलग-अलग स्रोत पेज के बारे में निष्कर्ष निकालने की अनुमति देती है।
* **प्रदर्शन API**. प्रदर्शन API का उपयोग मौजूदा पेज की **प्रदर्शन जानकारी तक पहुंचने के लिए** किया जाता है। उनकी एंट्रीज़ में प्रतिष्ठान और पेज द्वारा लोड किए गए हर संसाधन के विस्तृत नेटवर्क टाइमिंग डेटा शामिल होते हैं। इससे हमलावर को **अनुरोधित संसाधनों** के बारे में निष्कर्ष निकालने की अनुमति मिलती है। उदाहरण के लिए, हमने ऐसे मामलों की पहचान की है जहां ब्राउज़र ने कुछ अनुरोधों के लिए प्रदर्शन एंट्रीज़ नहीं बनाए हैं।
* **पठनीय गुणधर्म**. HTML में कई **ऐसे गुणधर्म होते हैं जो स्रोत-सीमा के बाहर पठनीय होते हैं**। इस पठनीय पहुंच का उपयोग लीक तकनीक के रूप में किया जा सकता है। उदाहरण के लिए, जावास्क्रिप्ट कोड विंडो.फ्रेम.लंबाई संपत्ति के साथ वेबपेज में शामिल फ्रेमों की संख्या पठनीय सीमा के बाहर से पढ़ सकता है।
निम्नलिखित तकनीकों में से कुछ तकनीकें संभावित वेब पेज की संभावित स्थितियों में अंतर का पता लगाने के लिए समय का उपयोग करेंगी। वेब ब्राउज़र में समय को मापने के लिए विभिन्न तरीके हैं।
**घड़ी**: [performance.now()](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) एपीआई डेवलपर्स को उच्च-संकल्प वाले समय मापन प्राप्त करने की अनुमति देता है।\
हमलावर द्वारा निर्मित घड़ी बनाने के लिए आक्रमणकारी बहुत सारे एपीआई हैं: [Broadcast Channel API](https://developer.mozilla.org/en-US/docs/Web/API/Broadcast\_Channel\_API), [Message Channel API](https://developer.mozilla.org/en-US/docs/Web/API/MessageChannel), [requestAnimationFrame](https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame), [setTimeout](https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout), CSS animations, और अन्य।\
अधिक जानकारी के लिए: [https://xsleaks.dev/docs/attacks/timing-attacks/clocks](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/).
* **सारांश:** [**performance.now()**](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) **API** का उपयोग करके यह मापा जा सकता है कि एक अनुरोध को पूरा करने में कितना समय लगता है। हालांकि, अन्य घड़ी भी उपयोग की जा सकती है, जैसे [**PerformanceLongTaskTiming API**](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceLongTaskTiming) जो 50 मिलीसेकंड से अधिक समय तक चल रहे कार्यों की पहचान कर सकता है।
* **कोड उदाहरण**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events) एक और उदाहरण:
* **सारांश:** [SharedArrayBuffer clock](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#sharedarraybuffer-and-web-workers) का उपयोग करके यह मापा जा सकता है कि एक अनुरोध को पूरा करने में कितना समय लगता है। अन्य घड़ी भी उपयोग की जा सकती है।
[`unload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/unload\_event) और [`beforeunload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeunload\_event) इवेंट का उपयोग करके एक संसाधित संसाधन को प्राप्त करने में कितना समय लगता है, इसे मापा जा सकता है। यह काम इसलिए करता है क्योंकि **`beforeunload`** जब ब्राउज़र एक नई नेविगेशन अनुरोध करता है तब ट्रिगर होता है, जबकि **`unload`** उस नेविगेशन को पूरा करने पर ट्रिगर होता है। इस व्यवहार के कारण, इन दो इवेंट्स के बीच समय अंतर की गणना की जा सकती है और **ब्राउज़र को संसाधित संसाधन को पूरा करने में कितना समय लगा** यह मापा जा सकता है।
* **सारांश:** [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) API का उपयोग करके यह मापा जा सकता है कि एक अनुरोध को पूरा करने में कितना समय लगता है। अन्य घड़ी भी उपयोग की जा सकती है।
यदि किसी पृष्ठ में [Framing Protections](https://xsleaks.dev/docs/defenses/opt-in/xfo/) लागू नहीं हैं, तो हमलावर पूरे नेटवर्क पर पृष्ठ और सभी सब-संसाधनों को लोड होने में कितना समय लगता है यह समय का माप कर सकता है। डिफ़ॉल्ट रूप से, एक आइफ्रेम के लिए `onload` हैंडलर सभी संसाधनों को लोड होने के बाद और सभी जावास्क्रिप्ट कोड के पूर्ण होने के बाद आह्वानित किया जाता है। लेकिन, हमलावर जावास्क्रिप्ट कोड के ध्वनि को हटा सकता है जो ज
* **सारांश**: हमलावर यह देख सकते हैं कि CORB को प्रयोग किया जा रहा है यदि किसी प्रतिक्रिया में _CORB सुरक्षित_`Content-Type` (और `nosniff`) और स्थिति कोड `2xx` के साथ लौटता है, जिससे CORB द्वारा प्रतिक्रिया से बॉडी और हैडर हटा दिए जाते हैं। इस सुरक्षा की पहचान हमलावर को देती है कि वह संयोजन का एक संयोजन कोड (सफलता बनाम त्रुटि) और `Content-Type` (CORB द्वारा संरक्षित या नहीं) का संयोजन लीक कर सकता है।
एक पृष्ठ को एक फ्रेम के भीतर लोड करना संभव है और पृष्ठ को ध्यान देने के लिए **`#id_value`** का उपयोग करना है जो फ्रेम के तत्व पर ध्यान केंद्रित करता है, फिर यदि **`onblur`** संकेत ट्रिगर होता है, तो ID तत्व मौजूद होता है।\
आप **`portal`** टैग के साथ भी एक ही हमला कर सकते हैं।
* **सारांश**: postMessage से संवेदनशील जानकारी इकट्ठा करें या पोस्टमैसेज की मौजूदगी का उपयोग उपयोगकर्ता की स्थिति को जानने के लिए एक ओरेकल के रूप में करें
* **कोड उदाहरण**: `सभी postMessages के लिए सुनने वाला कोड।`
अनुप्रयोगों में अक्सर [postMessage broadcasts](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) का उपयोग अन्य स्रोतों के साथ जानकारी साझा करने के लिए किया जाता है। इन संदेशों को सुनने से कोई भी **संवेदनशील जानकारी** (संभावित रूप से यदि `targetOrigin` पैरामीटर का उपयोग नहीं किया गया हो) मिल सकती है। इसके अलावा, किसी संदेश को प्राप्त करने का तथ्य एक **ओरेकल के रूप में उपयोग किया जा सकता है** (आप केवल तब इस तरह के संदेश प्राप्त करते हैं जब आप लॉग इन होते हैं)।
[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) का उपयोग करें और आसानी से वर्ल्ड के **सबसे उन्नत समुदाय उपकरणों** द्वारा संचालित कार्यप्रवाह बनाएं और स्वचालित करें।\
* **सारांश:** एक वेब के निष्पादन का समय मापें और एक थ्रेड के ईवेंट लूप को लॉक करें और **ईवेंट लूप फिर से उपलब्ध होने में कितना समय लगता है** का समय निर्धारित करें।
इस तकनीक का एक मुख्य लाभ यह है कि इसकी क्षमता है कि यह साइट आइसोलेशन को दूर कर सकती है, क्योंकि एक हमलावर मूल संबंध के निष्पादन पर एक अतिरिक्त मूल के निष्पादन को प्रभावित कर सकता है।
एक निष्पादन समय में **नेटवर्क कारकों को नष्ट करने** के लिए **और सटीक माप** प्राप्त करने के लिए संभव है। उदाहरण के लिए, पेज को लोड करने से पहले पेज द्वारा उपयोग किए जाने वाले संसाधनों को लोड करके।
* **सारांश:** एक हमलावर सभी सॉकेट्स को लॉक कर सकता है केवल 1 को छोड़कर, लक्षित वेब को लोड करें और उसी समय एक और पेज लोड करें, जब तक अंतिम पेज लोड होना शुरू नहीं होता है, तब तक लक्षित पेज को लोड करने में लगा समय है।
ब्राउज़र सर्वरों के साथ संचार करने के लिए सॉकेट्स का उपयोग करते हैं। जबकि ऑपरेटिंग सिस्टम और उस पर चल रहे हार्डवेयर के संसाधनों की सीमित संख्या होती है, **ब्राउज़रों को सीमा लगानी पड़ती है**। इस सीमा की मौजूदगी का शोषण करने के लिए हमलावर निम्न कार्रवाई कर सकते हैं:
1. जांचें कि ब्राउज़र की सीमा क्या है, उदाहरण के लिए 256 ग्लोबल सॉकेट्स।
2. विभिन्न होस्टों के 255 अनुरोधों को करके 255 सॉकेट्स को लंबे समय तक ब्लॉक करके 255 सॉकेट्स को ब्लॉक करें जो केवल कनेक्शन को रोकते हैं
3. लक्षित पेज के लिए एक अनुरोध करके 256वें सॉकेट का उपयोग करें।
4. एक अन्य होस्ट के लिए 257वें अनुरोध करें। सभी सॉकेट्स का उपयोग हो रहा है (2 और 3 कदम में), इसलिए यह अनुरोध पूल को एक उपलब्ध सॉकेट प्राप्त करने तक प्रतीक्षा करना होगा। इस प्रतीक्षा अवधि से हमलावर को 256वें सॉकेट के नेटवर्क टाइमिंग को प्राप्त होता है, जो लक्षित पेज के लिए होता है। यह काम करता है क्योंकि 2 कदम में 255 सॉकेट्स अभी भी ब्लॉक हैं, इसलिए अगर पूल ने एक उपलब्ध सॉकेट प्राप्त किया है, तो यह 3 कदम में सॉकेट के विमुक्त होने के कारण हुआ था। 256वें सॉकेट को विमुक्त करने का समय सीधे पूर्ण अनुरोध को पूरा करने में लिया जाने वाले समय से सीधे जुड़ा हुआ है।
अधिक जानकारी के लिए: [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
यह तकनीक उल्लेखित पेपर में एक तालिका में पाई गई थी, लेकिन उसमें तकनीक का कोई वर्णन नहीं मिला। हालांकि, आप इसे जांचने के लिए स्रोत कोड में खोज सकते हैं [https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak)
एक हमलावर यह पता लगा सकता है कि क्या एक अनुरोध खाली HTTP प्रतिक्रिया शरीर के कारण हुआ है क्योंकि **खाली पृष्ठ कुछ ब्राउज़र में प्रदर्शन प्रविष्टि नहीं बनाते हैं**।
SA में, XSSAuditor ट्रिगर हुआ है या नहीं इसे पता लगाना संभव है और इस तरह संवेदनशील जानकारी लीक कर सकते हैं। XSS-Auditor SA और GC (अब हटा दिया गया) की एक अंतर्निहित सुविधा है जो क्रॉस-साइट स्क्रिप्टिंग (XSS) हमलों को न्यायिक रूप से रोकने के लिए डिज़ाइन की गई है। 2013 में, Braun और Heiderich \[7] ने दिखाया कि XSS-Auditor का उपयोग झूलस सकता है और इस तरह से जानकारी को बाहर निकाल सकता है। इन XS-Leak को पहले तो Terada ने एक बग रिपोर्ट में वर्णित किया और बाद में Heyes ने एक ब्लॉग पोस्ट में। हालांकि, खोजी गई तकनीकें केवल GC में XSS-Auditor के लिए लागू होती हैं और SA में काम नहीं करती हैं। हमने यह खोजा है कि अवरुद्ध पृष्ठ Performance API प्रविष्टियाँ नहीं बनाएगा। इसका मतलब है कि एक हमलावर XSS-Auditor के साथ भी संवेदनशील जानकारी लीक कर सकता है।
यदि एक पृष्ठ को **आईफ्रेम** में **प्रदर्शित करने की अनुमति नहीं है**, तो यह **प्रदर्शन प्रविष्टि नहीं बनाता है**। इस परिणामस्वरूप, एक हमलावर प्रतिक्रिया हेडर **`X-Frame-Options`** का पता लगा सकता है।\
यदि आप **एम्बेड****टैग** का उपयोग करते हैं तो भी यही होता है।
कुछ मामलों में, **nextHopProtocol एंट्री** लीक तकनीक के रूप में उपयोग किया जा सकता है। GC में, जब **CORP हैडर** सेट होता है, तो nextHopProtocol **खाली** हो जाएगा। ध्यान दें कि SA CORP सक्षम संसाधनों के लिए कोई प्रदर्शन एंट्री बनाएगा ही नहीं।
सेवा कर्मचारी घटना-निर्देशित स्क्रिप्ट संदर्भ हैं जो एक मूल में चलते हैं। वे एक वेब पृष्ठ के पीछे चलते हैं और ऑफ़लाइन वेब एप्लिकेशन बनाने के लिए संसाधनों को अवरोधित, संशोधित और **कैश कर सकते हैं**।
यदि सेवा कर्मचारी द्वारा **कैश किया गया संसाधन****आईफ्रेम** के माध्यम से एक्सेस किया जाता है, तो संसाधन **सेवा कर्मचारी कैश से लोड होगा**।
संसाधन को सेवा कर्मचारी से **लोड किया गया था** यह जांचने के लिए **प्रदर्शन API** का उपयोग किया जा सकता है।
इसे एक टाइमिंग हमले के साथ भी किया जा सकता है (अधिक जानकारी के लिए पेपर की जांच करें)।
[प्रदर्शन API](xs-search.md#performance-api) का उपयोग करके संसाधन कैश हुआ है यह जांचना संभव है।
अधिक जानकारी के लिए: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources)
**`MediaError`** इंटरफेस की **`message`** प्रॉपर्टी में **सफलतापूर्वक लोड होने वाले संसाधनों के लिए एक अलग स्ट्रिंग होती है**। इससे एक हमलावर्ती कोर्स संसाधन के लिए प्रतिक्रिया स्थिति का अनुमान लगाना संभव होता है।
CORS किसी भी वेब संसाधन को किसी भी वेबसाइट से पढ़ा और उपयोग करने की अनुमति देता है। Webkit आधारित ब्राउज़र में, यह संभव है कि **कॉर्स अनुरोध विफल होने पर कॉर्स त्रुटि संदेश का उपयोग किया जा सके**। एक हमलावर एक टारगेट वेबसाइट को एक कॉर्स सक्षम अनुरोध भेज सकता है जो उपयोगकर्ता स्थिति के आधार पर **रीडायरेक्ट** करता है। जब ब्राउज़र अनुरोध को अस्वीकार करता है, तो त्रुटि संदेश में **रीडायरेक्ट के लक्ष्य का पूरा URL लीक हो जाता है**। इस हमले के साथ, रीडायरेक्ट का पता लगाना, रीडायरेक्ट स्थानों को और संवेदनशील क्वेरी पैरामीटर्स को लीक करना संभव होता है।
अखंडता विशेषता एक क्रिप्टोग्राफिक हैश परिभाषित करती है जिसके द्वारा ब्राउज़र सत्यापित कर सकता है कि एक फेच किया गया संसाधन में कोई खिलाव नहीं हुआ है। इस सुरक्षा तंत्र को Subresource Integrity (SRI) कहा जाता है। यह सामग्री वितरण नेटवर्क (CDN) से सेवा की जाने वाली संसाधनों की अखंडता सत्यापन के लिए उपयोग किया जाता है। डेटा लीक को रोकने के लिए, क्रॉस-उत्पन्न संसाधनों को **कॉर्स सक्षम** होना चाहिए। अन्यथा, प्रतिक्रिया अखंडता मान्यता के लिए योग्य नहीं होती है। कॉर्स त्रुटि XS-Leak की तरह, यह संभव है कि एक इंटेग्रिटी विशेषता के साथ एक फेच अनुरोध के बाद की **त्रुटि संदेश को पकड़ा जा सके**। एक हमलावर इस त्रुटि को किसी भी अनुरोध पर बलपूर्वक **ट्रिगर** कर सकता है एक **बोगस हैश मान** निर्दिष्ट करके। SA में, यह त्रुटि संदेश अनुरोधित संसाधन की सामग्री लंबाई को लीक करता है। एक हमलावर इस लीक का उपयोग करके प्रतिक्रिया के आकार में अंतर का पता लगा सकता है, जो शक्तिशाली XS-Leak हमलों को सक्षम करता है।
CORP हैडर एक नई वेब प्लेटफ़ॉर्म सुरक्षा सुविधा है जो नो-कोर्स क्रॉस-उत्पन्न अनुरोधों को दिए गए संसाधन के लिए अवरोधित करती है। हैडर की मौजूदगी पता लगाई जा सकती है, क्योंकि CORP द्वारा संरक्षित संसाधन को फेच करने पर त्रुटि उत्पन्न होगी।
### उत्पादन त्रुटि पर CORS त्रुटि <a href="#cors-error-on-origin-reflection-misconfiguration" id="cors-error-on-origin-reflection-misconfiguration"></a>
* **सारांश**: यदि Origin हैडर `Access-Control-Allow-Origin` में प्रतिबिंबित हो रहा है, तो संसाधन के बारे में जांच करने की संभावना होती है कि क्या पहले से ही कैश में है।
यदि Origin हैडर `Access-Control-Allow-Origin` में प्रतिबिंबित हो रहा है, तो हमलावर इस व्यवहार का दुरुपयोग कर सकता है और कोशिका मोड में संसाधन को फेच करने का प्रयास कर सकता है। यदि कोई त्रुटि उत्पन्न नहीं होती है, तो इसका अर्थ है कि यह वेब से सही ढंग से प्राप्त किया गया था, और यदि त्रुटि उत्पन्न होती है, तो इसका अर्थ है कि यह कैश से एक प्रतिक्रिया को संप्राप्त किया गया था (त्रुटि इसलिए प्रकट होती है क्योंकि कैश एक CORS हैडर के साथ एक प्रतिक्रिया को सही डोमेन की अनुमति देता है और हमलावर की डोमेन नहीं)**।**\
ध्यान दें कि यदि उत्पत्ति प्रतिबिंबित नहीं है लेकिन वाइल्डकार्ड का उपयोग किया जाता है (`Access-Control-Allow-Origin: *`), तो यह काम नहीं करेगा।
Fetch API का उपयोग करके `redirect: "manual"` और अन्य पैरामीटरों के साथ एक अनुरोध सबमिट करने से, `response.type` गुण को पढ़ने का संभावना होती है और यदि यह `opaqueredirect` के बराबर है तो प्रतिक्रिया एक रीडायरेक्ट थी।
* **सारांश:** प्रतिक्रियाओं में अंतर का पता लगाएं क्योंकि पुनर्निर्देशन प्रतिक्रिया की लंबाई एक अनुरोध के लिए बहुत बड़ी हो सकती है जिससे अंतर का पता लगाया जा सकता है।
[Chromium दस्तावेज़ीकरण](https://chromium.googlesource.com/chromium/src/+/main/docs/security/url\_display\_guidelines/url\_display\_guidelines.md#URL-Length) के अनुसार, Chrome की अधिकतम URL लंबाई 2MB है।
> सामान्य रूप से, वेब प्लेटफ़ॉर्म के पास URL की लंबाई पर सीमाएं नहीं होती हैं (हालांकि 2^31 एक सामान्य सीमा है)। Chrome अंतर-प्रक्रिया संचार में त्रुटि-सेवा समस्याओं को रोकने और व्यावहारिक कारणों से URL की अधिकतम लंबाई को 2MB तक सीमित करता है।
इसलिए यदि **पुनर्निर्देश URL** में किसी एक मामले में जवाब दिया जाता है, तो इसे **2MB से अधिक लंबा URL** बनाना संभव है ताकि यह **लंबाई सीमा** को प्रभावित कर सके। जब ऐसा होता है, तो Chrome एक **`about:blank#blocked`** पृष्ठ दिखाता है।
**पता लगाने योग्य अंतर** यह है कि यदि **पुनर्निर्देश** पूरा हो गया होता है, तो `window.origin` एक **त्रुटि** फेंकता है क्योंकि एक क्रॉस उत्पन्नता उस जानकारी तक पहुंच नहीं हो सकती है। हालांकि, यदि **सीमा** को छू जाता है और लोड किया गया पृष्ठ **`about:blank#blocked`** था, तो विंडो का **`origin`** माता-पिता का रहता है, जो एक **पहुंचने योग्य जानकारी** है।
**2MB** तक पहुंचने के लिए सभी अतिरिक्त जानकारी को प्रारंभिक URL में एक **हैश** के माध्यम से जोड़ा जा सकता है ताकि इसे **पुनर्निर्देश में उपयोग** किया जा सके।
यदि ब्राउज़र के **पुनर्निर्देशों** की **अधिकतम** संख्या 20 है, तो एक हमलावर 19 पुनर्निर्देशों के साथ अपना पृष्ठ लोड करने का प्रयास कर सकता है और अंत में पीड़ित को परीक्षण किए गए पृष्ठ पर भेज सकता है। यदि एक **त्रुटि** उत्पन्न होती है, तो पृष्ठ ने पीड़ित को **पुनर्निर्देशित करने की कोशिश** की थी।
**History API** जावास्क्रिप्ट कोड को ब्राउज़र इतिहास को संशोधित करने की अनुमति देता है, जिसमें एक उपयोगकर्ता द्वारा देखे गए पृष्ठ सहेजे जाते हैं। एक हमलावर लंबाई संपत्ति को एक समावेश विधि के रूप में उपयोग कर सकता है: जावास्क्रिप्ट और HTML नेविगेशन का पता लगाने के लिए।\
**`history.length` की जांच करें**, एक उपयोगकर्ता को **नेविगेट** कराएं, इसे **वापस** समान मूल के रूप में **बदलें** और **`history.length`** के नए मान की **जांच** करें।
`iframe` या `window.open` के माध्यम से खोले गए वेब पेज में **फ्रेमों की संख्या गिनने** से उपयोगकर्ता की **स्थिति की पहचान** करने में मदद मिल सकती है।\
इसके अलावा, यदि पेज में हमेशा एक ही संख्या की फ्रेमें होती हैं, तो फ्रेमों की संख्या की **नियमित रूप से जांच** करने से एक **पैटर्न** की पहचान की जा सकती है जो जानकारी लीक कर सकता है।
इस तकनीक का एक उदाहरण यह है कि क्रोम में, एक **पीडीएफ** को **फ्रेम गिनती** के साथ **पहचाना** जा सकता है क्योंकि इसमें आंतरिक रूप से `embed` का उपयोग होता है। इसमें [ओपन URL पैरामीटर](https://bugs.chromium.org/p/chromium/issues/detail?id=64309#c113) होते हैं जो सामग्री पर कुछ नियंत्रण प्रदान करते हैं जैसे `ज़ूम`, `व्यू`, `पेज`, `टूलबार` जहां यह तकनीक दिलचस्प हो सकती है।
कुछ वेबपेज उपयोगकर्ता जानकारी पर आधारित डाइनेमिक रूप से **मीडिया फ़ाइलें उत्पन्न** कर सकते हैं या मीडिया के आकार में पानी के निशान जोड़ सकते हैं। एक हमलावर इन HTML तत्वों द्वारा लीक हुई जानकारी का उपयोग करके संभावित स्थितियों के बीच अंतर का पता लगा सकता है।
* [HTMLMediaElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement) मीडिया `अवधि` और `बफर की गई समय` को लीक करता है।
* [HTMLVideoElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement) `videoHeight` और `videoWidth` को लीक करता है, कुछ ब्राउज़रों में `webkitVideoDecodedByteCount`, `webkitAudioDecodedByteCount` और `webkitDecodedFrameCount` भी हो सकते हैं।
* [getVideoPlaybackQuality()](https://developer.mozilla.org/en-US/docs/Web/API/VideoPlaybackQuality) `totalVideoFrames` को लीक करता है।
* [HTMLImageElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement) `ऊँचाई` और `चौड़ाई` को लीक करता है, लेकिन यदि छवि अमान्य है तो वे 0 हो जाएंगे और [`image.decode()`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/decode) अस्वीकृति प्राप्त करेगा।
वेब एप्लिकेशन उपयोगकर्ता की स्थिति पर निर्भर करके **वेबसाइट स्टाइलिंग बदल सकती है**। क्रॉस-उत्पन्न CSS फ़ाइलें HTML लिंक तत्व के साथ हमलावर पृष्ठ में सम्मिलित की जा सकती हैं, और नियमों को हमलावर पृष्ठ पर **लागू** किया जाएगा। यदि कोई पृष्ठ डाइनेमिक रूप से इन नियमों को बदलता है, तो हमलावर इस उपयोगकर्ता स्थिति के आधार पर इन अंतरों का **पता लगा सकता है**।\
एक लीक तकनीक के रूप में, हमलावर उपयोगकर्ता द्वारा निर्दिष्ट HTML तत्व के CSS गु
* **सारांश:** GC में, जब एक पृष्ठ को **X-Frame-Options के कारण क्रॉस-उत्पन्न पृष्ठ पर सम्मिलित करने की अनुमति नहीं होती है, तो एक त्रुटि पृष्ठ दिखाया जाता है**।
Chrome में, जब एक पृष्ठ को क्रॉस-उत्पन्न पृष्ठ पर सम्मिलित करने की अनुमति नहीं होती है, क्योंकि **X-FrameOptions** (XFO) हैडर को निषेध या समान-स्रोत में सेट किया जाता है, तो एक **त्रुटि पृष्ठ दिखाया जाता है इसके बजाय**। ऑब्जेक्ट के लिए, इस त्रुटि पृष्ठ को **`contentDocument` प्रॉपर्टी की जांच करके पता लगाया जा सकता है**। सामान्यतः, यह प्रॉपर्टी null लौटाती है क्योंकि क्रॉस-उत्पन्न सम्मिलित दस्तावेज़ तक पहुंच की अनुमति नहीं होती है। हालांकि, Chrome के रेंडरिंग के कारण, एक **खाली दस्तावेज़ ऑब्जेक्ट लौटाया जाता है**। यह iframes के लिए काम नहीं करता है या अन्य ब्राउज़र में। डेवलपर्स अक्सर सभी पृष्ठों के लिए X-Frame-Options सेट करना भूल सकते हैं और विशेष रूप से त्रुटि पृष्ठों में यह हैडर छूट जाता है। एक लीक तकनीक के रूप में, एक हमलावर इसे जांचकर विभिन्न उपयोगकर्ता स्थितियों के बीच अंतर का पता लगा सकता है।
`Content-Disposition` हैडर ([`Content-Disposition: attachment`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition)) इसका संकेत देता है कि ब्राउज़र को सामग्री को डाउनलोड करना चाहिए या इसे इनलाइन दिखाना चाहिए।
यदि केवल लॉग इन किए गए उपयोगकर्ता को **एक पृष्ठ तक पहुंचने की अनुमति होगी जो एक फ़ाइल डाउनलोड करेगा** क्योंकि यह हैडर का उपयोग कर रहा है। ऐसा व्यवहार पता लगाना संभव है।
Chromium-आधारित ब्राउज़र में, जब एक फ़ाइल डाउनलोड होता है, डाउनलोड प्रक्रिया का **नीचे एक बार में एक पूर्वावलोकन** दिखाई देता है, जो ब्राउज़र विंडो में समाहित होता है। **विंडो की ऊचाई का मॉनिटरिंग** करके हमलावर यह जांच सकते हैं कि क्या "डाउनलोड बार" खुला है।
[`Content-Disposition: attachment`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition) हैडर की जांच करने का एक और तरीका है **जांचें कि क्या एक नेविगेशन हुआ है**। यदि पृष्ठ लोड डाउनलोड को कारण बनाता है, तो यह नेविगेशन ट्रिगर नहीं करता है और **विंडो समान मूल में बनी रहती है**।
* **सारांश:** एक संसाधन को लोड करने का प्रयास करना संभव है और इसे लोड होने से पहले लोडिंग रुक जाती है। यदि एक त्रुटि ट्रिगर होती है, तो संसाधन कैश किया गया था या नहीं था इस पर निर्भर करेगा।
[**`एबोर्टकंट्रोलर`**](https://developer.mozilla.org/en-US/docs/Web/API/AbortController) को _**फेच**_ और _**setTimeout**_ के साथ कंबाइन किया जा सकता है ताकि यह पता लगाया जा सके कि क्या संसाधन कैश किया गया है और ब्राउज़र कैश से एक विशेष संसाधन को निकाला जा सके। इस तकनीक की एक अच्छी विशेषता यह है कि प्रोबिंग नई सामग्री को कैश करते हुए होती है।
* **सारांश:** जब एक **क्रॉस-संसाधन स्क्रिप्ट** पृष्ठ पर शामिल होता है, तो इसकी सामग्री को **सीधे पढ़ना संभव नहीं होता** है। हालांकि, यदि एक स्क्रिप्ट **किसी भी अंतर्निहित फ़ंक्शन का उपयोग करता है**, तो उसे **अधिलेखित किया जा सकता है** और उनके तर्क पढ़े जा सकते हैं जो **महत्वपूर्ण जानकारी छिड़कने** के लिए हो सकती है।
1. हमलावर अपने डोमेन में सेवा कर्मचारी को पंजीकृत करता है (attacker.com में)।
2. मुख्य दस्तावेज़ीकरण में, हमलावर लक्षित वेबसाइट पर नेविगेशन (विंडो.ओपन) जारी करता है और सेवा कर्मचारी को टाइमर शुरू करने के निर्देश देता है।
3. जब नई विंडो लोड होना शुरू होती है, हमलावर दस्तावेज़ीकरण में प्राप्त संदर्भ को सेवा कर्मचारी द्वारा संचालित पृष्ठ पर नेविगेट करता है।
4. जब चरण 3 में किया गया अनुरोध सेवा कर्मचारी तक पहुंचता है, तो यह एक 204 (कोई सामग्री नहीं) प्रतिक्रिया वापस करता है, जिससे नेविगेशन रद्द हो जाता है।
5. इस बिंदु पर, सेवा कर्मचारी चरण 2 में शुरू किए गए टाइमर से एक माप इकट्ठा करता है। इस माप को यह प्रभावित करता है कि जावास्क्रिप्ट नेविगेशन को कितना समय ब्लॉक करता है।
एक क्रियान्वयन समय में **नेटवर्क कारकों** को **नष्ट** करके **अधिक सटीक माप** प्राप्त किया जा सकता है। उदाहरण के लिए, पृष्ठ को लोड करने से पहले पृष्ठ द्वारा उपयोग की जाने वाली संसाधनों को लोड करके।
इसलिए, आपका काम हो सकता है कि आप **बहुत सारे बेकार अक्षर जोड़ें** (उदाहरण के लिए **हजारों "W"**) को **गुप्त से पहले वेब पेज भरने के लिए** या कुछ ऐसा जोड़ें `<br><canvas height="1850px"></canvas><br>.`\
फिर यदि उदाहरण के लिए हमारा **इंजेक्शन झंडे से पहले आता है**, तो **छवि** लोड होगी, लेकिन यदि झंडे के बाद आता है, तो झंडा + बेकार अक्षर इसे **लोड होने से रोकेगा** (आपको रखने के लिए कितने बेकार अक्षर रखने की जरूरत होगी, इसके साथ खेलने की आवश्यकता होगी)। यही हुआ [**इस व्राइटअप में**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/)।
यह पाठ बॉट को पृष्ठ में शामिल किए गए पाठ का उपयोग करने के लिए करेगा जो `SECR` टेक्स्ट को सम्मिलित करेगा। जैसा कि यह पाठ रहस्य है और यह **चित्र के नीचे ही है**, चित्र केवल तब ही लोड होगा जब अनुमानित रहस्य सही होगा। इसलिए यहां आपके पास अपना ओरेकल है जिसके माध्यम से आप रहस्य को **अक्षर-अक्षर निकाल सकते हैं**।
इसे उत्पन्न करने के लिए कुछ कोड उदाहरण: [https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e](https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e)
यदि एक बाहरी इमेज लोड करना संभव नहीं है जो हमलावर को इसकी जानकारी देती है कि इमेज लोड हो गई है, तो एक और विकल्प हो सकता है कि कई बार अक्षर को अनुमान लगाएं और उसे मापें। यदि इमेज लोड होती है तो सभी अनुरोधों में अधिक समय लगेगा जबकि इमेज लोड नहीं होती है तो कम समय लगेगा। यही वह चीज है जिसका उपयोग [**इस व्रिटअप के समाधान में**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/) किया गया था **यहां संक्षेप में दिया गया है:**
यदि `jQuery(location.hash)` का उपयोग किया जाता है, तो समय के माध्यम से पता लगाया जा सकता है कि क्या कुछ HTML सामग्री मौजूद है, यह इसलिए है क्योंकि यदि चयनकर्ता `main[id='site-main']` से मेल नहीं खाता है तो इसे बाकी **चयनकर्ताओं** की जांच करने की आवश्यकता नहीं होती है:
इस खंड में आप [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) में सिफारिश की गई कुछ सुरक्षा उपायों का हिस्सा देख सकते हैं, हालांकि, विकि के प्रत्येक खंड में अधिक सुरक्षा उपाय हैं [https://xsleaks.dev/](https://xsleaks.dev/)। इन तकनीकों से बचने के बारे में अधिक जानकारी के लिए वहां देखें।
* **HTML तत्व**. यह **CORP हैडर का उपयोग कर सकता है ताकि पृष्ठों को संसाधित संसाधनों को सम्मिलित करने की अनुमति हो सके**। CORP को समान-मूल या समान-साइट के रूप में सेट किया जा सकता है और उस संसाधन के लिए किसी भी पार-संसाधन या पार-साइट अनुरोध को ब्लॉक करता है। **ग्राहक साइट** पर, Chromium आधारित ब्राउज़र CORB एल्गोरिदम का उपयोग करते हैं ताकि यह निर्णय कर सकें कि पार-संसाधन संसाधन अनुरोधों को अनुमति दी जानी चाहिए या नहीं।
* **फ्रेम**. **आईफ्रेम** तत्वों को HTML संसाधनों को लोड करने से रोकने के लिए मुख्य सुरक्षा उपाय है **X-Frame-Options** का उपयोग करना। वैकल्पिक रूप में, **CSP निर्देशिका frame-ancestors** एक समान परिणाम प्राप्त कर सकती है। यदि सम्मिलन को नकारा जाता है, तो सम्मिलन विधि में प्रतिक्रियाओं में कोई अंतर नहीं पाया जा सकता है।
* **पॉप-अप**. `window.opener` तक पहुंच को प्रतिबंधित करने के लिए, **COOP HTTP प्रतिक्रिया हैडर** तीन अलग-अलग मानों को परिभाषित करता है: unsafe-none (डिफ़ॉल्ट), same-origin-allow-popups और same-origin। इन मानों का उपयोग करके **ब्राउज़िंग टैब्स और पॉप-अप्स को अलग करके**, और इस प्रकार, पॉप-अप पर आधारित लीक तकनीकों को रोकता है।
* **JavaScript अनुरोध**. पार-संसाधन JavaScript अनुरोधों का अक्सर XS-Leak हमलों में उपयोग किया जाता है, क्योंकि हमलावर को जारी किए गए अनुरोध पर ठीक-से नियंत्रण होता है। हालांकि, ये अनुरोध CORS सक्षम नहीं होते हैं, इसलिए इन्हें स्क्रिप्ट या छवियों की तरह HTML तत्वों द्वारा भेजे गए अनुरोधों की तरहीं प्रतिबंधित किए जाने की सीमाएं होती हैं। इस प्रकार, CORP और CORB द्वारा इस लीक तकनीक का प्रभाव भी **कम किया जा सकता है**।
* **फेच मेटाडेटा**. ये अनुरोध हेडर सर्वर मालिकों को बेहतर ढंग से समझने की अनुमति देते हैं कि उपयोगकर्ता के ब्राउज़र ने एक विशिष्ट अनुरोध को कैसे उत्पन्न किया है। Chrome में, Sec-Fetch-\* हेडर्स को स्वचालित रूप से प्रत्येक अनुरोध में जोड़ा जाता है और अनुरोध के मूल्य के बारे में मेटाडेटा प्रदान करता है। उदाहरण के लिए, Sec-Fetch-Dest: image एक छवि तत्व से ट्रिगर हुआ था। वेब अनुप्रयोग फिर उस जानकारी के आधार पर अनुरोधों को ब्लॉक करने का चयन कर सकते हैं।
* **Same-Site कुकीज़**. Same-Site कुकीज़ फ्लैग वेबसाइटों को घोषित करने की अनुमति देता है **कि क्या कुकी समान-साइट या पहली-पक्ष संदर्भ में सीमित होनी चाहिए**। सभी प्रमुख ब्राउज़र Same-Site कुकीज़ का समर्थन करते हैं। GC में, विशेषता के बिना कुकीज़ अब डिफ़ॉल्ट रूप से Lax हैं। XS-Leaks के मामले में, **Same-Site कुकीज़ लीक हमला संभावनाओं को बहुत हद तक सीमित करती हैं**। दूसरी ओर, **`window.open` के साथ `SameSite=Lax` काम करती हैं**। वेबसाइट जो **अन्य प्रमाणीकरण** विधियों, जैसे क्लाइंट-साइड प्रमाणपत्र और HTTP प्रमाणीकरण, **संवेदनशील रहती हैं**।
* **पार-संसाधन पहचानकर्ता अविंग्यता (COIU)**. COIU, जिसे पहले से ही Tor ब्राउज
* क्या आप **साइबर सुरक्षा कंपनी** में काम करते हैं? क्या आप अपनी **कंपनी को 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) या मुझे **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) का उपयोग करें और आसानी से बनाएं और **स्वचालित कार्यप्रवाह** बनाएं जो दुनिया के **सबसे उन्नत समुदाय उपकरणों** द्वारा संचालित होता है।\
