我思考了很久才把這里面的錯綜復雜的關系整清楚，我想很多人看我下面的paper會睡著，或者干脆“一目百行”的跳過去，但如果你真的想弄懂，請調試我的 每一個poc，會非常有助于理解(雖然你還是可能會暈)。請尊重俺的勞動成果，碼這么多字不容易。歡迎技術討論，但謝絕沒仔細看就來指手畫腳的。@_@
　　首先，為了幫助大家更好的理解，我先講講這種攻擊能夠達成什么效果：
　　1. 跨域執(zhí)行腳本(IE、Firefox)
　　2. 把非持久性XSS變成持久性XSS
　　3. 跨頁面執(zhí)行腳本
　　4. 瀏覽器將很難修補這一“特性”造成的威脅
　　5. 當然還是有一些條件限制的,本篇只是在理論上描述了這種攻擊。
　　那么，什么是cross iframe，簡單來說就是把iframe做一個迭代，以實現(xiàn)一些iframe之間的交叉數(shù)據(jù)訪問。在正常的web應用中，許多地方都有用到這種技術，比如facebook，比如yahoo。
　　但是由cross iframe引申出來一些安全隱患，則是我這里要探討的重點。
　　以下是我的測試環(huán)境：
　　Windows XP SP2
　　IE 6 SP2 (我只有IE6，沒有IE7，請自行測試IE7)
　　Firefox 2.0.0.16
　　測試域名：
　　www.A.com (/1.html , /4.html)
　　www.B.com (/2.html , /3.html)
　　這次測試主要使用了4個html頁面，請牢記1.html和4.html是在域A下; 2.html和3.html是在域B下
　　首先來看看什么是Cross Iframe， 他們又能干些什么。
　　Rule1: 同一個頁面下的兩個iframe，如果這兩個iframe指向同一個域，那么他們可以互相訪問，并操作對方頁面的腳本。
　　在 www.A.com 上，存在一個 1.html ，包含了兩個iframe，這兩個iframe分別引用了www.B.com 上的兩個頁面。其代碼如下：
1.html:

　　現(xiàn)在我們的目的就是利用 iframe：tt2_2 去調用 iframe：tt2_3里的javascript的函數(shù)。
　　3.html的代碼如下：

