Attack Vector 3：如果域A下的某個頁面z中，包含了指向域B的兩個iframe，分別是x和y;那么x能夠通過z，對y的某些對象進行一定的修改，從而篡改數(shù)據(jù)，或者是篡改函數(shù)的參數(shù)，執(zhí)行腳本。此時z起著iframe proxy的作用。
　　這段話可能有點拗口，其實就是父窗口在這里起了iframe proxy的作用。根據(jù)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()函數(shù)，并修改 input框的值為222
3.html：
//function alertpoc(){ alert("alert POC"); }
function alertpoc1(){ alert(window.location.href); }
　　此時，訪問http://www.A.com/1.html 后，發(fā)現(xiàn)input的值被成功修改，同事alertpoc1彈出顯示的是3.html的地址。


　　這種攻擊實際上還是攻擊的 http://www.A.com 下的 1.html 這個頁面(注意這個是和普通XSS攻擊的本質區(qū)別，攻擊的目標頁面不同)，因為iframe： 3.html 是顯示在 1.html 里的。在實際中用到這種情況的可能是某個頁面里要顯示一個報表，那么這個報表可以采用iframe的方式嵌入在頁面中。
　　實施這種攻擊，可以隨意篡改報表里的數(shù)據(jù)。攻擊來源卻是在另外一個iframe里實現(xiàn)的，和當前的1.html 沒有直接關系。
　　如果結合JSON Hijacking，直接在2.html中調用 3.html 里的一些回調函數(shù)，竊取敏感數(shù)據(jù)，也可能會起到一些意想不到的作用。因為在這里，我們再次把JSON CallBack函數(shù)持久化了，而且json返回的數(shù)據(jù)將顯示在1.html里，更具有欺騙性。
　　所以這第三種攻擊方法在篡改數(shù)據(jù)方面帶來了更高的風險。
　　以上可以看出，Cross Iframe Trick最大的優(yōu)勢就是隱蔽性
　　攻擊就像來自天外一樣，幾乎無跡可尋。
　　局限性：
　　1、首先iframe是限制發(fā)送cookie的，本地存儲的stored cookie將不被發(fā)送，只能發(fā)送一個session cookie。瀏覽器的這個安全特性將使得我們使用XSRF的可能性更低。
　　但也不是沒有辦法，比如在 4.html 里使用一個 window.open() 就能夠發(fā)送出stored cookie了，當然可能還有更好的方法。
　　不過雖然限制了cookie，導致XSRF會有些困難，但是能夠執(zhí)行目標域下的腳本，還是非常有價值的一件事情，已經(jīng)可以完成許多攻擊了。
　　2、其次，要在A域尋找到這樣一個用iframe包含B域的頁面，并且去控制iframe中的B域頁面，才是最為不容易的事情。這個條件是比較苛刻的。如果有朋友能找到現(xiàn)實網(wǎng)站中的案例，請給我一個反饋。
　　最后，正如最開始所說，要修補這種漏洞非常困難，因為這完全是瀏覽器的正常功能。如果要限制iframe的話，微軟自己在IE里實現(xiàn)了iframe的一個security屬性，可以限制框架頁面里腳本的執(zhí)行。也許還有其他的方法可以來對抗，但是，就不是我們今天要討論的話題了。
　　我雖然只是在理論上提出了Cross Iframe Trick這種威脅，但是我認為這幾乎可以算成是一種漏洞類型。它是許多腳本攻擊技術的結合應用技巧，而程序員又往往會忽略這些地方。所以這種威脅是真實存在的，而且是可以長期挖掘和利用的一種“漏洞類型”