diff --git a/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md b/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md index b1dd587aa..3d99903c6 100644 --- a/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md +++ b/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md @@ -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) ``` -यदि आप पिछले 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 @@ -61,7 +61,7 @@ alert(parent.secret) +content="script-src 'sha256-iF/bMbiFXal+AAl9tF8N6+KagNWdMlnhLqWkjAocLsk'" /> " if __name__ == "__main__": app.run() ``` -### अन्य पेलोड जो जंगल में पाए गए +#### New (2023-2025) CSP bypass techniques with iframes + +शोध समुदाय लगातार प्रतिबंधात्मक नीतियों को पराजित करने के लिए iframes का दुरुपयोग करने के रचनात्मक तरीकों की खोज कर रहा है। नीचे आप पिछले कुछ वर्षों में प्रकाशित सबसे उल्लेखनीय तकनीकों को पा सकते हैं: + +* **Dangling-markup / named-iframe data-exfiltration (PortSwigger 2023)** – जब एक एप्लिकेशन HTML को दर्शाता है लेकिन एक मजबूत CSP स्क्रिप्ट निष्पादन को रोकता है, तो आप *dangling* ` + + ``` ### 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(); ``` -- दूसरा 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}}