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

有没有办法限制父母在iframe中允许做什么？我正在寻找的是一个围绕Javascript的安全模型,它看起来像:

...



iframe {
  Deny All;
  Allow javascript:AllowedToAccess();
}

iframe script.untrusted {
  Deny All;
}



...

'trusted.html'看起来像:

javascript:window.parent {
  Allow javascript:document.body.offsetHeight;
  Allow javascript:document.title;
}

script.untrusted {
  Deny All;
}

而'SomethingIShouldnt.php'看起来像:

NotAllowedToAccess();

并且'untrusted.js'看起来像:

window.parent.AllowedToAccess();
InternalCall();
window.parent.NotAllowedToAccess();
InternalCall2();
window.parent.jQuery(body).append('
');
window.parent.jQuery('#badid').load('SomethingIShouldn't.php');

(呃...抱歉过度杀戮.)

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

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

简短的回答是否定的,XSRF与iframe无关.

伪造请求是否来自iframe无关紧要.伪造的请求必须来自另一台服务器,以便攻击者利用它.黑客用户iframe,因为它们可用于在XSRF漏洞中伪造帖子请求,因为漏洞利用必须使用javascript自动提交论坛.这是我针对XAMPP编写的真实世界XSRF漏洞,它改变了管理密码.最好在iframe中执行这个javascript/html,这样对受害者来说它是不可见的,但是这个漏洞只能在没有iframe的情况下重定向整个窗口,它仍然会改变管理员的密码.

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