Cross Iframe Trick：the Old New Thing（图）

Attack Vector 3：如果域A下的某个页面z中，包含了指向域B的两个iframe，分别是x和y;那么x能够通过z，对y的某些对象进行一定的修改，从而篡改数据，或者是篡改函数的参数，执行脚本。此时z起着iframe proxy的作用。
　　这段话可能有点拗口，其实就是父窗口在这里起了iframe proxy的作用。根据rule 1，我们有以下实例：
2.html：
window.onload = function() {
parent.frames["tt2_3].document.getElementById("3").value="222";
parent.frames["tt2_3].alertpoc1();
}

2.html将调用 3.html 中的 alertpoc1()函数，并修改 input框的值为222
3.html：
//function alertpoc(){ alert("alert POC"); }
function alertpoc1(){ alert(window.location.href); }
　　此时，访问http://www.A.com/1.html 后，发现input的值被成功修改，同事alertpoc1弹出显示的是3.html的地址。


　　这种攻击实际上还是攻击的 http://www.A.com 下的 1.html 这个页面(注意这个是和普通XSS攻击的本质区别，攻击的目标页面不同)，因为iframe： 3.html 是显示在 1.html 里的。在实际中用到这种情况的可能是某个页面里要显示一个报表，那么这个报表可以采用iframe的方式嵌入在页面中。
　　实施这种攻击，可以随意篡改报表里的数据。攻击来源却是在另外一个iframe里实现的，和当前的1.html 没有直接关系。
　　如果结合JSON Hijacking，直接在2.html中调用 3.html 里的一些回调函数，窃取敏感数据，也可能会起到一些意想不到的作用。因为在这里，我们再次把JSON CallBack函数持久化了，而且json返回的数据将显示在1.html里，更具有欺骗性。
　　所以这第三种攻击方法在篡改数据方面带来了更高的风险。
　　以上可以看出，Cross Iframe Trick最大的优势就是隐蔽性
　　攻击就像来自天外一样，几乎无迹可寻。
　　局限性：
　　1、首先iframe是限制发送cookie的，本地存储的stored cookie将不被发送，只能发送一个session cookie。浏览器的这个安全特性将使得我们使用XSRF的可能性更低。
　　但也不是没有办法，比如在 4.html 里使用一个 window.open() 就能够发送出stored cookie了，当然可能还有更好的方法。
　　不过虽然限制了cookie，导致XSRF会有些困难，但是能够执行目标域下的脚本，还是非常有价值的一件事情，已经可以完成许多攻击了。
　　2、其次，要在A域寻找到这样一个用iframe包含B域的页面，并且去控制iframe中的B域页面，才是最为不容易的事情。这个条件是比较苛刻的。如果有朋友能找到现实网站中的案例，请给我一个反馈。
　　最后，正如最开始所说，要修补这种漏洞非常困难，因为这完全是浏览器的正常功能。如果要限制iframe的话，微软自己在IE里实现了iframe的一个security属性，可以限制框架页面里脚本的执行。也许还有其他的方法可以来对抗，但是，就不是我们今天要讨论的话题了。
　　我虽然只是在理论上提出了Cross Iframe Trick这种威胁，但是我认为这几乎可以算成是一种漏洞类型。它是许多脚本攻击技术的结合应用技巧，而程序员又往往会忽略这些地方。所以这种威胁是真实存在的，而且是可以长期挖掘和利用的一种“漏洞类型”

最新评论