function alertpoc(){
alert("alert POC");
}
2.html的代碼如下：
2.html：
window.onload = function() {
parent.frames["tt2_3].alertpoc();
}
　　那么，當訪問 http://www.A.com/1.html 時，iframe：tt2_2中的腳本在www.B.com執(zhí)行了，它通過讀父窗口的iframe：tt2_3，嘗試在其中執(zhí)行腳本函數(shù) alertpoc()。由于tt2_2與tt2_3同在www.B.com 域中，所以他們之間不存在跨域問題，腳本被允許執(zhí)行。



　　Rule2：域B能夠以 iframe proxy 的方式，操作域A上的腳本，或者傳遞信息，實現(xiàn)跨域操作。
　　什么叫iframe proxy呢?其實就是做了一次iframe的迭代。
　　如下：
　　http://www.A.com/1.html 中包含一個iframe，指向 http://www.B.com/3.html
　　http://www.B.com/3.html 中又包含一個iframe，指向 http://www.A.com/4.html
　　那么這個3.html就是一個iframe proxy，通過 3.html 就能從B域 向 A域的 4.html傳遞消息，如果4.html還有一些處理的話，就可以執(zhí)行腳本。
實例如下：
　　1.html的代碼：
1.html：
// 1.html上的彈窗函數(shù)
function tt1(fvck){
alert(fvck);
}
同在 www.A.com 域下的 4.html代碼：
4.html:
//parent.parent.tt1("fvck tt1"); 也可以
top.tt1("fvck tt1"); // 調用 1.html 里的 tt1() 函數(shù)
在 www.B.com 域下的3.html 作用是iframe proxy，其代碼為：
3.html:
var tt1_4 = document.createElement("iframe");
tt1_4.src = "http://www.A.com/4.html";
document.body.appendChild(tt1_4);
訪問 http://www.A.com/1.html 后，將通過 http://www.B.com/3.html ，利用 http://www.A.com/4.html 執(zhí)行 http://www.A.com/1.html 的腳本



　　正確執(zhí)行了腳本。
　　跨域的問題已經(jīng)POC過了，那么存在什么樣的風險呢?
　　先講跨域的問題。
　　首先，由于4.html在這里關聯(lián)性最小，所以我們假設4.html是我們在域A下上傳的某個文件，或者是存在XSS漏洞的某個頁面。
　　那么對于域A下的頁面 1.html，它包含了 域B的3.html，當域B下的3.html被惡意用戶控制時，惡意用戶就可以通過4.html，直接攻擊到 1.html
　　所以我們有了第一個攻擊方法：
　　Attack Vector 1：控制iframe proxy后可以跨域攻擊父頁面
　　由于域B和域A不是同一個域，所以域A的安全級別和一些防范措施很可能無法涉及到域B，這種信任上的危機將帶來一定的風險。
　　請注意和普通掛馬或者是XSS攻擊不同的是，域A上的這個頁面是我們無法控制或篡改的，但他正好包含了一個指向域B上頁面的iframe，所以我們才可以通過域B上的那個頁面跨域攻擊它。
　　比如，www.baidu.com/av.html 可能包含了某個廣告網(wǎng)站的一些頁面，他使用的是iframe的方式：
　　那么這個時候，攻擊者如果能夠控制evil.html，就可以在evil.html 中包含一個指向 http://www.baidu.com/evilupload.html 的iframe;
　　當正常用戶瀏覽 http://www.baidu.com/av.html 時候，就會受到來自 evilupload.html 的XSS攻擊， 而攻擊的來源是 http://www.advertise.com/evil.html 發(fā)起的。
　　這種跨域的攻擊將會極其隱蔽，因為真正的惡意腳本是寫在evilupload.html 里的，所以即便查看了 av.html 和 evil.html 的代碼也無法看到任何惡意腳本，只能看到兩個iframe。
　　對于IE 6， 甚至可以把 4.html 改名為 4.JPG 或者 4.RAR， 在iframe proxy中引用后，都將執(zhí)行腳本。(想到GIFAR沒?)
　　而Firefox 2 則必須保持為 html 文件才能保證腳本的執(zhí)行。
　　控制evil.html的方法有很多種，最常見的包括直接攻擊域B服務器、篡改客戶端網(wǎng)絡中的數(shù)據(jù)、或者是在evil.html 中放置一個 持久性的XSS，都將導致 evil.html 被控制
　　通過控制 evil.html，調整不同的iframe src地址，我們可以得到第二種攻擊方法。
　　Attack Vector 2：在iframe proxy中直接引用一個非持久性XSS(反射XSS)，可以讓該XSS在父窗口中持久存在。
　　很多人非常鄙視非持久性XSS(反射型XSS)，認為這種XSS只能依靠欺騙的手段去騙人點擊，才能讓攻擊正常實施起來。
　　其實讓非持久性XSS變得持久的方法，已經(jīng)出現(xiàn)過好多次了。比如利用applet、利用flash的AS腳本、利用IE的Ghost 頁面。
　　那么今天這種方法又要多一個了：利用 Cross Iframe Trick
　　實例如下：
　　設想http://www.A.com/4.html 存在一個XSS漏洞，其代碼如下：
4.html：
//parent.parent.tt1("fvck tt1");
//top.tt1("fvck tt1");
document.write("window.location.href "\' >");
這里存在一個基于DOM的XSS漏洞，當在瀏覽器地址欄里輸入：
http://www.A.com/4.html#'>alert(/XSS/);時，alert()將被執(zhí)行。
此時，利用 Cross Iframe技術，在 3.html 中直接構造iframe地址為XSS的地址。
3.html：
//function alertpoc(){ alert("alert POC"); }
var tt1_4 = document.createElement("iframe");
tt1_4.src = "http://www.A.com/4.html#\'\>\alert(\"Domain=\" document.domain)\;\\";
document.body.appendChild(tt1_4);
　　訪問 http://www.A.com/1.html 后，4.html里的XSS漏洞將被利用，并彈出可愛的小框框


　　如果說，前面講的兩種方法是利用的Rule 2，那么Rule 1能否利用起來呢?思考后，發(fā)現(xiàn)Rule 1雖然沒有跨域風險高，但還是會帶來一些問題的。
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這種威脅，但是我認為這幾乎可以算成是一種漏洞類型。它是許多腳本攻擊技術的結合應用技巧，而程序員又往往會忽略這些地方。所以這種威脅是真實存在的，而且是可以長期挖掘和利用的一種“漏洞類型”