XS-Search/XS-Leaks
Last updated
**** का उपयोग करके दुनिया के सबसे उन्नत सामुदायिक उपकरणों द्वारा संचालित कार्यप्रवाहों को आसानी से बनाएं और स्वचालित करें। आज ही एक्सेस प्राप्त करें:
बुनियादी जानकारी
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 डेवलपर्स को उच्च-रिज़ॉल्यूशन समय माप प्राप्त करने की अनुमति देती है। हमलावरों द्वारा उपयोग किए जाने वाले कई API हैं जो निहित घड़ियाँ बनाने के लिए दुरुपयोग किए जा सकते हैं: Broadcast Channel API, Message Channel API, requestAnimationFrame, setTimeout, CSS एनिमेशन, और अन्य। अधिक जानकारी के लिए: https://xsleaks.dev/docs/attacks/timing-attacks/clocks।
इवेंट हैंडलर तकनीकें
Onload/Onerror
शामिल करने की विधियाँ: फ्रेम, HTML तत्व
पता लगाने योग्य अंतर: स्थिति कोड
सारांश: यदि एक संसाधन को लोड करने का प्रयास करते समय onerror/onload इवेंट ट्रिगर होते हैं जब संसाधन सफलतापूर्वक/असफलता से लोड होता है, तो स्थिति कोड का पता लगाना संभव है।
कोड उदाहरण JS से स्क्रिप्ट ऑब्जेक्ट लोड करने का प्रयास करता है, लेकिन अन्य टैग जैसे ऑब्जेक्ट, स्टाइलशीट, छवियाँ, ऑडियोज़ भी उपयोग किए जा सकते हैं। इसके अलावा, टैग को सीधे इंजेक्ट करना और टैग के अंदर onload और onerror इवेंट्स को घोषित करना भी संभव है (JS से इंजेक्ट करने के बजाय)।
इस हमले का एक स्क्रिप्ट-रहित संस्करण भी है:
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)
Summary: The performance.now() API का उपयोग यह मापने के लिए किया जा सकता है कि एक अनुरोध करने में कितना समय लगता है। हालाँकि, अन्य घड़ियाँ भी उपयोग की जा सकती हैं, जैसे कि PerformanceLongTaskTiming API जो 50ms से अधिक समय तक चलने वाले कार्यों की पहचान कर सकती हैं।
Code Example: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events another example in:
Onload Timing + Forced Heavy Task
This technique is just like the previous one, but the attacker will also force some action to take a relevant amount time when the answer is positive or negative and measure that time.
performance.now + Force heavy taskunload/beforeunload Timing
Inclusion Methods: Frames
Detectable Difference: Timing (generally due to Page Content, Status Code)
Summary: The SharedArrayBuffer clock का उपयोग यह मापने के लिए किया जा सकता है कि एक अनुरोध करने में कितना समय लगता है। अन्य घड़ियाँ भी उपयोग की जा सकती हैं।
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)
Summary: The performance.now() API का उपयोग यह मापने के लिए किया जा सकता है कि एक अनुरोध करने में कितना समय लगता है। अन्य घड़ियाँ भी उपयोग की जा सकती हैं।
It has been observed that in the absence of Framing Protections, the time required for a page and its subresources to load over the network can be measured by an attacker. This measurement is typically possible because the onload handler of an iframe is triggered only after the completion of resource loading and JavaScript execution. To bypass the variability introduced by script execution, an attacker might employ the sandbox attribute within the <iframe>. The inclusion of this attribute restricts numerous functionalities, notably the execution of JavaScript, thereby facilitating a measurement that is predominantly influenced by network performance.
#ID + error + onload
Inclusion Methods: Frames
Detectable Difference: Page Content
More info:
Summary: यदि आप सही सामग्री को एक्सेस करते समय पृष्ठ में त्रुटि उत्पन्न कर सकते हैं और किसी भी सामग्री को एक्सेस करते समय इसे सही तरीके से लोड कर सकते हैं, तो आप सभी जानकारी निकालने के लिए एक लूप बना सकते हैं बिना समय मापे।
Code Example:
मान लीजिए कि आप iframe के अंदर गुप्त सामग्री वाला पृष्ठ डाल सकते हैं।
आप पीड़ित को खोजने के लिए iframe का उपयोग करके "flag" वाला फ़ाइल खोजने के लिए कह सकते हैं (उदाहरण के लिए CSRF का शोषण करते हुए)। iframe के अंदर आप जानते हैं कि onload event हमेशा कम से कम एक बार निष्पादित होगा। फिर, आप iframe के URL को बदल सकते हैं लेकिन केवल URL के 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
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
Summary: id या name attribute से संवेदनशील डेटा लीक करें।
यह संभव है कि आप iframe के अंदर एक पृष्ठ लोड करें और #id_value का उपयोग करके पृष्ठ को iframe के तत्व पर ध्यान केंद्रित करने के लिए कहें, यदि एक onblur संकेत सक्रिय होता है, तो ID तत्व मौजूद है।
आप portal टैग के साथ भी वही हमला कर सकते हैं।
postMessage Broadcasts
Inclusion Methods: Frames, Pop-ups
Detectable Difference: API Usage
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 कनेक्शनों की संख्या को लीक करता है।
यह पहचानना संभव है कि एक लक्ष्य पृष्ठ कितने 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 हमलावर को पता लगाने की अनुमति देता है जब एक क्रॉस-ओरिजिन पृष्ठ भुगतान अनुरोध शुरू करता है।
क्योंकि केवल एक भुगतान अनुरोध एक समय में सक्रिय हो सकता है, यदि लक्ष्य वेबसाइट भुगतान अनुरोध API का उपयोग कर रही है, तो इस API का उपयोग करने के लिए कोई भी आगे के प्रयास विफल होंगे, और एक JavaScript अपवाद का कारण बनेंगे। हमलावर इसे नियमित रूप से भुगतान API UI दिखाने का प्रयास करके शोषण कर सकता है। यदि एक प्रयास अपवाद का कारण बनता है, तो लक्ष्य वेबसाइट वर्तमान में इसका उपयोग कर रही है। हमलावर इन नियमित प्रयासों को UI बनाने के तुरंत बाद बंद करके छिपा सकता है।
Timing the Event Loop
Inclusion Methods:
Detectable Difference: Timing (generally due to Page Content, Status Code)
Summary: एक वेब के निष्पादन समय को मापें जो एकल-थ्रेडेड JS इवेंट लूप का दुरुपयोग करता है।
Code Example:
JavaScript एक एकल-थ्रेडेड इवेंट लूप समवर्ती मॉडल पर काम करता है, जिसका अर्थ है कि यह एक समय में केवल एक कार्य निष्पादित कर सकता है। इस विशेषता का उपयोग यह मापने के लिए किया जा सकता है कि एक अलग मूल से कोड को निष्पादित करने में कितना समय लगता है। एक हमलावर अपने कोड के निष्पादन समय को इवेंट लूप में माप सकता है, लगातार निश्चित गुणों के साथ इवेंट भेजकर। ये इवेंट तब संसाधित होंगे जब इवेंट पूल खाली होगा। यदि अन्य मूल भी उसी पूल में इवेंट भेज रहे हैं, तो एक हमलावर अपने कार्यों के निष्पादन में देरी को देखकर यह अनुमान लगा सकता है कि इन बाहरी इवेंट्स को निष्पादित करने में कितना समय लगता है। देरी के लिए इवेंट लूप की निगरानी करने की यह विधि विभिन्न मूलों से कोड के निष्पादन समय को प्रकट कर सकती है, संभावित रूप से संवेदनशील जानकारी को उजागर कर सकती है।
एक निष्पादन समय में नेटवर्क कारकों को हटाना संभव है ताकि अधिक सटीक माप प्राप्त किया जा सके। उदाहरण के लिए, पृष्ठ द्वारा उपयोग किए जाने वाले संसाधनों को लोड करने से पहले लोड करना।
Busy Event Loop
Inclusion Methods:
Detectable Difference: Timing (generally due to Page Content, Status Code)
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)
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: एक अनुरोध जो त्रुटियों का परिणाम देता है, संसाधन समय प्रविष्टि नहीं बनाएगा।
यह संभव है कि आप HTTP प्रतिक्रिया स्थिति कोड के बीच भेद कर सकते हैं क्योंकि जो अनुरोध त्रुटि का परिणाम देते हैं वे प्रदर्शन प्रविष्टि नहीं बनाते हैं।
Style Reload Error
Inclusion Methods: HTML Elements
Detectable Difference: Status Code
More info: https://xsinator.com/paper.pdf (5.2)
Summary: एक ब्राउज़र बग के कारण, त्रुटियों का परिणाम देने वाले अनुरोध दो बार लोड होते हैं।
पिछली तकनीक में यह भी पहचाना गया कि GC में ब्राउज़र बग के दो मामले हैं जो संसाधनों को दो बार लोड करते हैं जब वे लोड करने में विफल होते हैं। इसका परिणाम प्रदर्शन API में कई प्रविष्टियों में हो सकता है और इस प्रकार इसे पहचाना जा सकता है।
Request Merging Error
Inclusion Methods: HTML Elements
Detectable Difference: Status Code
More info: https://xsinator.com/paper.pdf (5.2)
Summary: त्रुटियों का परिणाम देने वाले अनुरोधों को मर्ज नहीं किया जा सकता है।
यह तकनीक उस तालिका में पाई गई थी जो उल्लेखित पेपर में थी लेकिन इसके बारे में कोई विवरण नहीं मिला। हालाँकि, आप इसे 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: खाली प्रतिक्रियाएँ संसाधन समय प्रविष्टियाँ नहीं बनाती हैं।
एक हमलावर यह पहचान सकता है कि क्या एक अनुरोध का परिणाम खाली HTTP प्रतिक्रिया शरीर में हुआ क्योंकि कुछ ब्राउज़रों में खाली पृष्ठ प्रदर्शन प्रविष्टि नहीं बनाते हैं।
XSS-Auditor Leak
Inclusion Methods: Frames
Detectable Difference: Page Content
More info: https://xsinator.com/paper.pdf (5.2)
Summary: सुरक्षा आश्वासन में XSS ऑडिटर का उपयोग करते हुए, हमलावर प्रतिक्रिया में परिवर्तनों का अवलोकन करके विशिष्ट वेबपृष्ठ तत्वों का पता लगा सकते हैं जब तैयार किए गए पेलोड ऑडिटर के फ़िल्टरिंग तंत्र को सक्रिय करते हैं।
सुरक्षा आश्वासन (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
Summary: X-Frame-Options हेडर वाला संसाधन संसाधन समय प्रविष्टि नहीं बनाता है।
यदि किसी पृष्ठ को 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 में संसाधन समय प्रविष्टियाँ नहीं बनाते हैं।
XS-Leak के वर्णित के समान, एक संसाधन जो डाउनलोड किया गया है क्योंकि ContentDisposition हेडर के कारण, यह भी प्रदर्शन प्रविष्टि नहीं बनाता है। यह तकनीक सभी प्रमुख ब्राउज़रों में काम करती है।
Redirect Start Leak
Inclusion Methods: Frames
Detectable Difference: Redirect
More info: https://xsinator.com/paper.pdf (5.2)
Summary: संसाधन समय प्रविष्टि एक रीडायरेक्ट के प्रारंभ समय को लीक करती है।
हमने एक 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: रीडायरेक्ट होने पर समय प्रविष्टियों की अवधि नकारात्मक होती है।
GC में, रीडायरेक्ट के परिणामस्वरूप अनुरोधों के लिए अवधि नकारात्मक होती है और इस प्रकार इसे पहचान किया जा सकता है कि अनुरोध रीडायरेक्ट के परिणामस्वरूप है या नहीं।
CORP Leak
Inclusion Methods: Frames
Detectable Difference: Header
More info: https://xsinator.com/paper.pdf (5.2)
Summary: CORP द्वारा संरक्षित संसाधन संसाधन समय प्रविष्टियाँ नहीं बनाते हैं।
कुछ मामलों में, nextHopProtocol प्रविष्टि को लीक तकनीक के रूप में उपयोग किया जा सकता है। GC में, जब CORP हेडर सेट होता है, तो nextHopProtocol खाली होगा। ध्यान दें कि SA CORP-सक्षम संसाधनों के लिए प्रदर्शन प्रविष्टि नहीं बनाएगा।
Service Worker
Inclusion Methods: Frames
Detectable Difference: API Usage
Summary: एक विशिष्ट मूल के लिए सेवा कार्यकर्ता पंजीकृत है या नहीं, इसका पता लगाएं।
Code Example:
सेवा कार्यकर्ता इवेंट-चालित स्क्रिप्ट संदर्भ होते हैं जो एक मूल पर चलते हैं। वे एक वेब पृष्ठ के बैकग्राउंड में चलते हैं और संसाधनों को इंटरसेप्ट, संशोधित और कैश कर सकते हैं ताकि ऑफ़लाइन वेब एप्लिकेशन बनाया जा सके। यदि एक संसाधन कैश द्वारा सेवा कार्यकर्ता के माध्यम से एक्सेस किया जाता है, तो संसाधन सेवा कार्यकर्ता कैश से लोड होगा। यह पहचानने के लिए कि क्या संसाधन सेवा कार्यकर्ता कैश से लोड किया गया था, Performance API का उपयोग किया जा सकता है। यह एक टाइमिंग हमले के साथ भी किया जा सकता है (अधिक जानकारी के लिए पेपर देखें)।
Cache
Inclusion Methods: Fetch API
Detectable Difference: Timing
Summary: यह जांचना संभव है कि क्या एक संसाधन कैश में संग्रहीत था।
Performance API का उपयोग करके यह जांचना संभव है कि क्या एक संसाधन कैश में है।
Network Duration
Inclusion Methods: Fetch API
Detectable Difference: Page Content
Summary: यह संभव है कि
performanceAPI से एक अनुरोध की नेटवर्क अवधि प्राप्त की जा सके।
Error Messages Technique
Media Error
Inclusion Methods: HTML Elements (Video, Audio)
Detectable Difference: Status Code
Summary: फ़ायरफ़ॉक्स में एक क्रॉस-ओरिजिन अनुरोध की स्थिति कोड को सटीक रूप से लीक करना संभव है।
Code Example: https://jsbin.com/nejatopusi/1/edit?html,css,js,output
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
Summary: यदि हम पीड़ित की वेबसाइट को CSP में केवल अनुमति देते हैं और यह एक अलग डोमेन पर पुनर्निर्देशित करने की कोशिश करता है, तो CSP एक पहचानने योग्य त्रुटि को ट्रिगर करेगा।
एक XS-Leak CSP का उपयोग कर यह पता लगा सकता है कि क्या एक क्रॉस-ओरिजिन साइट को एक अलग मूल पर पुनर्निर्देशित किया गया था। यह लीक पुनर्निर्देश का पता लगा सकता है, लेकिन इसके अतिरिक्त, पुनर्निर्देश लक्ष्य का डोमेन भी लीक करता है। इस हमले का मूल विचार है कि हमलावर साइट पर लक्षित डोमेन की अनुमति दें। एक बार जब लक्षित डोमेन पर एक अनुरोध जारी किया जाता है, तो यह पुनर्निर्देशित होता है एक क्रॉस-ओरिजिन डोमेन पर। CSP इसके लिए पहुंच को अवरुद्ध करता है और एक उल्लंघन रिपोर्ट बनाता है जो लीक तकनीक के रूप में उपयोग की जाती है। ब्राउज़र के आधार पर, यह रिपोर्ट पुनर्निर्देश के लक्ष्य स्थान को लीक कर सकती है। आधुनिक ब्राउज़र यह नहीं बताते कि इसे किस URL पर पुनर्निर्देशित किया गया था, लेकिन आप अभी भी यह पता लगा सकते हैं कि एक क्रॉस-ओरिजिन पुनर्निर्देश को ट्रिगर किया गया था।
Cache
Inclusion Methods: Frames, Pop-ups
Detectable Difference: Page Content
Summary: फ़ाइल को कैश से हटा दें। लक्षित पृष्ठ खोलता है यह जांचता है कि क्या फ़ाइल कैश में मौजूद है।
Code Example:
ब्राउज़र सभी वेबसाइटों के लिए एक साझा कैश का उपयोग कर सकते हैं। उनके मूल की परवाह किए बिना, यह पता लगाना संभव है कि क्या लक्षित पृष्ठ ने विशिष्ट फ़ाइल का अनुरोध किया है।
यदि एक पृष्ठ केवल तभी एक छवि लोड करता है जब उपयोगकर्ता लॉग इन होता है, तो आप संसाधन को अमान्य कर सकते हैं (ताकि यह अब कैश में न हो, अधिक जानकारी लिंक देखें), एक अनुरोध करें जो उस संसाधन को लोड कर सकता है और संसाधन को खराब अनुरोध के साथ लोड करने की कोशिश करें (जैसे एक लंबे संदर्भ हेडर का उपयोग करके)। यदि संसाधन लोड किसी त्रुटि को ट्रिगर नहीं करता है, तो इसका मतलब है कि यह कैश किया गया था।
CSP Directive
Inclusion Methods: Frames
Detectable Difference: Header
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
Summary: क्रॉस-ओरिजिन संसाधन नीति (CORP) के साथ सुरक्षित संसाधन एक अस्वीकृत मूल से लाए जाने पर त्रुटि फेंकेंगे।
Code Example: https://xsinator.com/testing.html#CORP%20Leak
CORP हेडर एक अपेक्षाकृत नया वेब प्लेटफ़ॉर्म सुरक्षा फीचर है जो सेट होने पर दिए गए संसाधन के लिए नो-CORS क्रॉस-ओरिजिन अनुरोधों को अवरुद्ध करता है। हेडर की उपस्थिति का पता लगाया जा सकता है, क्योंकि CORP के साथ सुरक्षित संसाधन लाए जाने पर त्रुटि फेंकेंगे।
CORB
Inclusion Methods: HTML Elements
Detectable Difference: Headers
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
Summary: यदि Origin हेडर को हेडर
Access-Control-Allow-Originमें परावर्तित किया गया है, तो यह जांचना संभव है कि क्या संसाधन पहले से ही कैश में है।
यदि Origin हेडर को परावर्तित किया जा रहा है हेडर Access-Control-Allow-Origin में, तो एक हमलावर इस व्यवहार का दुरुपयोग कर सकता है CORS मोड में संसाधन को लाने के लिए। यदि एक त्रुटि ट्रिगर नहीं होती है, तो इसका मतलब है कि इसे वेब से सही तरीके से प्राप्त किया गया था, यदि एक त्रुटि ट्रिगर होती है, तो इसका मतलब है कि इसे कैश से एक्सेस किया गया था (त्रुटि इसलिए प्रकट होती है क्योंकि कैश एक प्रतिक्रिया को CORS हेडर के साथ बचाता है जो मूल डोमेन की अनुमति देता है और हमलावर के डोमेन की नहीं)**।
ध्यान दें कि यदि मूल परावर्तित नहीं होता है लेकिन एक वाइल्डकार्ड का उपयोग किया जाता है (Access-Control-Allow-Origin: *), तो यह काम नहीं करेगा।
Readable Attributes Technique
Fetch Redirect
Inclusion Methods: Fetch API
Detectable Difference: Status Code
Summary: GC और SA पुनर्निर्देश समाप्त होने के बाद प्रतिक्रिया के प्रकार (opaque-redirect) की जांच करने की अनुमति देते हैं।
redirect: "manual" और अन्य पैरामीटर के साथ Fetch API का उपयोग करके एक अनुरोध सबमिट करते समय, यह response.type विशेषता को पढ़ना संभव है और यदि यह opaqueredirect के बराबर है, तो प्रतिक्रिया एक पुनर्निर्देश थी।
COOP
Inclusion Methods: Pop-ups
Detectable Difference: Header
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
Summary: पुनर्निर्देश प्रतिक्रिया की लंबाई के कारण प्रतिक्रियाओं में भिन्नताओं का पता लगाना संभव है, जो इतनी बड़ी हो सकती है कि सर्वर एक त्रुटि के साथ पुनः खेलता है और एक अलर्ट उत्पन्न होता है।
यदि एक सर्वर-साइड पुनर्निर्देश पुनर्निर्देशन में उपयोगकर्ता इनपुट और अतिरिक्त डेटा का उपयोग करता है। इस व्यवहार का पता लगाना संभव है क्योंकि आमतौर पर सर्वर के पास सीमित अनुरोध लंबाई होती है। यदि उपयोगकर्ता डेटा वह लंबाई - 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
Summary: पुनर्निर्देश प्रतिक्रिया की लंबाई के कारण प्रतिक्रियाओं में भिन्नताओं का पता लगाना संभव है, जो एक अनुरोध के लिए बहुत बड़ी हो सकती है कि एक भिन्नता का पता लगाया जा सके।
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 में एक हैश के माध्यम से जोड़ा जा सकता है ताकि इसे पुनर्निर्देश में उपयोग किया जा सके।
URL Max Length - Client SideMax Redirects
Inclusion Methods: Fetch API, Frames
Detectable Difference: Status Code
Summary: ब्राउज़र के पुनर्निर्देश की सीमा का उपयोग URL पुनर्निर्देशों की घटना का पता लगाने के लिए करें।
Code Example: https://xsinator.com/testing.html#Max%20Redirect%20Leak
यदि एक ब्राउज़र के लिए अनुसरण करने के लिए अधिकतम संख्या 20 पुनर्निर्देश है, तो एक हमलावर 19 पुनर्निर्देशों के साथ अपने पृष्ठ को लोड करने का प्रयास कर सकता है और अंततः पीड़ित को परीक्षण किए गए पृष्ठ पर भेज सकता है। यदि एक त्रुटि ट्रिगर होती है, तो इसका मतलब है कि पृष्ठ पीड़ित को पुनर्निर्देशित करने की कोशिश कर रहा था।
History Length
Inclusion Methods: Frames, Pop-ups
Detectable Difference: Redirects
Summary: JavaScript कोड ब्राउज़र इतिहास में हेरफेर करता है और इसे लंबाई प्रॉपर्टी द्वारा एक्सेस किया जा सकता है।
History API JavaScript कोड को ब्राउज़र इतिहास में हेरफेर करने की अनुमति देता है, जो उपयोगकर्ता द्वारा देखे गए पृष्ठों को सहेजता है। एक हमलावर लंबाई प्रॉपर्टी का उपयोग एक समावेशन विधि के रूप में कर सकता है: JavaScript और HTML नेविगेशन का पता लगाने के लिए।
history.length की जांच करना, उपयोगकर्ता को एक पृष्ठ पर नेविगेट करने के लिए कहना, इसे वापस उसी मूल में बदलना और history.length के नए मान की जांच करना।
History Length with same URL
Inclusion Methods: Frames, Pop-ups
Detectable Difference: यदि URL अनुमानित URL के समान है
Summary: यह अनुमान लगाना संभव है कि क्या एक फ्रेम/पॉपअप का स्थान एक विशिष्ट URL में है, इतिहास की लंबाई का दुरुपयोग करके।
Code Example: नीचे
एक हमलावर JavaScript कोड का उपयोग करके फ्रेम/पॉप-अप स्थान को अनुमानित URL में हेरफेर कर सकता है और तुरंत इसे about:blank में बदल सकता है। यदि इतिहास की लंबाई बढ़ गई है, तो इसका मतलब है कि URL सही था और इसे बढ़ने का समय मिला क्योंकि URL को फिर से लोड नहीं किया जाता है यदि यह समान है। यदि यह नहीं बढ़ा, तो इसका मतलब है कि यह अनुमानित URL को लोड करने की कोशिश कर रहा था, लेकिन क्योंकि हम तुरंत बाद में about:blank लोड करते हैं, इतिहास की लंबाई कभी नहीं बढ़ी जब अनुमानित URL लोड किया गया।
Frame Counting
Inclusion Methods: Frames, Pop-ups
Detectable Difference: Page Content
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
Summary: 2 संभावित राज्यों के बीच भेद करने के लिए लीक किए गए मान को पढ़ें
HTML तत्वों के माध्यम से जानकारी का लीक होना वेब सुरक्षा में एक चिंता का विषय है, विशेष रूप से जब उपयोगकर्ता की जानकारी के आधार पर गतिशील मीडिया फ़ाइलें उत्पन्न की जाती हैं, या जब वॉटरमार्क जोड़े जाते हैं, जिससे मीडिया का आकार बदलता है। हमलावर इस जानकारी का विश्लेषण करके संभावित राज्यों के बीच भेद करने के लिए इसका लाभ उठा सकते हैं।
Information Exposed by HTML Elements
HTMLMediaElement: यह तत्व मीडिया की
durationऔरbufferedसमय को प्रकट करता है, जिसे इसके API के माध्यम से एक्सेस किया जा सकता है। HTMLMediaElement के बारे में अधिक पढ़ेंHTMLVideoElement: यह
videoHeightऔरvideoWidthको प्रकट करता है। कुछ ब्राउज़रों में,webkitVideoDecodedByteCount,webkitAudioDecodedByteCount, औरwebkitDecodedFrameCountजैसे अतिरिक्त प्रॉपर्टीज उपलब्ध हैं, जो मीडिया सामग्री के बारे में अधिक गहन जानकारी प्रदान करते हैं। HTMLVideoElement के बारे में अधिक पढ़ेंgetVideoPlaybackQuality(): यह फ़ंक्शन वीडियो प्लेबैक गुणवत्ता के बारे में विवरण प्रदान करता है, जिसमें
totalVideoFramesशामिल है, जो वीडियो डेटा की मात्रा को इंगित कर सकता है। getVideoPlaybackQuality() के बारे में अधिक पढ़ेंHTMLImageElement: यह तत्व एक छवि की
heightऔरwidthको लीक करता है। हालाँकि, यदि एक छवि अमान्य है, तो ये प्रॉपर्टीज 0 लौटाएंगी, औरimage.decode()फ़ंक्शन अस्वीकृत हो जाएगा, जो यह संकेत करता है कि छवि को सही तरीके से लोड करने में विफलता हुई। HTMLImageElement के बारे में अधिक पढ़ें
CSS Property
Inclusion Methods: HTML Elements
Detectable Difference: Page Content
Summary: उपयोगकर्ता की स्थिति या स्थिति के साथ संबंधित वेबसाइट स्टाइलिंग में भिन्नताओं की पहचान करें।
Code Example: https://xsinator.com/testing.html#CSS%20Property%20Leak
वेब अनुप्रयोग उपयोगकर्ता की स्थिति के आधार पर वेबसाइट स्टाइलिंग को बदल सकते हैं। क्रॉस-ओरिजिन CSS फ़ाइलों को HTML लिंक तत्व के साथ हमलावर पृष्ठ पर एम्बेड किया जा सकता है, और नियम हमलावर पृष्ठ पर लागू किए जाएंगे। यदि एक पृष्ठ गतिशील रूप से इन नियमों को बदलता है, तो एक हमलावर उपयोगकर्ता की स्थिति के आधार पर इन भिन्नताओं का पता लगा सकता है।
एक लीक तकनीक के रूप में, हमलावर एक विशिष्ट HTML तत्व की CSS प्रॉपर्टीज को पढ़ने के लिए window.getComputedStyle विधि का उपयोग कर सकता है। परिणामस्वरूप, यदि प्रभावित तत्व और प्रॉपर्टी का नाम ज्ञात है, तो एक हमलावर मनमाने CSS प्रॉपर्टीज को पढ़ सकता है।
CSS History
Inclusion Methods: HTML Elements
Detectable Difference: Page Content
Summary: यह पता करें कि क्या किसी URL पर
:visitedस्टाइल लागू है, जो यह संकेत करता है कि इसे पहले ही देखा गया था
यहाँ के अनुसार, यह हेडलेस क्रोम में काम नहीं कर रहा है।
CSS :visited चयनकर्ता का उपयोग URLs को अलग तरीके से स्टाइल करने के लिए किया जाता है यदि उन्हें उपयोगकर्ता द्वारा पहले देखा गया हो। पहले, getComputedStyle() विधि का उपयोग इन स्टाइल भिन्नताओं की पहचान करने के लिए किया जा सकता था। हालाँकि, आधुनिक ब्राउज़रों ने इस विधि को लिंक की स्थिति को प्रकट करने से रोकने के लिए सुरक्षा उपाय लागू किए हैं। इन उपायों में हमेशा इस तरह से गणना की गई शैली लौटाना शामिल है जैसे कि लिंक को देखा गया हो और :visited चयनकर्ता के साथ लागू की जा सकने वाली शैलियों को प्रतिबंधित करना शामिल है।
इन प्रतिबंधों के बावजूद, यह अप्रत्यक्ष रूप से लिंक की देखी गई स्थिति को पहचानना संभव है। एक तकनीक में उपयोगकर्ता को CSS से प्रभावित क्षेत्र के साथ बातचीत करने के लिए धोखा देना शामिल है, विशेष रूप से mix-blend-mode प्रॉपर्टी का उपयोग करना। यह प्रॉपर्टी तत्वों को उनके पृष्ठभूमि के साथ मिश्रित करने की अनुमति देती है, संभावित रूप से उपयोगकर्ता की बातचीत के आधार पर देखी गई स्थिति को प्रकट करती है।
इसके अलावा, लिंक के रेंडरिंग समय का लाभ उठाकर बिना उपयोगकर्ता की बातचीत के पहचान की जा सकती है। चूंकि ब्राउज़र देखे गए और न देखे गए लिंक को अलग-अलग तरीके से रेंडर कर सकते हैं, इससे रेंडरिंग में मापने योग्य समय का अंतर उत्पन्न हो सकता है। एक प्रमाण अवधारणा (PoC) का उल्लेख एक क्रोमियम बग रिपोर्ट में किया गया था, जो इस तकनीक को कई लिंक का उपयोग करके समय के अंतर को बढ़ाने के लिए प्रदर्शित करता है, जिससे देखी गई स्थिति को समय विश्लेषण के माध्यम से पहचानना संभव हो जाता है।
इन प्रॉपर्टीज और विधियों के बारे में अधिक जानकारी के लिए, उनके दस्तावेज़ पृष्ठों पर जाएँ:
:visited: MDN DocumentationgetComputedStyle(): MDN Documentationmix-blend-mode: MDN Documentation
ContentDocument X-Frame Leak
Inclusion Methods: Frames
Detectable Difference: Headers
Summary: Google Chrome में, जब किसी पृष्ठ को X-Frame-Options प्रतिबंधों के कारण क्रॉस-ओरिजिन साइट पर एम्बेड करने से रोका जाता है, तो एक समर्पित त्रुटि पृष्ठ प्रदर्शित होता है।
क्रोम में, यदि X-Frame-Options हेडर "deny" या "same-origin" पर सेट किया गया है और इसे एक ऑब्जेक्ट के रूप में एम्बेड किया गया है, तो एक त्रुटि पृष्ठ दिखाई देता है। क्रोम इस ऑब्जेक्ट के contentDocument प्रॉपर्टी के लिए एक खाली दस्तावेज़ ऑब्जेक्ट (null के बजाय) लौटाता है, जो कि iframe या अन्य ब्राउज़रों में नहीं होता है। हमलावर इस खाली दस्तावेज़ का पता लगाकर इसका लाभ उठा सकते हैं, जो उपयोगकर्ता की स्थिति के बारे में जानकारी प्रकट कर सकता है, विशेष रूप से यदि डेवलपर्स असंगत रूप से X-Frame-Options हेडर सेट करते हैं, अक्सर त्रुटि पृष्ठों को नजरअंदाज करते हैं। जागरूकता और सुरक्षा हेडर का लगातार अनुप्रयोग ऐसे लीक को रोकने के लिए महत्वपूर्ण है।
Download Detection
Inclusion Methods: Frames, Pop-ups
Detectable Difference: Headers
Summary: एक हमलावर iframe का लाभ उठाकर फ़ाइल डाउनलोड का पता लगा सकता है; iframe की निरंतर पहुंच सफल फ़ाइल डाउनलोड का संकेत देती है।
Content-Disposition हेडर, विशेष रूप से Content-Disposition: attachment, ब्राउज़र को सामग्री को इनलाइन प्रदर्शित करने के बजाय डाउनलोड करने का निर्देश देता है। इस व्यवहार का उपयोग यह पहचानने के लिए किया जा सकता है कि क्या उपयोगकर्ता के पास एक पृष्ठ तक पहुंच है जो फ़ाइल डाउनलोड को ट्रिगर करता है। क्रोमियम-आधारित ब्राउज़रों में, इस डाउनलोड व्यवहार का पता लगाने के लिए कुछ तकनीकें हैं:
डाउनलोड बार मॉनिटरिंग:
जब एक फ़ाइल क्रोमियम-आधारित ब्राउज़रों में डाउनलोड की जाती है, तो ब्राउज़र विंडो के नीचे एक डाउनलोड बार दिखाई देता है।
विंडो की ऊँचाई में परिवर्तनों की निगरानी करके, हमलावर डाउनलोड बार के प्रकट होने का अनुमान लगा सकता है, यह सुझाव देते हुए कि एक डाउनलोड शुरू किया गया है।
iframes के साथ डाउनलोड नेविगेशन:
जब एक पृष्ठ
Content-Disposition: attachmentहेडर का उपयोग करके फ़ाइल डाउनलोड को ट्रिगर करता है, तो यह एक नेविगेशन इवेंट का कारण नहीं बनता है।सामग्री को एक iframe में लोड करके और नेविगेशन इवेंट्स की निगरानी करके, यह जांचना संभव है कि क्या सामग्री का निपटान फ़ाइल डाउनलोड का कारण बनता है (कोई नेविगेशन नहीं) या नहीं।
iframes के बिना डाउनलोड नेविगेशन:
iframe तकनीक के समान, यह विधि
window.openका उपयोग करने में शामिल है।नए खोले गए विंडो में नेविगेशन इवेंट्स की निगरानी करके यह पता लगाया जा सकता है कि क्या फ़ाइल डाउनलोड को ट्रिगर किया गया था (कोई नेविगेशन नहीं) या यदि सामग्री इनलाइन प्रदर्शित की गई थी (नेविगेशन होता है)।
उन परिदृश्यों में जहां केवल लॉगिन किए गए उपयोगकर्ता ऐसे डाउनलोड को ट्रिगर कर सकते हैं, इन तकनीकों का उपयोग उपयोगकर्ता की प्रमाणीकरण स्थिति का अप्रत्यक्ष रूप से अनुमान लगाने के लिए किया जा सकता है।
Partitioned HTTP Cache Bypass
Inclusion Methods: Pop-ups
Detectable Difference: Timing
Summary: एक हमलावर iframe का लाभ उठाकर फ़ाइल डाउनलोड का पता लगा सकता है; iframe की निरंतर पहुंच सफल फ़ाइल डाउनलोड का संकेत देती है।
यह इस तकनीक को दिलचस्प बनाता है: क्रोम में अब कैश विभाजन है, और नए खोले गए पृष्ठ का कैश कुंजी है: (https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m =xxx) लेकिन यदि मैं एक ngrok पृष्ठ खोलता हूँ और इसमें fetch का उपयोग करता हूँ, तो कैश कुंजी होगी: (https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx)। कैश कुंजी अलग है, इसलिए कैश साझा नहीं किया जा सकता। आप यहाँ अधिक विवरण पा सकते हैं: कैश को विभाजित करके सुरक्षा और गोपनीयता प्राप्त करना
(यहाँ से टिप्पणी)
यदि एक साइट example.com *.example.com/resource से एक संसाधन शामिल करती है, तो वह संसाधन उसी कैशिंग कुंजी के साथ होगा जैसे कि यदि संसाधन को सीधे शीर्ष स्तर की नेविगेशन के माध्यम से अनुरोध किया गया हो। इसका कारण यह है कि कैशिंग कुंजी शीर्ष स्तर के eTLD+1 और फ्रेम eTLD+1 से बनी होती है।
क्योंकि कैश तक पहुंचना संसाधन को लोड करने की तुलना में तेज़ है, यह संभव है कि एक पृष्ठ के स्थान को बदलने का प्रयास करें और इसे 20ms (उदाहरण के लिए) के बाद रद्द करें। यदि रोकने के बाद मूल बदल गया, तो इसका मतलब है कि संसाधन कैश किया गया था। या बस संभावित कैश किए गए पृष्ठ पर कुछ fetch भेजें और यह मापें कि इसमें कितना समय लगता है।
Manual Redirect
Inclusion Methods: Fetch API
Detectable Difference: Redirects
Summary: यह पता लगाना संभव है कि क्या fetch अनुरोध का उत्तर एक रीडायरेक्ट है
Code Example:
Fetch with AbortController
Inclusion Methods: Fetch API
Detectable Difference: Timing
Summary: यह संभव है कि एक संसाधन को लोड करने का प्रयास करें और लोड होने से पहले इसे रोक दें। यदि एक त्रुटि उत्पन्न होती है, तो संसाधन कैश किया गया था या नहीं।
fetch और setTimeout का उपयोग करें एक AbortController के साथ यह पता लगाने के लिए कि संसाधन कैश किया गया है और ब्राउज़र कैश से एक विशिष्ट संसाधन को निकालने के लिए। इसके अलावा, यह प्रक्रिया नए सामग्री को कैश किए बिना होती है।
Script Pollution
Inclusion Methods: HTML Elements (script)
Detectable Difference: Page Content
Summary: यह संभव है कि निर्मित फ़ंक्शंस को ओवरराइट करें और उनके तर्कों को पढ़ें जो कि क्रॉस-ओरिजिन स्क्रिप्ट से भी हो सकते हैं (जिसे सीधे नहीं पढ़ा जा सकता), यह मूल्यवान जानकारी लीक कर सकता है।
Service Workers
Inclusion Methods: Pop-ups
Detectable Difference: Page Content
Summary: सेवा श्रमिकों का उपयोग करके एक वेब के निष्पादन समय को मापें।
Code Example:
दी गई स्थिति में, हमलावर अपने एक डोमेन में एक सेवा श्रमिक को पंजीकृत करने की पहल करता है, विशेष रूप से "attacker.com"। इसके बाद, हमलावर मुख्य दस्तावेज़ से लक्षित वेबसाइट में एक नई विंडो खोलता है और सेवा श्रमिक को एक टाइमर शुरू करने का निर्देश देता है। जैसे ही नई विंडो लोड होने लगती है, हमलावर पिछले चरण में प्राप्त संदर्भ को सेवा श्रमिक द्वारा प्रबंधित पृष्ठ पर नेविगेट करता है।
पिछले चरण में शुरू किए गए अनुरोध के आगमन पर, सेवा श्रमिक 204 (No Content) स्थिति कोड के साथ प्रतिक्रिया करता है, प्रभावी रूप से नेविगेशन प्रक्रिया को समाप्त करता है। इस बिंदु पर, सेवा श्रमिक पहले चरण में शुरू किए गए टाइमर से एक माप को कैप्चर करता है। यह माप उस अवधि से प्रभावित होता है जो नेविगेशन प्रक्रिया में देरी का कारण बनती है।
एक निष्पादन समय में, यह संभव है कि नेटवर्क कारकों को समाप्त करें ताकि अधिक सटीक माप प्राप्त किया जा सके। उदाहरण के लिए, पृष्ठ द्वारा उपयोग किए जाने वाले संसाधनों को लोड करने से पहले लोड करना।
Fetch Timing
Inclusion Methods: Fetch API
Detectable Difference: Timing (आमतौर पर पृष्ठ सामग्री, स्थिति कोड के कारण)
Summary: एक अनुरोध करने में लगने वाले समय को मापने के लिए performance.now() का उपयोग करें। अन्य घड़ियों का उपयोग किया जा सकता है।
Cross-Window Timing
Inclusion Methods: Pop-ups
Detectable Difference: Timing (आमतौर पर पृष्ठ सामग्री, स्थिति कोड के कारण)
Summary:
window.openका उपयोग करके अनुरोध करने में लगने वाले समय को मापने के लिए performance.now() का उपयोग करें। अन्य घड़ियों का उपयोग किया जा सकता है।
Trickest का उपयोग करें ताकि आप आसानी से वर्कफ़्लो बना सकें और स्वचालित कर सकें जो दुनिया के सबसे उन्नत सामुदायिक उपकरणों द्वारा संचालित हो। आज ही एक्सेस प्राप्त करें:
With HTML or Re Injection
यहाँ आप क्रॉस-ओरिजिन HTML से जानकारी निकालने की तकनीकें पा सकते हैं HTML सामग्री को इंजेक्ट करके। ये तकनीकें उन मामलों में दिलचस्प हैं जहां किसी भी कारण से आप HTML इंजेक्ट कर सकते हैं लेकिन आप JS कोड इंजेक्ट नहीं कर सकते।
Dangling Markup
Dangling Markup - HTML scriptless injectionImage Lazy Loading
यदि आपको सामग्री निकालने की आवश्यकता है और आप गुप्त के पहले HTML जोड़ सकते हैं, तो आपको सामान्य लटकते मार्कअप तकनीकों की जांच करनी चाहिए। हालाँकि, यदि किसी भी कारण से आपको चर द्वारा चर करना अनिवार्य है (शायद संचार कैश हिट के माध्यम से है) तो आप इस ट्रिक का उपयोग कर सकते हैं।
HTML में छवियों में एक "loading" विशेषता होती है जिसका मान "lazy" हो सकता है। इस मामले में, छवि तब लोड होगी जब इसे देखा जाएगा और न कि जब पृष्ठ लोड हो रहा हो:
इसलिए, आप जो कर सकते हैं वह है कई जंक कैरेक्टर्स जोड़ना (उदाहरण के लिए हजारों "W") गुप्त के पहले वेब पेज को भरने के लिए या कुछ ऐसा जोड़ना जैसे <br><canvas height="1850px"></canvas><br>.
फिर यदि उदाहरण के लिए हमारी इंजेक्शन ध्वज के पहले दिखाई देती है, तो छवि लोड होगी, लेकिन यदि ध्वज के बाद दिखाई देती है, तो ध्वज + जंक इसे लोड होने से रोक देगा (आपको यह तय करने के लिए खेलना होगा कि कितनी जंक डालनी है)। यही इस लेख में हुआ।
एक और विकल्प होगा स्क्रॉल-टू-टेक्स्ट-फ्रैगमेंट का उपयोग करना यदि अनुमति हो:
Scroll-to-text-fragment
हालांकि, आप बॉट को पृष्ठ तक पहुँचने के लिए कुछ ऐसा करते हैं
तो वेब पृष्ठ कुछ इस तरह होगा: https://victim.com/post.html#:~:text=SECR
जहाँ post.html में हमलावर के जंक कैरक्टर और लेज़ी लोड इमेज होती है और फिर बॉट का रहस्य जोड़ा जाता है।
यह पाठ बॉट को पृष्ठ में किसी भी पाठ तक पहुँचने के लिए बनाएगा जिसमें पाठ SECR शामिल है। चूंकि वह पाठ रहस्य है और यह छवि के ठीक नीचे है, छवि केवल तभी लोड होगी जब अनुमानित रहस्य सही होगा। तो आपके पास रहस्य को कैरक्टर द्वारा कैरक्टर निकालने के लिए आपका ओरेकल है।
इसका शोषण करने के लिए कुछ कोड उदाहरण: https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e
इमेज लेज़ी लोडिंग टाइम आधारित
यदि बाहरी छवि को लोड करना संभव नहीं है जो हमलावर को यह संकेत दे सके कि छवि लोड हो गई है, तो एक और विकल्प होगा कि कई बार कैरक्टर का अनुमान लगाने की कोशिश करें और उसे मापें। यदि छवि लोड होती है तो सभी अनुरोधों में अधिक समय लगेगा बनिस्बत इसके कि छवि लोड नहीं होती। यही इस लेख के समाधान में संक्षेप में उपयोग किया गया था:
Event Loop Blocking + Lazy imagesReDoS
Regular expression Denial of Service - ReDoSCSS ReDoS
यदि jQuery(location.hash) का उपयोग किया जाता है, तो यह समय के माध्यम से पता लगाने में संभव है यदि कुछ HTML सामग्री मौजूद है, यह इस कारण से है कि यदि चयनकर्ता main[id='site-main'] मेल नहीं खाता है तो इसे बाकी चयनकर्ताओं की जांच करने की आवश्यकता नहीं है:
CSS Injection
CSS InjectionDefenses
इन तकनीकों से बचाव के लिए https://xsinator.com/paper.pdf में अनुशंसित उपाय हैं और विकी के प्रत्येक अनुभाग में https://xsleaks.dev/ भी। इन तकनीकों से बचने के लिए अधिक जानकारी के लिए वहां देखें।
References
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
