Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) to आसानी से **वर्कफ़्लो** बनाएं और **स्वचालित करें** जो दुनिया के **सबसे उन्नत** सामुदायिक उपकरणों द्वारा संचालित हैं।\
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.
* **कमजोर वेब**: लक्षित वेबसाइट जिससे जानकारी निकाली जानी है।
* **हमलावर का वेब**: वह दुर्भावनापूर्ण वेबसाइट जो हमलावर द्वारा बनाई गई है, जिसे पीड़ित विजिट करता है, जो एक्सप्लॉइट को होस्ट करती है।
* **शामिल करने की विधि**: वह तकनीक जो कमजोर वेब को हमलावर के वेब में शामिल करने के लिए उपयोग की जाती है (जैसे, window.open, iframe, fetch, href के साथ HTML टैग, आदि)।
* **लीक तकनीक**: तकनीकें जो शामिल करने की विधि के माध्यम से एकत्र की गई जानकारी के आधार पर कमजोर वेब की स्थिति में भिन्नताएँ पहचानने के लिए उपयोग की जाती हैं।
* **राज्य**: कमजोर वेब की दो संभावित स्थितियाँ, जिन्हें हमलावर पहचानने का प्रयास करता है।
* **पता लगाने योग्य भिन्नताएँ**: अवलोकनीय भिन्नताएँ जिन पर हमलावर कमजोर वेब की स्थिति का अनुमान लगाने के लिए निर्भर करता है।
### Detectable Differences
कमजोर वेब की स्थितियों को भिन्न करने के लिए कई पहलुओं का विश्लेषण किया जा सकता है:
* **स्थिति कोड**: **विभिन्न HTTP प्रतिक्रिया स्थिति कोड** के बीच भेद करना, जैसे सर्वर त्रुटियाँ, क्लाइंट त्रुटियाँ, या प्रमाणीकरण त्रुटियाँ।
* **API उपयोग**: पृष्ठों के बीच **वेब APIs के उपयोग** की पहचान करना, यह प्रकट करना कि क्या एक क्रॉस-ओरिजिन पृष्ठ एक विशिष्ट जावास्क्रिप्ट वेब API का उपयोग करता है।
* **रीडायरेक्ट्स**: विभिन्न पृष्ठों पर नेविगेशन का पता लगाना, न केवल HTTP रीडायरेक्ट्स बल्कि जावास्क्रिप्ट या HTML द्वारा ट्रिगर किए गए।
* **पृष्ठ सामग्री**: **HTTP प्रतिक्रिया शरीर में भिन्नताओं** या पृष्ठ उप-संसाधनों में अवलोकन करना, जैसे **एंबेडेड फ्रेम की संख्या** या छवियों में आकार भिन्नताएँ।
* **HTTP हेडर**: **विशिष्ट HTTP प्रतिक्रिया हेडर** की उपस्थिति या संभवतः उसके मान को नोट करना, जिसमें X-Frame-Options, Content-Disposition, और Cross-Origin-Resource-Policy जैसे हेडर शामिल हैं।
* **समय**: दोनों स्थितियों के बीच लगातार समय भिन्नताओं का ध्यान रखना।
* **HTML तत्व**: HTML विभिन्न तत्वों की पेशकश करता है जो **क्रॉस-ओरिजिन संसाधन समावेश** के लिए होते हैं, जैसे स्टाइलशीट, छवियाँ, या स्क्रिप्ट, जो ब्राउज़र को एक गैर-HTML संसाधन के लिए अनुरोध करने के लिए मजबूर करते हैं। इस उद्देश्य के लिए संभावित HTML तत्वों का संकलन [https://github.com/cure53/HTTPLeaks](https://github.com/cure53/HTTPLeaks) पर पाया जा सकता है।
* **फ्रेम**: तत्व जैसे **iframe**, **object**, और **embed** HTML संसाधनों को सीधे हमलावर के पृष्ठ में एम्बेड कर सकते हैं। यदि पृष्ठ **फ्रेमिंग सुरक्षा** की कमी है, तो जावास्क्रिप्ट फ्रेम किए गए संसाधन की विंडो ऑब्जेक्ट को contentWindow प्रॉपर्टी के माध्यम से एक्सेस कर सकता है।
* **पॉप-अप**: **`window.open`** विधि एक नए टैब या विंडो में एक संसाधन खोलती है, जावास्क्रिप्ट को विधियों और गुणों के साथ बातचीत करने के लिए एक **विंडो हैंडल** प्रदान करती है जो SOP का पालन करती है। पॉप-अप, जो अक्सर सिंगल साइन-ऑन में उपयोग होते हैं, लक्षित संसाधन की फ्रेमिंग और कुकी प्रतिबंधों को दरकिनार करते हैं। हालाँकि, आधुनिक ब्राउज़र पॉप-अप निर्माण को कुछ उपयोगकर्ता क्रियाओं तक सीमित करते हैं।
* **जावास्क्रिप्ट अनुरोध**: जावास्क्रिप्ट लक्षित संसाधनों के लिए सीधे अनुरोध करने की अनुमति देती है **XMLHttpRequests** या **Fetch API** का उपयोग करके। ये विधियाँ अनुरोध पर सटीक नियंत्रण प्रदान करती हैं, जैसे HTTP रीडायरेक्ट का पालन करने का विकल्प चुनना।
* **इवेंट हैंडलर**: XS-Leaks में एक पारंपरिक लीक तकनीक, जहां इवेंट हैंडलर जैसे **onload** और **onerror** संसाधन लोडिंग की सफलता या विफलता के बारे में जानकारी प्रदान करते हैं।
* **त्रुटि संदेश**: जावास्क्रिप्ट अपवाद या विशेष त्रुटि पृष्ठ लीक जानकारी प्रदान कर सकते हैं या तो त्रुटि संदेश से सीधे या इसकी उपस्थिति और अनुपस्थिति के बीच भेद करके।
* **वैश्विक सीमाएँ**: एक ब्राउज़र की भौतिक सीमाएँ, जैसे मेमोरी क्षमता या अन्य लागू ब्राउज़र सीमाएँ, यह संकेत दे सकती हैं कि कब एक सीमा तक पहुँच गई है, जो एक लीक तकनीक के रूप में कार्य करती है।
* **वैश्विक स्थिति**: ब्राउज़र की **वैश्विक स्थितियों** (जैसे, इतिहास इंटरफेस) के साथ पता लगाने योग्य इंटरैक्शन का लाभ उठाया जा सकता है। उदाहरण के लिए, एक ब्राउज़र के इतिहास में **प्रविष्टियों की संख्या** क्रॉस-ओरिजिन पृष्ठों के बारे में सुराग प्रदान कर सकती है।
* **परफॉर्मेंस API**: यह API **वर्तमान पृष्ठ के प्रदर्शन विवरण** प्रदान करती है, जिसमें दस्तावेज़ और लोड किए गए संसाधनों के लिए नेटवर्क समय शामिल है, जो अनुरोधित संसाधनों के बारे में अनुमान लगाने की अनुमति देती है।
* **पढ़ने योग्य विशेषताएँ**: कुछ HTML विशेषताएँ **क्रॉस-ओरिजिन पढ़ने योग्य** होती हैं और लीक तकनीक के रूप में उपयोग की जा सकती हैं। उदाहरण के लिए, `window.frame.length` प्रॉपर्टी जावास्क्रिप्ट को एक वेबपृष्ठ में शामिल फ्रेमों की संख्या गिनने की अनुमति देती है।
XSinator एक स्वचालित उपकरण है जो **कई ज्ञात XS-Leaks** के खिलाफ ब्राउज़रों की **जांच** करता है, जिसे इसके पेपर में समझाया गया है: [**https://xsinator.com/paper.pdf**](https://xsinator.com/paper.pdf)
आप **उपकरण तक पहुँच सकते हैं** [**https://xsinator.com/**](https://xsinator.com/)
{% hint style="warning" %}
**अलग किए गए XS-Leaks**: हमें उन XS-Leaks को अलग करना पड़ा जो **सेवा श्रमिकों** पर निर्भर करते हैं क्योंकि वे XSinator में अन्य लीक के साथ हस्तक्षेप करेंगे। इसके अलावा, हमने **विशिष्ट वेब एप्लिकेशन में गलत कॉन्फ़िगरेशन और बग्स पर निर्भर करने वाले XS-Leaks को भी अलग करने का निर्णय लिया**। उदाहरण के लिए, CrossOrigin Resource Sharing (CORS) गलत कॉन्फ़िगरेशन, postMessage लीक या Cross-Site Scripting। इसके अतिरिक्त, हमने समय आधारित XS-Leaks को भी अलग किया क्योंकि वे अक्सर धीमे, शोर वाले और असंगत होते हैं।
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) to आसानी से **वर्कफ़्लो** बनाएं और **स्वचालित करें** जो दुनिया के **सबसे उन्नत** सामुदायिक उपकरणों द्वारा संचालित हैं।\
कुछ निम्नलिखित तकनीकें समय का उपयोग करने जा रही हैं ताकि वेब पृष्ठों की संभावित स्थितियों में भिन्नताएँ पहचान सकें। एक वेब ब्राउज़र में समय मापने के विभिन्न तरीके हैं।
**घड़ियाँ**: [performance.now()](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) API डेवलपर्स को उच्च-रिज़ॉल्यूशन समय माप प्राप्त करने की अनुमति देती है।\
हमलावरों के पास निहित घड़ियाँ बनाने के लिए कई APIs का दुरुपयोग करने के लिए पर्याप्त संख्या में APIs हैं: [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 एनिमेशन, और अन्य।\
* **Summary**: यदि एक संसाधन को लोड करने का प्रयास किया जा रहा है तो onerror/onload इवेंट्स को ट्रिगर किया जाता है जब संसाधन सफलतापूर्वक/असफलता से लोड होता है, तो स्थिति कोड का पता लगाना संभव है।
कोड उदाहरण **JS से स्क्रिप्ट ऑब्जेक्ट लोड करने** का प्रयास करता है, लेकिन **अन्य टैग** जैसे ऑब्जेक्ट, स्टाइलशीट, छवियाँ, ऑडियोज़ का भी उपयोग किया जा सकता है। इसके अलावा, **टैग को सीधे** इंजेक्ट करना और टैग के अंदर `onload` और `onerror` इवेंट्स को घोषित करना भी संभव है (इसके बजाय इसे JS से इंजेक्ट करना)।
* **Summary:** The [**performance.now()**](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) **API** can be used to measure how much time it takes to perform a request. However, other clocks could be used, such as [**PerformanceLongTaskTiming API**](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceLongTaskTiming) which can identify tasks running for more than 50ms.
* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events) another example in:
यह तकनीक पिछले वाले के समान है, लेकिन **attacker** कुछ क्रिया को **प्रासंगिक समय** लेने के लिए भी **बल देगा** जब **उत्तर सकारात्मक या नकारात्मक** हो और उस समय को मापेगा।
* **Summary:** The [SharedArrayBuffer clock](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#sharedarraybuffer-and-web-workers) can be used to measure how much time it takes to perform a request. Other clocks could be used.
The time taken to fetch a resource can be measured by utilizing the [`unload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/unload\_event) and [`beforeunload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeunload\_event) events. The **`beforeunload`** event is fired when the browser is about to navigate to a new page, while the **`unload`** event occurs when the navigation is actually taking place. The time difference between these two events can be calculated to determine the **duration the browser spent fetching the resource**.
* **Summary:** The [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) API can be used to measure how much time it takes to perform a request. Other clocks could be used.
यह देखा गया है कि [Framing Protections](https://xsleaks.dev/docs/defenses/opt-in/xfo/) की अनुपस्थिति में, एक पृष्ठ और इसके उप-संसाधनों को नेटवर्क पर लोड करने के लिए आवश्यक समय को एक **attacker** द्वारा मापा जा सकता है। यह माप आमतौर पर संभव है क्योंकि एक iframe का `onload` हैंडलर केवल संसाधन लोडिंग और JavaScript निष्पादन की समाप्ति के बाद ही सक्रिय होता है। स्क्रिप्ट निष्पादन द्वारा उत्पन्न परिवर्तनशीलता को बायपास करने के लिए, एक **attacker**`<iframe>` के भीतर [`sandbox`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe) विशेषता का उपयोग कर सकता है। इस विशेषता का समावेश कई कार्यक्षमताओं को प्रतिबंधित करता है, विशेष रूप से JavaScript के निष्पादन को, जिससे एक माप को सुविधाजनक बनाया जा सकता है जो मुख्य रूप से नेटवर्क प्रदर्शन से प्रभावित होता है।
* **Summary**: यदि आप सही सामग्री को एक्सेस करते समय पृष्ठ में त्रुटि उत्पन्न कर सकते हैं और किसी भी सामग्री को एक्सेस करते समय इसे सही तरीके से लोड कर सकते हैं, तो आप सभी जानकारी निकालने के लिए एक लूप बना सकते हैं बिना समय मापे।
आप **पीड़ित को खोजने के लिए मजबूर कर सकते हैं** उस फ़ाइल के लिए जिसमें "_**flag**_" है, एक **Iframe** का उपयोग करके (उदाहरण के लिए CSRF का शोषण करते हुए)। Iframe के अंदर आप जानते हैं कि _**onload event**_ हमेशा **कम से कम एक बार****निष्पादित** होगा। फिर, आप **URL** को **iframe** का **बदल सकते हैं** लेकिन केवल **hash** के **सामग्री** को बदलकर।
यदि पहला URL **सफलतापूर्वक लोड** हुआ, तो, जब **hash** भाग को **बदला** जाता है, तो **onload** घटना **फिर से सक्रिय नहीं होगी**। लेकिन **यदि** पृष्ठ लोड करते समय किसी प्रकार की **त्रुटि** थी, तो, **onload** घटना **फिर से सक्रिय होगी**।
तब, आप **सही** लोड किए गए पृष्ठ या पृष्ठ के बीच **अंतर** कर सकते हैं जिसमें **त्रुटि** है जब इसे एक्सेस किया जाता है।
### Javascript Execution
* **Inclusion Methods**: Frames
* **Detectable Difference**: Page Content
* **More info**:
* **Summary:** यदि **पृष्ठ****संवेदनशील** सामग्री **वापस कर रहा है**, **या** एक **सामग्री** जो उपयोगकर्ता द्वारा **नियंत्रित** की जा सकती है। उपयोगकर्ता **नकारात्मक मामले** में **मान्य JS कोड सेट कर सकता है**, और **`<script>`** टैग के अंदर प्रत्येक प्रयास को **लोड** कर सकता है, इसलिए **नकारात्मक** मामलों में हमलावरों का **कोड****निष्पादित** होता है, और **सकारात्मक** मामलों में **कुछ भी** निष्पादित नहीं होगा।
* **Summary**: **Cross-Origin Read Blocking (CORB)** एक सुरक्षा उपाय है जो वेब पृष्ठों को कुछ संवेदनशील क्रॉस-ओरिजिन संसाधनों को लोड करने से रोकता है ताकि **Spectre** जैसे हमलों से सुरक्षा की जा सके। हालाँकि, हमलावर इसके सुरक्षात्मक व्यवहार का शोषण कर सकते हैं। जब **CORB** के अधीन एक प्रतिक्रिया _**CORB protected**_`Content-Type` के साथ `nosniff` और `2xx` स्थिति कोड लौटाती है, तो **CORB** प्रतिक्रिया के शरीर और हेडर को हटा देता है। इस पर नज़र रखने वाले हमलावर स्थिति कोड (सफलता या त्रुटि को इंगित करने वाला) और `Content-Type` (यह दर्शाता है कि यह **CORB** द्वारा संरक्षित है) के संयोजन का अनुमान लगा सकते हैं, जिससे संभावित जानकारी लीक हो सकती है।
* **Code Example**:
हमले के बारे में अधिक जानकारी के लिए अधिक जानकारी लिंक की जांच करें।
यह संभव है कि आप **iframe** के अंदर एक **पृष्ठ****लोड करें** और **`#id_value`** का उपयोग करके पृष्ठ को **iframe के तत्व पर ध्यान केंद्रित** करने के लिए मजबूर करें, यदि एक **`onblur`** संकेत सक्रिय होता है, तो ID तत्व मौजूद है।\
आप **`portal`** टैग के साथ भी वही हमला कर सकते हैं।
* **Summary**: postMessage से संवेदनशील जानकारी इकट्ठा करें या उपयोगकर्ता की स्थिति जानने के लिए postMessages की उपस्थिति का उपयोग करें।
* **Code Example**: `Any code listening for all postMessages.`
ऐप्लिकेशन अक्सर [`postMessage` broadcasts](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) का उपयोग विभिन्न मूलों के बीच संचार करने के लिए करते हैं। हालाँकि, यदि `targetOrigin` पैरामीटर को ठीक से निर्दिष्ट नहीं किया गया है, तो यह विधि अनजाने में **संवेदनशील जानकारी** को उजागर कर सकती है, जिससे किसी भी विंडो को संदेश प्राप्त करने की अनुमति मिलती है। इसके अलावा, संदेश प्राप्त करने की क्रिया एक **oracle** के रूप में कार्य कर सकती है; उदाहरण के लिए, कुछ संदेश केवल उन उपयोगकर्ताओं को भेजे जा सकते हैं जो लॉग इन हैं। इसलिए, इन संदेशों की उपस्थिति या अनुपस्थिति उपयोगकर्ता की स्थिति या पहचान के बारे में जानकारी प्रकट कर सकती है, जैसे कि क्या वे प्रमाणित हैं या नहीं।
[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) का उपयोग करें ताकि आप आसानी से दुनिया के **सबसे उन्नत** सामुदायिक उपकरणों द्वारा संचालित **कार्यप्रवाह** बना और स्वचालित कर सकें।\
यह पहचानना संभव है कि एक लक्ष्य पृष्ठ कितने **WebSocket कनेक्शन** का उपयोग करता है। यह हमलावर को एप्लिकेशन की स्थितियों का पता लगाने और WebSocket कनेक्शनों की संख्या से संबंधित जानकारी लीक करने की अनुमति देता है।
यदि एक **origin****WebSocket** कनेक्शन वस्तुओं की **अधिकतम मात्रा** का उपयोग करता है, तो कनेक्शन की स्थिति की परवाह किए बिना, **नए वस्तुओं का निर्माण JavaScript अपवादों का परिणाम देगा**। इस हमले को निष्पादित करने के लिए, हमलावर की वेबसाइट लक्ष्य वेबसाइट को एक पॉप-अप या iframe में खोलती है और फिर, लक्ष्य वेब के लोड होने के बाद, संभवतः अधिकतम संख्या में WebSockets कनेक्शन बनाने का प्रयास करती है। **उत्पन्न अपवादों की संख्या** लक्ष्य वेबसाइट के **WebSocket कनेक्शनों की संख्या** है।
क्योंकि **केवल एक भुगतान अनुरोध सक्रिय हो सकता है** एक ही समय में, यदि लक्ष्य वेबसाइट Payment Request API का उपयोग कर रही है, तो इस API का उपयोग करने के लिए कोई भी आगे के प्रयास **विफल** होंगे, और एक **JavaScript अपवाद** का कारण बनेंगे। हमलावर इसे **नियमित रूप से Payment API UI दिखाने का प्रयास करके** शोषण कर सकता है। यदि एक प्रयास अपवाद का कारण बनता है, तो लक्ष्य वेबसाइट वर्तमान में इसका उपयोग कर रही है। हमलावर इन नियमित प्रयासों को UI बनाने के तुरंत बाद बंद करके छिपा सकता है।
JavaScript एक [एकल-थ्रेडेड इवेंट लूप](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop) समवर्ती मॉडल पर काम करता है, जिसका अर्थ है कि **यह एक समय में केवल एक कार्य निष्पादित कर सकता है**। इस विशेषता का उपयोग **यह मापने के लिए किया जा सकता है कि एक अलग मूल से कोड को निष्पादित करने में कितना समय लगता है**। एक हमलावर अपने कोड के निष्पादन समय को इवेंट लूप में माप सकता है, लगातार निश्चित गुणों के साथ इवेंट भेजकर। ये इवेंट तब संसाधित किए जाएंगे जब इवेंट पूल खाली होगा। यदि अन्य मूल भी उसी पूल में इवेंट भेज रहे हैं, तो एक **हमलावर इन बाहरी इवेंट के निष्पादन में देरी को देखकर यह अनुमान लगा सकता है कि इन बाहरी इवेंट को निष्पादित करने में कितना समय लगता है**। देरी के लिए इवेंट लूप की निगरानी करने की यह विधि विभिन्न मूलों से कोड के निष्पादन समय को प्रकट कर सकती है, संभावित रूप से संवेदनशील जानकारी को उजागर कर सकती है।
एक निष्पादन समय में **नेटवर्क कारकों** को **हटाना** संभव है ताकि **अधिक सटीक माप** प्राप्त किया जा सके। उदाहरण के लिए, पृष्ठ द्वारा उपयोग किए जाने वाले संसाधनों को लोड करने से पहले लोड करना।
* **Summary:** एक वेब ऑपरेशन के निष्पादन समय को मापने की एक विधि में जानबूझकर एक थ्रेड के इवेंट लूप को अवरुद्ध करना और फिर **इवेंट लूप को फिर से उपलब्ध होने में कितना समय लगता है** को मापना शामिल है। एक अवरुद्ध ऑपरेशन (जैसे लंबी गणना या समकालिक API कॉल) को इवेंट लूप में डालकर, और बाद के कोड के निष्पादन की शुरुआत के लिए समय की निगरानी करके, कोई यह अनुमान लगा सकता है कि अवरुद्ध अवधि के दौरान इवेंट लूप में कौन से कार्य निष्पादित हो रहे थे। यह तकनीक JavaScript के इवेंट लूप की एकल-थ्रेडेड प्रकृति का लाभ उठाती है, जहां कार्य अनुक्रम में निष्पादित होते हैं, और यह समान थ्रेड साझा करने वाले अन्य ऑपरेशनों के प्रदर्शन या व्यवहार के बारे में अंतर्दृष्टि प्रदान कर सकती है।
इवेंट लूप को लॉक करके निष्पादन समय को मापने की तकनीक का एक महत्वपूर्ण लाभ **Site Isolation** को दरकिनार करने की क्षमता है। **Site Isolation** एक सुरक्षा विशेषता है जो विभिन्न वेबसाइटों को अलग प्रक्रियाओं में विभाजित करती है, जिसका उद्देश्य दुर्भावनापूर्ण साइटों को अन्य साइटों से संवेदनशील डेटा तक सीधे पहुंचने से रोकना है। हालाँकि, साझा इवेंट लूप के माध्यम से दूसरे मूल के निष्पादन समय को प्रभावित करके, एक हमलावर उस मूल की गतिविधियों के बारे में अप्रत्यक्ष रूप से जानकारी निकाल सकता है। यह विधि दूसरे मूल के डेटा तक सीधी पहुंच पर निर्भर नहीं करती है, बल्कि साझा इवेंट लूप पर उस मूल की गतिविधियों के प्रभाव को देखती है, इस प्रकार **Site Isolation** द्वारा स्थापित सुरक्षात्मक बाधाओं से बचती है।
एक निष्पादन समय में **नेटवर्क कारकों** को **हटाना** संभव है ताकि **अधिक सटीक माप** प्राप्त किया जा सके। उदाहरण के लिए, पृष्ठ द्वारा उपयोग किए जाने वाले संसाधनों को लोड करने से पहले लोड करना।
* **Summary:** एक हमलावर सभी सॉकेट्स को 1 को छोड़कर लॉक कर सकता है, लक्ष्य वेब को लोड कर सकता है और एक ही समय में एक और पृष्ठ लोड कर सकता है, अंतिम पृष्ठ के लोड होने तक का समय लक्ष्य पृष्ठ के लोड होने का समय है।
ब्राउज़र सर्वर संचार के लिए सॉकेट का उपयोग करते हैं, लेकिन ऑपरेटिंग सिस्टम और हार्डवेयर के सीमित संसाधनों के कारण, **ब्राउज़र को समवर्ती सॉकेट की संख्या पर एक सीमा लागू करने के लिए मजबूर किया जाता है**। हमलावर इस सीमा का शोषण निम्नलिखित चरणों के माध्यम से कर सकते हैं:
1. ब्राउज़र की सॉकेट सीमा का निर्धारण करें, उदाहरण के लिए, 256 वैश्विक सॉकेट।
2. विभिन्न होस्टों के लिए 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/)
### Connection Pool by Destination
* **Inclusion Methods**: JavaScript Requests
* **Detectable Difference**: Timing (generally due to Page Content, Status Code)
* **More info**:
* **Summary:** यह पिछले तकनीक के समान है लेकिन सभी सॉकेट्स का उपयोग करने के बजाय, Google **Chrome** एक ही मूल के लिए **6 समवर्ती अनुरोधों** की सीमा लगाता है। यदि हम **5** को **ब्लॉक** करते हैं और फिर **6 वां** अनुरोध शुरू करते हैं, तो हम इसे **समय** कर सकते हैं और यदि हम **पीड़ित पृष्ठ को** उसी एंडपॉइंट पर अधिक **अनुरोध भेजने** में सफल होते हैं, तो **6 वां अनुरोध****लंबा** होगा और हम इसे पहचान सकते हैं।
## Performance API Techniques
[`Performance API`](https://developer.mozilla.org/en-US/docs/Web/API/Performance) वेब अनुप्रयोगों के प्रदर्शन मेट्रिक्स के बारे में जानकारी प्रदान करता है, जिसे [`Resource Timing API`](https://developer.mozilla.org/en-US/docs/Web/API/Resource\_Timing\_API) द्वारा और समृद्ध किया गया है। Resource Timing API नेटवर्क अनुरोध समय की विस्तृत निगरानी की अनुमति देती है, जैसे अनुरोधों की अवधि। विशेष रूप से, जब सर्वर अपने उत्तरों में `Timing-Allow-Origin: *` हेडर शामिल करते हैं, तो अतिरिक्त डेटा जैसे ट्रांसफर आकार और डोमेन लुकअप समय उपलब्ध हो जाता है।
इस डेटा की प्रचुरता को [`performance.getEntries`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntries) या [`performance.getEntriesByName`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntriesByName) जैसी विधियों के माध्यम से प्राप्त किया जा सकता है, जो प्रदर्शन से संबंधित जानकारी का एक व्यापक दृश्य प्रदान करता है। इसके अलावा, API निष्पादन समय को मापने की सुविधा प्रदान करता है, जो [`performance.now()`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) से प्राप्त टाइमस्टैम्प के बीच के अंतर की गणना करके किया जाता है। हालाँकि, यह ध्यान देने योग्य है कि Chrome जैसे ब्राउज़रों में कुछ ऑपरेशनों के लिए, `performance.now()` की सटीकता मिलीसेकंड तक सीमित हो सकती है, जो समय माप की बारीकी को प्रभावित कर सकती है।
समय माप के अलावा, प्रदर्शन API को सुरक्षा से संबंधित अंतर्दृष्टि के लिए भी उपयोग किया जा सकता है। उदाहरण के लिए, Chrome में `performance` ऑब्जेक्ट में पृष्ठों की उपस्थिति या अनुपस्थिति `X-Frame-Options` के लागू होने का संकेत दे सकती है। विशेष रूप से, यदि किसी पृष्ठ को `X-Frame-Options` के कारण एक फ्रेम में रेंडर करने से रोका जाता है, तो इसे `performance` ऑब्जेक्ट में रिकॉर्ड नहीं किया जाएगा, जो पृष्ठ की फ्रेमिंग नीतियों के बारे में एक सूक्ष्म संकेत प्रदान करता है।
यह **HTTP प्रतिक्रिया स्थिति कोड** के बीच **अंतर** करने के लिए संभव है क्योंकि जो अनुरोध **त्रुटि** का परिणाम देते हैं वे **प्रदर्शन प्रविष्टि** नहीं बनाते हैं।
पिछली तकनीक में यह भी पहचाना गया कि GC में ब्राउज़र बग के दो मामले हैं जो **संसाधनों को दो बार लोड करते हैं जब वे लोड करने में विफल होते हैं**। इसका परिणाम प्रदर्शन API में कई प्रविष्टियों में हो सकता है और इस प्रकार इसे पहचाना जा सकता है।
यह तकनीक उस तालिका में पाई गई थी जो उल्लेखित पेपर में थी लेकिन इसके बारे में कोई विवरण नहीं मिला। हालाँकि, आप इसे [https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak) में स्रोत कोड की जांच करके पा सकते हैं।
एक हमलावर यह पहचान सकता है कि क्या एक अनुरोध का परिणाम एक खाली HTTP प्रतिक्रिया शरीर में हुआ क्योंकि **खाली पृष्ठ कुछ ब्राउज़रों में प्रदर्शन प्रविष्टि नहीं बनाते हैं**।
* **Summary:** सुरक्षा आश्वासन में XSS ऑडिटर का उपयोग करते हुए, हमलावर प्रतिक्रिया में परिवर्तनों का अवलोकन करके विशिष्ट वेबपृष्ठ तत्वों का पता लगा सकते हैं जब तैयार किए गए पेलोड ऑडिटर के फ़िल्टरिंग तंत्र को सक्रिय करते हैं।
सुरक्षा आश्वासन (SA) में, XSS ऑडिटर, जो मूल रूप से क्रॉस-साइट स्क्रिप्टिंग (XSS) हमलों को रोकने के लिए डिज़ाइन किया गया था, को संवेदनशील जानकारी लीक करने के लिए विपरीत रूप से शोषित किया जा सकता है। हालाँकि, यह अंतर्निहित विशेषता Google Chrome (GC) से हटा दी गई थी, लेकिन यह SA में अभी भी मौजूद है। 2013 में, ब्रौन और हाइडरिच ने प्रदर्शित किया कि XSS ऑडिटर अनजाने में वैध स्क्रिप्टों को अवरुद्ध कर सकता है, जिससे झूठे सकारात्मक उत्पन्न होते हैं। इसके आधार पर, शोधकर्ताओं ने जानकारी निकालने और क्रॉस-ओरिजिन पृष्ठों पर विशिष्ट सामग्री का पता लगाने के लिए तकनीकों का विकास किया, जिसे XS-Leaks के रूप में जाना जाता है, जिसे पहले टेराडा द्वारा रिपोर्ट किया गया था और हेयेस द्वारा एक ब्लॉग पोस्ट में विस्तृत किया गया था। हालाँकि ये तकनीकें GC में XSS ऑडिटर के लिए विशिष्ट थीं, यह पाया गया कि SA में, XSS ऑडिटर द्वारा अवरुद्ध पृष्ठ प्रदर्शन API में प्रविष्टियाँ उत्पन्न नहीं करते हैं, जिससे संवेदनशील जानकारी लीक होने का एक तरीका प्रकट होता है।
यदि किसी पृष्ठ को **iframe** में **रेंडर** करने की **अनुमति नहीं है**, तो यह **प्रदर्शन प्रविष्टि** नहीं बनाता है। परिणामस्वरूप, एक हमलावर प्रतिक्रिया हेडर **`X-Frame-Options`** का पता लगा सकता है।\
यदि आप एक **embed****tag** का उपयोग करते हैं तो वही होता है।
उसी तरह, XS-Leak के वर्णित एक **संसाधन जो डाउनलोड किया गया है** क्योंकि ContentDisposition हेडर के कारण, भी **प्रदर्शन प्रविष्टि** नहीं बनाता है। यह तकनीक सभी प्रमुख ब्राउज़रों में काम करती है।
हमने एक XS-Leak उदाहरण पाया जो कुछ ब्राउज़रों के व्यवहार का दुरुपयोग करता है जो क्रॉस-ओरिजिन अनुरोधों के लिए बहुत अधिक जानकारी लॉग करते हैं। मानक एक उपसमुच्चय विशेषताओं को शून्य पर सेट करने के लिए परिभाषित करता है जो क्रॉस-ओरिजिन संसाधनों के लिए होनी चाहिए। हालाँकि, **SA** में यह पता लगाना संभव है कि क्या उपयोगकर्ता **लक्ष्य पृष्ठ** द्वारा **रीडायरेक्ट** किया गया है, **Performance API** को क्वेरी करके और **redirectStart समय डेटा** की जांच करके।
GC में, **रीडायरेक्ट** के परिणामस्वरूप अनुरोधों के लिए **अवधि****नकारात्मक** होती है और इस प्रकार इसे **अलग** किया जा सकता है उन अनुरोधों से जो रीडायरेक्ट का परिणाम नहीं देते हैं।
कुछ मामलों में, **nextHopProtocol प्रविष्टि** को लीक तकनीक के रूप में उपयोग किया जा सकता है। GC में, जब **CORP हेडर** सेट होता है, तो nextHopProtocol **खाली** होगा। ध्यान दें कि SA CORP-सक्षम संसाधनों के लिए प्रदर्शन प्रविष्टि नहीं बनाएगा।
सेवा कार्यकर्ता इवेंट-चालित स्क्रिप्ट संदर्भ होते हैं जो एक मूल पर चलते हैं। वे एक वेब पृष्ठ के बैकग्राउंड में चलते हैं और संसाधनों को इंटरसेप्ट, संशोधित और **कैश** कर सकते हैं ताकि ऑफ़लाइन वेब एप्लिकेशन बनाया जा सके।\
यदि एक **संसाधन कैश** किया गया है एक **सेवा कार्यकर्ता** द्वारा, तो इसे **iframe** के माध्यम से एक्सेस किया जाएगा, संसाधन **सेवा कार्यकर्ता कैश** से **लोड** होगा।\
यह पता लगाने के लिए कि क्या संसाधन **सेवा कार्यकर्ता** कैश से **लोड** किया गया था, **Performance API** का उपयोग किया जा सकता है।\
यह एक टाइमिंग हमले के साथ भी किया जा सकता है (अधिक जानकारी के लिए पेपर की जांच करें)।
The `MediaError` इंटरफेस का संदेश प्रॉपर्टी उन संसाधनों की अद्वितीय पहचान करता है जो एक विशिष्ट स्ट्रिंग के साथ सफलतापूर्वक लोड होते हैं। एक हमलावर इस विशेषता का लाभ उठाकर संदेश सामग्री का अवलोकन कर सकता है, जिससे वह क्रॉस-ओरिजिन संसाधन की प्रतिक्रिया स्थिति का अनुमान लगा सकता है।
यह तकनीक एक हमलावर को **क्रॉस-ओरिजिन साइट के पुनर्निर्देश का गंतव्य निकालने** की अनुमति देती है, जो यह दर्शाती है कि Webkit-आधारित ब्राउज़र CORS अनुरोधों को कैसे संभालते हैं। विशेष रूप से, जब एक **CORS-सक्षम अनुरोध** को एक लक्षित साइट पर भेजा जाता है जो उपयोगकर्ता स्थिति के आधार पर पुनर्निर्देशित करती है और ब्राउज़र बाद में अनुरोध को अस्वीकार करता है, तो **पुनर्निर्देश के लक्ष्य का पूरा URL** त्रुटि संदेश के भीतर प्रकट होता है। यह भेद्यता न केवल पुनर्निर्देश के तथ्य को उजागर करती है बल्कि पुनर्निर्देश के अंत बिंदु और किसी भी **संवेदनशील क्वेरी पैरामीटर** को भी उजागर करती है जो इसमें हो सकते हैं।
एक हमलावर **विस्तृत त्रुटि संदेशों** का लाभ उठाकर क्रॉस-ओरिजिन प्रतिक्रियाओं के आकार का अनुमान लगा सकता है। यह Subresource Integrity (SRI) के तंत्र के कारण संभव है, जो यह सुनिश्चित करने के लिए अखंडता विशेषता का उपयोग करता है कि संसाधन, जो अक्सर CDNs से लाए जाते हैं, में छेड़छाड़ नहीं की गई है। SRI को क्रॉस-ओरिजिन संसाधनों पर काम करने के लिए, इन्हें **CORS-सक्षम** होना चाहिए; अन्यथा, ये अखंडता जांच के अधीन नहीं होते। सुरक्षा आश्वासन (SA) में, CORS त्रुटि XS-Leak की तरह, एक त्रुटि संदेश को एक अखंडता विशेषता के साथ एक फ़ेच अनुरोध के बाद कैप्चर किया जा सकता है जो विफल हो जाता है। हमलावर जानबूझकर **इस त्रुटि को ट्रिगर कर सकते हैं** किसी भी अनुरोध की अखंडता विशेषता में **बोगस हैश मान** असाइन करके। SA में, परिणामी त्रुटि संदेश अनजाने में अनुरोधित संसाधन की सामग्री लंबाई को प्रकट करता है। यह जानकारी लीक एक हमलावर को प्रतिक्रिया के आकार में भिन्नताओं का पता लगाने की अनुमति देती है, जो परिष्कृत XS-Leak हमलों के लिए रास्ता प्रशस्त करती है।
* **Summary:** यदि हम पीड़ित की वेबसाइट को CSP में केवल अनुमति देते हैं और यह एक अलग डोमेन पर पुनर्निर्देशित करने की कोशिश करता है, तो CSP एक पहचानने योग्य त्रुटि को ट्रिगर करेगा।
एक XS-Leak CSP का उपयोग कर यह पता लगा सकता है कि क्या एक क्रॉस-ओरिजिन साइट को एक अलग मूल पर पुनर्निर्देशित किया गया था। यह लीक पुनर्निर्देश का पता लगा सकता है, लेकिन इसके अतिरिक्त, पुनर्निर्देश लक्ष्य का डोमेन भी लीक करता है। इस हमले का मूल विचार है **हमलावर साइट पर लक्षित डोमेन की अनुमति देना**। एक बार जब लक्षित डोमेन पर एक अनुरोध जारी किया जाता है, तो यह **पुनर्निर्देशित** होता है एक क्रॉस-ओरिजिन डोमेन पर। **CSP** इसके लिए पहुंच को अवरुद्ध करता है और एक **उल्लंघन रिपोर्ट बनाता है जो लीक तकनीक के रूप में उपयोग की जाती है**। ब्राउज़र के आधार पर, **यह रिपोर्ट पुनर्निर्देश के लक्ष्य स्थान को लीक कर सकती है**।\
आधुनिक ब्राउज़र यह नहीं बताएंगे कि इसे किस URL पर पुनर्निर्देशित किया गया था, लेकिन आप अभी भी यह पता लगा सकते हैं कि एक क्रॉस-ओरिजिन पुनर्निर्देश को ट्रिगर किया गया था।
ब्राउज़र सभी वेबसाइटों के लिए एक साझा कैश का उपयोग कर सकते हैं। उनके मूल की परवाह किए बिना, यह पता लगाना संभव है कि क्या लक्षित पृष्ठ ने **विशिष्ट फ़ाइल** का अनुरोध किया है।
यदि एक पृष्ठ केवल तभी एक छवि लोड करता है जब उपयोगकर्ता लॉग इन होता है, तो आप **संसाधन को अमान्य** कर सकते हैं (ताकि यह अब कैश में न हो, अधिक जानकारी लिंक देखें), **एक अनुरोध करें** जो उस संसाधन को लोड कर सकता है और **खराब अनुरोध के साथ संसाधन लोड करने की कोशिश करें** (जैसे, एक लंबे संदर्भ हेडर का उपयोग करके)। यदि संसाधन लोड **किसी त्रुटि को ट्रिगर नहीं करता है**, तो इसका मतलब है कि यह **कैश किया गया** था।
Google Chrome (GC) में एक नया फीचर वेब पृष्ठों को **एक सामग्री सुरक्षा नीति (CSP)** प्रस्तावित करने की अनुमति देता है, जो iframe तत्व पर एक विशेषता सेट करके किया जाता है, जिसमें नीति निर्देश HTTP अनुरोध के साथ भेजे जाते हैं। सामान्यतः, अंतर्निहित सामग्री को **इसका अधिकृत करना चाहिए HTTP हेडर के माध्यम से**, या एक **त्रुटि पृष्ठ प्रदर्शित होता है**। हालाँकि, यदि iframe पहले से ही CSP द्वारा शासित है और प्रस्तावित नीति अधिक प्रतिबंधात्मक नहीं है, तो पृष्ठ सामान्य रूप से लोड होगा। यह तंत्र एक हमलावर को **क्रॉस-ओरिजिन पृष्ठ के विशिष्ट CSP निर्देशों का पता लगाने** के लिए एक मार्ग खोलता है, त्रुटि पृष्ठ की पहचान करके। हालांकि इस भेद्यता को ठीक किया गया था, हमारे निष्कर्ष एक **नए लीक तकनीक** का पता लगाते हैं जो त्रुटि पृष्ठ का पता लगाने में सक्षम है, यह सुझाव देते हुए कि अंतर्निहित समस्या को कभी पूरी तरह से संबोधित नहीं किया गया था।
CORP हेडर एक अपेक्षाकृत नया वेब प्लेटफ़ॉर्म सुरक्षा फीचर है जो सेट होने पर **दिए गए संसाधन के लिए नो-CORS क्रॉस-ओरिजिन अनुरोधों को अवरुद्ध करता है**। हेडर की उपस्थिति का पता लगाया जा सकता है, क्योंकि CORP के साथ सुरक्षित संसाधन **लाए जाने पर त्रुटि फेंकेंगे**।
### CORS error on Origin Reflection misconfiguration <a href="#cors-error-on-origin-reflection-misconfiguration" id="cors-error-on-origin-reflection-misconfiguration"></a>
* **Summary**: यदि Origin हेडर को `Access-Control-Allow-Origin` हेडर में परावर्तित किया जाता है, तो यह जांचना संभव है कि क्या संसाधन पहले से कैश में है।
यदि **Origin हेडर** को `Access-Control-Allow-Origin` हेडर में **परावर्तित** किया जा रहा है, तो एक हमलावर इस व्यवहार का दुरुपयोग कर **CORS** मोड में **संसाधन को लाने** की कोशिश कर सकता है। यदि **त्रुटि****ट्रिगर नहीं होती है**, तो इसका मतलब है कि इसे **वेब से सही तरीके से प्राप्त किया गया था**, यदि त्रुटि **ट्रिगर होती है**, तो इसका मतलब है कि इसे **कैश से एक्सेस किया गया था** (त्रुटि इसलिए प्रकट होती है क्योंकि कैश एक प्रतिक्रिया को CORS हेडर के साथ बचाता है जो मूल डोमेन की अनुमति देता है और हमलावर के डोमेन की नहीं)**।\
ध्यान दें कि यदि मूल परावर्तित नहीं होता है लेकिन एक वाइल्डकार्ड का उपयोग किया जाता है (`Access-Control-Allow-Origin: *`), तो यह काम नहीं करेगा।
`redirect: "manual"` और अन्य पैरामीटर के साथ Fetch API का उपयोग करके एक अनुरोध सबमिट करने पर, `response.type` विशेषता को पढ़ना संभव है और यदि यह `opaqueredirect` के बराबर है, तो प्रतिक्रिया एक पुनर्निर्देश थी।
एक हमलावर क्रॉस-ओरिजिन HTTP प्रतिक्रिया में क्रॉस-ओरिजिन ओपनर नीति (COOP) हेडर की उपस्थिति का अनुमान लगा सकता है। COOP का उपयोग वेब अनुप्रयोगों द्वारा बाहरी साइटों को मनमाने विंडो संदर्भ प्राप्त करने से रोकने के लिए किया जाता है। इस हेडर की दृश्यता को **`contentWindow` संदर्भ** तक पहुंचने का प्रयास करके पहचाना जा सकता है। उन परिदृश्यों में जहां COOP को शर्तों के अनुसार लागू किया जाता है, **`opener` प्रॉपर्टी** एक स्पष्ट संकेतक बन जाती है: यह COOP सक्रिय होने पर **undefined** होती है, और इसके अभाव में **defined** होती है।
### URL Max Length - Server Side
* **Inclusion Methods**: Fetch API, HTML Elements
* **Detectable Difference**: Status Code / Content
* **Summary:** पुनर्निर्देश प्रतिक्रिया की लंबाई के कारण प्रतिक्रियाओं में भिन्नताओं का पता लगाना संभव है, जो इतनी बड़ी हो सकती है कि सर्वर त्रुटि के साथ पुनः खेलता है और एक अलर्ट उत्पन्न होता है।
यदि सर्वर-साइड पुनर्निर्देश **पुनर्निर्देश में उपयोगकर्ता इनपुट** और **अतिरिक्त डेटा** का उपयोग करता है। इस व्यवहार का पता लगाना संभव है क्योंकि सामान्यतः **सर्वर** की **सीमा अनुरोध लंबाई** होती है। यदि **उपयोगकर्ता डेटा****लंबाई - 1** है, क्योंकि **पुनर्निर्देश****उस डेटा** का उपयोग कर रहा है और **कुछ अतिरिक्त जोड़ रहा है**, तो यह **त्रुटि को ट्रिगर करेगा जिसे त्रुटि घटनाओं के माध्यम से पता लगाया जा सकता है**।
यदि आप किसी तरह उपयोगकर्ता को कुकीज़ सेट कर सकते हैं, तो आप इस हमले को **पर्याप्त कुकीज़ सेट करके** भी कर सकते हैं ([**कुकी बम**](hacking-with-cookies/cookie-bomb.md)) ताकि **सही प्रतिक्रिया** के **बढ़े हुए आकार** के साथ एक **त्रुटि** ट्रिगर हो। इस मामले में, याद रखें कि यदि आप इस अनुरोध को एक ही साइट से ट्रिगर करते हैं, तो `<script>` स्वचालित रूप से कुकीज़ भेजेगा (ताकि आप त्रुटियों की जांच कर सकें)।\
**कुकी बम + XS-Search** का एक उदाहरण इस लेख के इरादित समाधान में पाया जा सकता है: [https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended)
`SameSite=None` या एक ही संदर्भ में होना इस प्रकार के हमले के लिए सामान्यतः आवश्यक है।
### URL Max Length - Client Side
* **Inclusion Methods**: Pop-ups
* **Detectable Difference**: Status Code / Content
* **Summary:** पुनर्निर्देश प्रतिक्रिया की लंबाई के कारण प्रतिक्रियाओं में भिन्नताओं का पता लगाना संभव है, जो एक अनुरोध के लिए बहुत बड़ी हो सकती है कि एक भिन्नता का पता लगाया जा सके।
[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_ व्यावहारिक कारणों से और अंतःप्रक्रिया संचार में सेवा से इनकार की समस्याओं से बचने के लिए URLs को अधिकतम लंबाई **2MB** तक सीमित करता है।
इसलिए यदि **पुनर्निर्देश URL में एक मामले में बड़ा उत्तर दिया गया है**, तो इसे **2MB से बड़ा URL** के साथ पुनर्निर्देशित करना संभव है ताकि **लंबाई सीमा** को हिट किया जा सके। जब ऐसा होता है, तो Chrome एक **`about:blank#blocked`** पृष्ठ दिखाता है।
**ध्यान देने योग्य भिन्नता** यह है कि यदि **पुनर्निर्देश****पूर्ण** था, तो `window.origin` एक **त्रुटि** फेंकता है क्योंकि एक क्रॉस ओरिजिन उस जानकारी तक पहुंच नहीं सकता। हालाँकि, यदि **सीमा** हिट की गई थी और लोड किया गया पृष्ठ **`about:blank#blocked`** था, तो विंडो का **`origin`** मूल के रूप में बना रहता है, जो एक **सुलभ जानकारी** है।
**2MB** तक पहुँचने के लिए आवश्यक सभी अतिरिक्त जानकारी को प्रारंभिक URL में एक **हैश** के माध्यम से जोड़ा जा सकता है ताकि इसे **पुनर्निर्देश में** उपयोग किया जा सके।
यदि एक ब्राउज़र के लिए **अनुक्रमित** पुनर्निर्देशों की अधिकतम संख्या **20** है, तो एक हमलावर **19 पुनर्निर्देशों** के साथ अपने पृष्ठ को लोड करने की कोशिश कर सकता है और अंततः **पीड़ित को** परीक्षण किए गए पृष्ठ पर भेज सकता है। यदि एक **त्रुटि** ट्रिगर होती है, तो इसका मतलब है कि पृष्ठ **पीड़ित को पुनर्निर्देशित** करने की कोशिश कर रहा था।
**History API** JavaScript कोड को ब्राउज़र इतिहास में हेरफेर करने की अनुमति देता है, जो **उपयोगकर्ता द्वारा देखे गए पृष्ठों को सहेजता है**। एक हमलावर लंबाई प्रॉपर्टी का उपयोग एक समावेशन विधि के रूप में कर सकता है: JavaScript और HTML नेविगेशन का पता लगाने के लिए।\
**`history.length`** की जांच करना, एक उपयोगकर्ता को **एक पृष्ठ पर नेविगेट** करने के लिए कहना, **इसे वापस** उसी मूल पर **बदलना** और **`history.length`** के नए मान की जांच करना।
एक हमलावर JavaScript कोड का उपयोग करके **फ्रेम/पॉप-अप स्थान को अनुमानित URL में हेरफेर कर सकता है** और **तुरंत****इसे `about:blank` में बदल सकता है**। यदि इतिहास की लंबाई बढ़ गई है, तो इसका मतलब है कि URL सही था और इसे **बढ़ने का समय मिला** क्योंकि यदि URL वही है तो इसे फिर से लोड नहीं किया जाता। यदि यह नहीं बढ़ा, तो इसका मतलब है कि यह **अनुमानित URL को लोड करने की कोशिश की गई** थी, लेकिन क्योंकि हम **तुरंत बाद में****`about:blank`** लोड करते हैं, **इतिहास की लंबाई कभी नहीं बढ़ी** जब अनुमानित URL लोड किया गया।
`iframe` या `window.open` के माध्यम से खोले गए **वेब में फ्रेम की संख्या** की गणना करना **उपयोगकर्ता की स्थिति** की पहचान करने में मदद कर सकता है।\
इसके अलावा, यदि पृष्ठ में हमेशा समान संख्या में फ्रेम होते हैं, तो फ्रेम की संख्या की **निरंतर** जांच करना एक **पैटर्न** की पहचान करने में मदद कर सकता है जो जानकारी लीक कर सकता है।
इस तकनीक का एक उदाहरण यह है कि क्रोम में, एक **PDF** को **फ्रेम गिनती** के साथ **पता लगाया** जा सकता है क्योंकि आंतरिक रूप से `embed` का उपयोग किया जाता है। कुछ कंटेंट पर नियंत्रण की अनुमति देने वाले [Open URL Parameters](https://bugs.chromium.org/p/chromium/issues/detail?id=64309#c113) हैं जैसे `zoom`, `view`, `page`, `toolbar` जहां यह तकनीक दिलचस्प हो सकती है।
HTML तत्वों के माध्यम से जानकारी का लीक होना वेब सुरक्षा में एक चिंता का विषय है, विशेष रूप से जब उपयोगकर्ता की जानकारी के आधार पर गतिशील मीडिया फ़ाइलें उत्पन्न की जाती हैं, या जब वॉटरमार्क जोड़े जाते हैं, जिससे मीडिया का आकार बदलता है। हमलावर इस जानकारी का विश्लेषण करके संभावित राज्यों के बीच भेद करने के लिए इसका लाभ उठा सकते हैं।
* **HTMLMediaElement**: यह तत्व मीडिया की `duration` और `buffered` समय को प्रकट करता है, जिसे इसके API के माध्यम से एक्सेस किया जा सकता है। [HTMLMediaElement के बारे में अधिक पढ़ें](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement)
* **HTMLVideoElement**: यह `videoHeight` और `videoWidth` को प्रकट करता है। कुछ ब्राउज़रों में, `webkitVideoDecodedByteCount`, `webkitAudioDecodedByteCount`, और `webkitDecodedFrameCount` जैसे अतिरिक्त प्रॉपर्टीज उपलब्ध हैं, जो मीडिया सामग्री के बारे में अधिक गहन जानकारी प्रदान करते हैं। [HTMLVideoElement के बारे में अधिक पढ़ें](https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement)
* **getVideoPlaybackQuality()**: यह फ़ंक्शन वीडियो प्लेबैक गुणवत्ता के बारे में विवरण प्रदान करता है, जिसमें `totalVideoFrames` शामिल है, जो वीडियो डेटा की मात्रा को इंगित कर सकता है। [getVideoPlaybackQuality() के बारे में अधिक पढ़ें](https://developer.mozilla.org/en-US/docs/Web/API/VideoPlaybackQuality)
* **HTMLImageElement**: यह तत्व एक छवि की `height` और `width` को लीक करता है। हालाँकि, यदि एक छवि अमान्य है, तो ये प्रॉपर्टीज 0 लौटाएंगी, और `image.decode()` फ़ंक्शन अस्वीकृत हो जाएगा, जो यह संकेत करता है कि छवि को सही तरीके से लोड करने में विफलता हुई। [HTMLImageElement के बारे में अधिक पढ़ें](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement)
वेब अनुप्रयोग उपयोगकर्ता की स्थिति के आधार पर वेबसाइट स्टाइलिंग को बदल सकते हैं। क्रॉस-ओरिजिन CSS फ़ाइलों को **HTML लिंक तत्व** के साथ हमलावर पृष्ठ पर एम्बेड किया जा सकता है, और **नियम** हमलावर पृष्ठ पर **लागू** किए जाएंगे। यदि एक पृष्ठ गतिशील रूप से इन नियमों को बदलता है, तो एक हमलावर उपयोगकर्ता की स्थिति के आधार पर इन **भिन्नताओं** का **पता लगा** सकता है।\
एक लीक तकनीक के रूप में, हमलावर `window.getComputedStyle` विधि का उपयोग करके एक विशिष्ट HTML तत्व की **CSS** प्रॉपर्टीज़ को **पढ़** सकता है। परिणामस्वरूप, यदि प्रभावित तत्व और प्रॉपर्टी का नाम ज्ञात है, तो एक हमलावर मनमाने CSS प्रॉपर्टीज़ को पढ़ सकता है।
CSS `:visited` चयनकर्ता का उपयोग URLs को अलग तरीके से स्टाइल करने के लिए किया जाता है यदि उन्हें उपयोगकर्ता द्वारा पहले देखा गया हो। पहले, `getComputedStyle()` विधि का उपयोग इन स्टाइल भिन्नताओं की पहचान करने के लिए किया जा सकता था। हालाँकि, आधुनिक ब्राउज़रों ने इस विधि को लिंक की स्थिति को प्रकट करने से रोकने के लिए सुरक्षा उपाय लागू किए हैं। इन उपायों में हमेशा यह लौटाना शामिल है कि जैसे लिंक को देखा गया हो और `:visited` चयनकर्ता के साथ लागू की जा सकने वाली शैलियों को प्रतिबंधित करना शामिल है।
इन प्रतिबंधों के बावजूद, यह अप्रत्यक्ष रूप से लिंक की देखी गई स्थिति का पता लगाने के लिए संभव है। एक तकनीक में उपयोगकर्ता को CSS से प्रभावित क्षेत्र के साथ बातचीत करने के लिए धोखा देना शामिल है, विशेष रूप से `mix-blend-mode` प्रॉपर्टी का उपयोग करना। यह प्रॉपर्टी तत्वों को उनके पृष्ठभूमि के साथ मिश्रित करने की अनुमति देती है, संभावित रूप से उपयोगकर्ता की बातचीत के आधार पर देखी गई स्थिति को प्रकट करती है।
इसके अलावा, लिंक के रेंडरिंग समय का लाभ उठाकर बिना उपयोगकर्ता की बातचीत के पता लगाया जा सकता है। चूंकि ब्राउज़र देखे गए और न देखे गए लिंक को अलग-अलग तरीके से रेंडर कर सकते हैं, इससे रेंडरिंग में मापने योग्य समय का अंतर आ सकता है। एक प्रमाणित अवधारणा (PoC) का उल्लेख एक क्रोमियम बग रिपोर्ट में किया गया था, जो इस तकनीक को कई लिंक का उपयोग करके समय के अंतर को बढ़ाने के लिए प्रदर्शित करता है, जिससे देखी गई स्थिति को समय विश्लेषण के माध्यम से पता लगाया जा सकता है।
इन प्रॉपर्टीज़ और विधियों के बारे में अधिक जानकारी के लिए, उनके दस्तावेज़ पृष्ठों पर जाएँ:
* **Summary:** Google Chrome में, जब एक पृष्ठ को X-Frame-Options प्रतिबंधों के कारण क्रॉस-ओरिजिन साइट पर एम्बेड करने से रोका जाता है, तो एक समर्पित त्रुटि पृष्ठ प्रदर्शित होता है।
क्रोम में, यदि `X-Frame-Options` हेडर "deny" या "same-origin" पर सेट किया गया है और इसे एक ऑब्जेक्ट के रूप में एम्बेड किया गया है, तो एक त्रुटि पृष्ठ दिखाई देता है। क्रोम इस ऑब्जेक्ट के `contentDocument` प्रॉपर्टी के लिए एक खाली दस्तावेज़ ऑब्जेक्ट (null के बजाय) लौटाता है, जो कि iframe या अन्य ब्राउज़रों में नहीं होता है। हमलावर इसका लाभ उठाकर खाली दस्तावेज़ का पता लगा सकते हैं, जो उपयोगकर्ता की स्थिति के बारे में जानकारी प्रकट कर सकता है, विशेष रूप से यदि डेवलपर्स असंगत रूप से X-Frame-Options हेडर सेट करते हैं, अक्सर त्रुटि पृष्ठों को नजरअंदाज करते हैं। सुरक्षा हेडर के प्रति जागरूकता और सुसंगत अनुप्रयोग महत्वपूर्ण हैं ताकि ऐसे लीक को रोका जा सके।
`Content-Disposition` हेडर, विशेष रूप से `Content-Disposition: attachment`, ब्राउज़र को सामग्री को डाउनलोड करने के लिए निर्देशित करता है न कि इसे इनलाइन प्रदर्शित करने के लिए। इस व्यवहार का लाभ उठाकर यह पता लगाया जा सकता है कि क्या उपयोगकर्ता के पास एक पृष्ठ तक पहुंच है जो फ़ाइल डाउनलोड को ट्रिगर करता है। क्रोमियम-आधारित ब्राउज़रों में, इस डाउनलोड व्यवहार का पता लगाने के लिए कुछ तकनीकें हैं:
* जब एक फ़ाइल क्रोमियम-आधारित ब्राउज़रों में डाउनलोड की जाती है, तो ब्राउज़र विंडो के नीचे एक डाउनलोड बार दिखाई देता है।
* विंडो की ऊँचाई में परिवर्तनों की निगरानी करके, हमलावर डाउनलोड बार के प्रकट होने का अनुमान लगा सकते हैं, यह सुझाव देते हुए कि एक डाउनलोड शुरू किया गया है।
2.**iframe के साथ डाउनलोड नेविगेशन**:
* जब एक पृष्ठ `Content-Disposition: attachment` हेडर का उपयोग करके फ़ाइल डाउनलोड को ट्रिगर करता है, तो यह एक नेविगेशन इवेंट का कारण नहीं बनता है।
* सामग्री को एक iframe में लोड करके और नेविगेशन इवेंट्स की निगरानी करके, यह जांचना संभव है कि क्या सामग्री का निपटान फ़ाइल डाउनलोड का कारण बनता है (कोई नेविगेशन नहीं) या नहीं।
3.**iframe के बिना डाउनलोड नेविगेशन**:
* iframe तकनीक के समान, यह विधि `window.open` का उपयोग करने में शामिल है।
* नए खोले गए विंडो में नेविगेशन इवेंट्स की निगरानी करके यह पता लगाया जा सकता है कि क्या फ़ाइल डाउनलोड को ट्रिगर किया गया था (कोई नेविगेशन नहीं) या यदि सामग्री इनलाइन प्रदर्शित की गई है (नेविगेशन होता है)।
उन परिदृश्यों में जहां केवल लॉगिन किए गए उपयोगकर्ता ऐसे डाउनलोड को ट्रिगर कर सकते हैं, इन तकनीकों का उपयोग उपयोगकर्ता की प्रमाणीकरण स्थिति का अप्रत्यक्ष रूप से अनुमान लगाने के लिए किया जा सकता है।
यह इस तकनीक को दिलचस्प बनाता है: क्रोम अब **कैश विभाजन** करता है, और नए खोले गए पृष्ठ का कैश कुंजी है: `(https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m =xxx)`, लेकिन यदि मैं एक ngrok पृष्ठ खोलता हूँ और इसका उपयोग करता हूँ, तो कैश कुंजी होगी: `(https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx)`, **कैश कुंजी अलग है**, इसलिए कैश साझा नहीं किया जा सकता। आप यहाँ अधिक विवरण पा सकते हैं: [कैश को विभाजित करके सुरक्षा और गोपनीयता प्राप्त करना](https://developer.chrome.com/blog/http-cache-partitioning/)\
([**यहाँ**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/) से टिप्पणी)
यदि एक साइट `example.com``*.example.com/resource` से एक संसाधन शामिल करती है, तो वह संसाधन **उसी कैशिंग कुंजी** के साथ होगा जैसे कि यदि संसाधन को सीधे **शीर्ष स्तर की नेविगेशन** के माध्यम से अनुरोध किया गया हो। इसका कारण यह है कि कैशिंग कुंजी शीर्ष स्तर के _eTLD+1_ और फ्रेम _eTLD+1_ से बनी होती है।
क्योंकि कैश तक पहुंचना संसाधन को लोड करने की तुलना में तेज़ है, यह संभव है कि एक पृष्ठ के स्थान को बदलने का प्रयास करें और इसे 20ms (उदाहरण के लिए) के बाद रद्द करें। यदि रोकने के बाद मूल बदल गया, तो इसका मतलब है कि संसाधन कैश किया गया था।\
या बस **संभावित रूप से कैश किए गए पृष्ठ पर कुछ फ़ेच भेजें और यह मापें कि इसमें कितना समय लगता है**।
* **Summary:** यह संभव है कि एक संसाधन को लोड करने का प्रयास करें और लोड होने से पहले इसे रोक दें। यदि एक त्रुटि उत्पन्न होती है, तो संसाधन कैश किया गया था या नहीं।
_**fetch**_ और _**setTimeout**_ का उपयोग करें एक **AbortController** के साथ यह पता लगाने के लिए कि **संसाधन कैश किया गया है** और ब्राउज़र कैश से एक विशिष्ट संसाधन को निकालने के लिए। इसके अलावा, यह प्रक्रिया नए सामग्री को कैश किए बिना होती है।
* **Summary:** यह संभव है कि **निर्मित कार्यों को ओवरराइट करें** और उनके तर्कों को पढ़ें जो कि **क्रॉस-ओरिजिन स्क्रिप्ट** से भी हैं (जिसे सीधे नहीं पढ़ा जा सकता), यह **मूल्यवान जानकारी लीक** कर सकता है।
* **Summary:** सेवा श्रमिकों का उपयोग करके एक वेब के निष्पादन समय को मापें।
* **Code Example**:
दी गई स्थिति में, हमलावर अपने एक डोमेन में एक **सेवा श्रमिक** को पंजीकृत करने की पहल करता है, विशेष रूप से "attacker.com"। इसके बाद, हमलावर मुख्य दस्तावेज़ से लक्षित वेबसाइट में एक नई विंडो खोलता है और **सेवा श्रमिक** को एक टाइमर शुरू करने के लिए निर्देशित करता है। जैसे ही नई विंडो लोड होना शुरू होती है, हमलावर पिछले चरण में प्राप्त संदर्भ को **सेवा श्रमिक** द्वारा प्रबंधित पृष्ठ पर नेविगेट करता है।
पिछले चरण में शुरू किए गए अनुरोध के आगमन पर, **सेवा श्रमिक****204 (No Content)** स्थिति कोड के साथ प्रतिक्रिया करता है, प्रभावी रूप से नेविगेशन प्रक्रिया को समाप्त करता है। इस बिंदु पर, **सेवा श्रमिक** पहले चरण में शुरू किए गए टाइमर से एक माप कैप्चर करता है। यह माप उस अवधि से प्रभावित होता है जो नेविगेशन प्रक्रिया में देरी का कारण बनती है।
{% hint style="warning" %}
एक निष्पादन समय में, यह **नेटवर्क कारकों** को समाप्त करना संभव है ताकि **अधिक सटीक माप** प्राप्त किया जा सके। उदाहरण के लिए, पृष्ठ द्वारा उपयोग किए जाने वाले संसाधनों को लोड करने से पहले लोड करना।
{% endhint %}
### Fetch Timing
* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Timing (आमतौर पर पृष्ठ सामग्री, स्थिति कोड के कारण)
* **Summary:** एक अनुरोध करने में लगने वाले समय को मापने के लिए [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) का उपयोग करें। अन्य घड़ियों का उपयोग किया जा सकता है।
* **Summary:** `window.open` का उपयोग करके अनुरोध करने में लगने वाले समय को मापने के लिए [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) का उपयोग करें। अन्य घड़ियों का उपयोग किया जा सकता है।
[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) का उपयोग करें ताकि आसानी से **वर्कफ़्लो** का निर्माण और **स्वचालित** किया जा सके जो दुनिया के **सबसे उन्नत** सामुदायिक उपकरणों द्वारा संचालित हो।\
यहाँ आप क्रॉस-ओरिजिन HTML से जानकारी निकालने की तकनीकें पा सकते हैं **HTML सामग्री को इंजेक्ट** करके। ये तकनीकें उन मामलों में दिलचस्प हैं जहां किसी भी कारण से आप **HTML इंजेक्ट कर सकते हैं लेकिन आप JS कोड इंजेक्ट नहीं कर सकते**।
यदि आपको **सामग्री निकालने** की आवश्यकता है और आप **गुप्त के पहले HTML जोड़ सकते हैं**, तो आपको **सामान्य लटकते मार्कअप तकनीकों** की जांच करनी चाहिए।\
हालाँकि, यदि किसी भी कारण से आपको **चर द्वारा चर** करना **अनिवार्य** है (शायद संचार कैश हिट के माध्यम से है) तो आप इस ट्रिक का उपयोग कर सकते हैं।
HTML में **छवियों** में एक "**loading**" विशेषता होती है जिसका मान "**lazy**" हो सकता है। इस मामले में, छवि तब लोड होगी जब इसे देखा जाएगा और पृष्ठ लोड होने के दौरान नहीं:
इसलिए, आप जो कर सकते हैं वह है **कई जंक कैरेक्टर्स जोड़ना** (उदाहरण के लिए **हजारों "W"**) **गुप्त के पहले वेब पेज को भरने के लिए या कुछ ऐसा जोड़ना जैसे**`<br><canvas height="1850px"></canvas><br>.`\
फिर यदि उदाहरण के लिए हमारी **इंजेक्शन ध्वज के पहले दिखाई देती है**, तो **छवि****लोड** होगी, लेकिन यदि **ध्वज के बाद** दिखाई देती है, तो ध्वज + जंक **इसे लोड होने से रोक देगा** (आपको यह तय करने के लिए खेलना होगा कि कितनी जंक डालनी है)। यही [**इस लेख में**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/) हुआ।
यह टेक्स्ट बॉट को पेज में किसी भी टेक्स्ट तक पहुँचने के लिए बनाएगा जो टेक्स्ट `SECR` को शामिल करता है। चूंकि वह टेक्स्ट रहस्य है और यह **इमेज के ठीक नीचे** है, **इमेज केवल तभी लोड होगी जब अनुमानित रहस्य सही होगा**। तो आपके पास **रहस्य को कैरेक्टर द्वारा कैरेक्टर निकालने के लिए आपका ओरेकल है**।
Some code example to exploit this: [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/) पर भी। इन तकनीकों से बचने के लिए अधिक जानकारी के लिए वहां देखें।
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.
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
