談跨站腳本攻擊與防御的正確應(yīng)用 |
發(fā)布時(shí)間: 2012/8/11 17:26:10 |
以下的文章主要向大家講述的是腳本攻擊與防御的實(shí)際操作技巧,網(wǎng)絡(luò)上曾經(jīng)有過關(guān)于講述跨站腳本攻擊和防御的文案,但是隨著攻擊技術(shù)的不斷進(jìn)步進(jìn)步,以前的關(guān)于跨站腳本攻擊的看法與理論已經(jīng)不能滿足現(xiàn)在的攻擊與防御的需要了,而且由于這種對(duì)于跨站腳本認(rèn)識(shí)上的混亂..... 網(wǎng)絡(luò)上曾經(jīng)有過關(guān)于跨站腳本攻擊與防御的文章,但是隨著攻擊技術(shù)的進(jìn)步,以前的關(guān)于跨站腳本攻擊的看法與理論已經(jīng)不能滿足現(xiàn)在的攻擊與防御的需要了,而且由于這種對(duì)于跨站腳本認(rèn)識(shí)上的混亂,導(dǎo)致現(xiàn)在很多的程序包括現(xiàn)在的動(dòng)網(wǎng)都存在著跨站腳本過濾不嚴(yán)的問題,希望本文能給寫程序的與研究程序的帶來一點(diǎn)思路。 還是首先看看跨站腳本漏洞的成因,所謂跨站腳本漏洞其實(shí)就是Html的注入問題,惡意用戶的輸入沒有經(jīng)過嚴(yán)格的控制進(jìn)入了數(shù)據(jù)庫最終顯示給來訪的用戶,導(dǎo)致可以在來訪用戶的瀏覽器里以瀏覽用戶的身份執(zhí)行HTml代碼,數(shù)據(jù)流程如下: 惡意用戶的Html輸入————>web程序————>進(jìn)入數(shù)據(jù)庫————>web程序————>用戶瀏覽器 這樣我們就可以清楚的看到Html代碼是如何進(jìn)入受害者瀏覽器的了,我們也就可以根據(jù)這個(gè)流程來討論跨站腳本的攻擊與防御了! 1 什么是HTml輸入? 這里給出一個(gè)HTml代碼的示例 很多的程序最終都是將用戶的輸入轉(zhuǎn)換成這種形式的?梢钥吹<>是告訴瀏覽器這是一個(gè)Html標(biāo)記,img是這個(gè)Html標(biāo)記的名稱,src是這個(gè)標(biāo)記的第一個(gè)屬性,=后面是這個(gè)屬性的值,后面的width是第二個(gè)屬性,onerror是標(biāo)記的事件屬性。大家可以看到,一個(gè)Html標(biāo)記是包括很多元素的,并不是傳統(tǒng)意義上的只有輸入<>才會(huì)注入Html,事實(shí)上只要你的輸入處在Html標(biāo)簽內(nèi),產(chǎn)生了新的元素或者屬性,就實(shí)現(xiàn)了跨站腳本攻擊!實(shí)際上大多數(shù)隱秘的跨站腳本攻擊是不需要<>的,因?yàn)楝F(xiàn)在的Ubb標(biāo)簽已經(jīng)讓你處在了Html標(biāo)記之內(nèi),很有意思,不是么? 2 哪里才是罪惡的來源? 既然我們的目標(biāo)是引入代碼在目標(biāo)用戶的瀏覽器內(nèi)執(zhí)行,那么我們來看看哪些地方可以引入HTml代碼吧!如果用戶可以不受限制的引入<>,那么很顯然他可以完全操縱一個(gè)Html標(biāo)記,譬如 這樣的形式,這對(duì)于追求安全的程序來說是絕對(duì)不允許的,所以首先要做轉(zhuǎn)換的就是<>,通過如下代碼: 過濾代碼:
好了,用戶可能不能構(gòu)造自己的HTml標(biāo)記了,那么利用已經(jīng)存在的屬性如何呢?下面的代碼依然可以工作得很好: 因?yàn)楹芏嗟腍tml標(biāo)記里屬性都支持javascript:[code]的形式,很好,很多的程序意識(shí)到了這一點(diǎn),可能做了如下的轉(zhuǎn)換: 過濾代碼
你看,只要發(fā)現(xiàn)以javascript等腳本屬性的形式都會(huì)被過濾掉,失去了:的腳本代碼是起不了作用的!這樣完美了么?事實(shí)上Html屬性的值,注意是值而不是屬性本身是支持&#ASCii這種形式表示的,譬如上面的代碼可以換成這樣: 代碼又執(zhí)行了,呵呵!看來你漏掉了點(diǎn)什么哦,加上這個(gè)代碼吧!
行了,&失去它原來的意義了,用戶不能以其他方式表示Html屬性值了哦!等等,這樣的過濾真可以相信么?只要發(fā)現(xiàn)這種過濾的關(guān)鍵字機(jī)制,饒過就是簡單的問題了: 沒有javascript關(guān)鍵字了哦!注意中間那個(gè)是tab鍵弄出來的!關(guān)鍵字被拆分了哦!這是個(gè)很麻煩的問題,很多人忘記了這些特殊的字符,呵呵!有人想到要過濾空格了,在過濾之前我們再看看其他的一些東西吧!也許我們現(xiàn)在所處的src屬性已經(jīng)無法利用了,但是我們依然可以產(chǎn)生自己的屬性或者事件機(jī)制哦!依然是可以執(zhí)行Html代碼的,首先說說事件機(jī)制吧: 這樣依然可以執(zhí)行代碼的哦!明白問題出在哪了,不是么?有的程序員仿佛明白了,注意我說的是仿佛,動(dòng)網(wǎng)就是一個(gè)典型的例子,事件屬性不是要onerror么?很多人開始用正則表達(dá)式了,發(fā)現(xiàn)關(guān)鍵的詞如onerror就會(huì)做轉(zhuǎn)換或者提示用戶不執(zhí)行,是不是沒有機(jī)會(huì)了呢? 當(dāng)然不是的,事件只是讓代碼運(yùn)行的一種方法而不是所有的,可以定義事件了那么也就可以實(shí)現(xiàn)自己弄出自己的屬性了,試試下面的: 呵呵,還是執(zhí)行了哦!在做關(guān)鍵字過濾之后有人發(fā)現(xiàn)是不是屬性之間分隔要用到空格,好,他們把空格堵死了(這樣認(rèn)為的人很多,呵呵)!將空格轉(zhuǎn)成 是個(gè)很普遍的方法?是么?甚至還可以讓別人無法關(guān)鍵字拆分,不要太自信了,試試下面的代碼看看如何: 這好象是利用了腳本里注釋會(huì)被當(dāng)作一個(gè)空白來表示造成的!那怎么辦呢?上面提到的好象一直都是在進(jìn)行被動(dòng)的攻擊防御,為什么不抓住他的本源出來呢?哪里出了問題哪里堵上! 上面的問題好象本質(zhì)上就是一個(gè)東西,那就是用戶超越了他所處的標(biāo)簽,也就是數(shù)據(jù)和代碼的混淆,對(duì)付這種混淆的辦法就是限制監(jiān)牢,讓用戶在一個(gè)安全的空間內(nèi)活動(dòng),這通過上面的分析大家也可能已經(jīng)知道,只要在過濾了<>這兩個(gè)人人都會(huì)去殺的字符之后就可以把用戶的輸入在輸出的時(shí)候放到""之間,現(xiàn)在的一般的程序都是這樣做的,譬如[img]http://www.loveshell.net[/img]將會(huì)轉(zhuǎn)化成這是個(gè)好的安全習(xí)慣,然后呢?就要讓用戶的輸入處在安全的領(lǐng)域里了,這可以通過過濾用戶輸入里""實(shí)現(xiàn),但是不要忘記了,這個(gè)標(biāo)簽本身也是不安全的,過濾掉空格和tab鍵就不用擔(dān)心關(guān)鍵字被拆分饒過了,然后就是用文章中提到的辦法過濾掉script關(guān)鍵字,最后就是防止用戶通過&#這樣的形式饒過檢查,轉(zhuǎn)換掉&吧! 在文章中開始提到的圖里可以看到,數(shù)據(jù)的轉(zhuǎn)換和過濾是可以在3個(gè)地方進(jìn)行轉(zhuǎn)換的,在接受數(shù)據(jù)的時(shí)候可以轉(zhuǎn)換下,在進(jìn)入數(shù)據(jù)庫的時(shí)候可以轉(zhuǎn)換下,在輸出數(shù)據(jù)的時(shí)候也可以轉(zhuǎn)換下,但是困惑在哪里呢? 不得不面對(duì)一個(gè)問題就是許多時(shí)候程序員舍不得為安全做出那么大的應(yīng)用上的犧牲,安全是要有代價(jià)的,譬如現(xiàn)在郵箱的就不愿意舍棄html標(biāo)簽,所以他們側(cè)重于XSS的IDS檢測的性質(zhì),只要發(fā)現(xiàn)不安全的東西就會(huì)轉(zhuǎn)化,但是攻擊是無法預(yù)知的,漂亮的東西總是脆弱的,有限制,肯定就有人會(huì)饒過,呵呵。本文沒什么技術(shù)含量,只是希望搞安全的腳本人員能更加的了解Xss,跨站,不是那么簡單滴! 上述的相關(guān)內(nèi)容就是對(duì)談跨站腳本攻擊與防御的描述,希望會(huì)給你帶來一些幫助在此方面。
本文出自:億恩科技【mszdt.com】 服務(wù)器租用/服務(wù)器托管中國五強(qiáng)!虛擬主機(jī)域名注冊頂級(jí)提供商!15年品質(zhì)保障!--億恩科技[ENKJ.COM] |