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

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

function alertpoc(){
alert("alert POC");
}
2.html的代碼如下：
2.html：
window.onload = function() {
parent.frames["tt2_3].alertpoc();
}
　　那么，當(dāng)訪問 http://www.A.com/1.html 時(shí)，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上的腳本，或者傳遞信息，實(shí)現(xiàn)跨域操作。
　　什么叫iframe proxy呢?其實(shí)就是做了一次iframe的迭代。
　　如下：
　　http://www.A.com/1.html 中包含一個(gè)iframe，指向 http://www.B.com/3.html
　　http://www.B.com/3.html 中又包含一個(gè)iframe，指向 http://www.A.com/4.html
　　那么這個(gè)3.html就是一個(gè)iframe proxy，通過 3.html 就能從B域 向 A域的 4.html傳遞消息，如果4.html還有一些處理的話，就可以執(zhí)行腳本。
實(shí)例如下：
　　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"); // 調(diào)用 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過了，那么存在什么樣的風(fēng)險(xiǎn)呢?
　　先講跨域的問題。
　　首先，由于4.html在這里關(guān)聯(lián)性最小，所以我們假設(shè)4.html是我們?cè)谟駻下上傳的某個(gè)文件，或者是存在XSS漏洞的某個(gè)頁面。
　　那么對(duì)于域A下的頁面 1.html，它包含了 域B的3.html，當(dāng)域B下的3.html被惡意用戶控制時(shí)，惡意用戶就可以通過4.html，直接攻擊到 1.html
　　所以我們有了第一個(gè)攻擊方法：
　　Attack Vector 1：控制iframe proxy后可以跨域攻擊父頁面
　　由于域B和域A不是同一個(gè)域，所以域A的安全級(jí)別和一些防范措施很可能無法涉及到域B，這種信任上的危機(jī)將帶來一定的風(fēng)險(xiǎn)。
　　請(qǐng)注意和普通掛馬或者是XSS攻擊不同的是，域A上的這個(gè)頁面是我們無法控制或篡改的，但他正好包含了一個(gè)指向域B上頁面的iframe，所以我們才可以通過域B上的那個(gè)頁面跨域攻擊它。
　　比如，www.baidu.com/av.html 可能包含了某個(gè)廣告網(wǎng)站的一些頁面，他使用的是iframe的方式：
　　那么這個(gè)時(shí)候，攻擊者如果能夠控制evil.html，就可以在evil.html 中包含一個(gè)指向 http://www.baidu.com/evilupload.html 的iframe;
　　當(dāng)正常用戶瀏覽 http://www.baidu.com/av.html 時(shí)候，就會(huì)受到來自 evilupload.html 的XSS攻擊， 而攻擊的來源是 http://www.advertise.com/evil.html 發(fā)起的。
　　這種跨域的攻擊將會(huì)極其隱蔽，因?yàn)檎嬲膼阂饽_本是寫在evilupload.html 里的，所以即便查看了 av.html 和 evil.html 的代碼也無法看到任何惡意腳本，只能看到兩個(gè)iframe。
　　對(duì)于IE 6， 甚至可以把 4.html 改名為 4.JPG 或者 4.RAR， 在iframe proxy中引用后，都將執(zhí)行腳本。(想到GIFAR沒?)
　　而Firefox 2 則必須保持為 html 文件才能保證腳本的執(zhí)行。
　　控制evil.html的方法有很多種，最常見的包括直接攻擊域B服務(wù)器、篡改客戶端網(wǎng)絡(luò)中的數(shù)據(jù)、或者是在evil.html 中放置一個(gè) 持久性的XSS，都將導(dǎo)致 evil.html 被控制
　　通過控制 evil.html，調(diào)整不同的iframe src地址，我們可以得到第二種攻擊方法。
　　Attack Vector 2：在iframe proxy中直接引用一個(gè)非持久性XSS(反射XSS)，可以讓該XSS在父窗口中持久存在。
　　很多人非常鄙視非持久性XSS(反射型XSS)，認(rèn)為這種XSS只能依靠欺騙的手段去騙人點(diǎn)擊，才能讓攻擊正常實(shí)施起來。
　　其實(shí)讓非持久性XSS變得持久的方法，已經(jīng)出現(xiàn)過好多次了。比如利用applet、利用flash的AS腳本、利用IE的Ghost 頁面。
　　那么今天這種方法又要多一個(gè)了：利用 Cross Iframe Trick
　　實(shí)例如下：
　　設(shè)想http://www.A.com/4.html 存在一個(gè)XSS漏洞，其代碼如下：
4.html：
//parent.parent.tt1("fvck tt1");
//top.tt1("fvck tt1");
document.write("window.location.href "\' >");
這里存在一個(gè)基于DOM的XSS漏洞，當(dāng)在瀏覽器地址欄里輸入：
http://www.A.com/4.html#'>alert(/XSS/);時(shí)，alert()將被執(zhí)行。
此時(shí)，利用 Cross Iframe技術(shù)，在 3.html 中直接構(gòu)造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雖然沒有跨域風(fēng)險(xiǎn)高，但還是會(huì)帶來一些問題的。
Attack Vector 3：如果域A下的某個(gè)頁面z中，包含了指向域B的兩個(gè)iframe，分別是x和y;那么x能夠通過z，對(duì)y的某些對(duì)象進(jìn)行一定的修改，從而篡改數(shù)據(jù)，或者是篡改函數(shù)的參數(shù)，執(zhí)行腳本。此時(shí)z起著iframe proxy的作用。
　　這段話可能有點(diǎn)拗口，其實(shí)就是父窗口在這里起了iframe proxy的作用。根據(jù)rule 1，我們有以下實(shí)例：
2.html：
window.onload = function() {
parent.frames["tt2_3].document.getElementById("3").value="222";
parent.frames["tt2_3].alertpoc1();
}

2.html將調(diào)用 3.html 中的 alertpoc1()函數(shù)，并修改 input框的值為222
3.html：
//function alertpoc(){ alert("alert POC"); }
function alertpoc1(){ alert(window.location.href); }
　　此時(shí)，訪問http://www.A.com/1.html 后，發(fā)現(xiàn)input的值被成功修改，同事alertpoc1彈出顯示的是3.html的地址。


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

最新評(píng)論