謝品章 曾德生 龐雙龍



摘要:WEB會話管理涵蓋了從登錄到離開WEB應用程序的所有用戶控制,在提高應用的易用性和友好性方面發揮了重要作用,同時也增加了在無須提供正確憑證就能非法訪問WEB應用程序的風險。本文首先對WEB會話管理漏洞進行詳細分析,針對不同類型的WEB會話管理漏洞設計相對應的檢測方法,并在此基礎上提出WEB會話管理漏洞的防范措施。
關鍵詞:Web安全;會話管理;漏洞檢測;防范措施
0引言
HTTP是一種無狀態協議。WEB服務器并不需要關聯客戶端請求就會做出響應。為了避免不斷地認證網站或者服務的每一個頁面。WEB應用程序通常采用某種會話管理機制將多個客戶端請求關聯起來組成一個“會話”,每個會話使用一個會話標識符或者Cookie來標識。通過在預先確定的時間范圍內存儲和驗證其會話憑證,實現對網站用戶交互方式的控制,會話管理涵蓋了從登錄到離開WEB應用程序的所有用戶控制,在提高應用的易用性和用戶的友好性方面發揮了重要作用,同時也增加了在無須提供正確憑證的情況下進入用戶賬號。非法訪問WEB應用程序的安全風險。
大多數的WEB應用程序都是通過Cookie來關聯一個會話中的多個請求,RFC6265文檔對這一方法給出了詳細的說明。一個典型的應用例子就是在線購物車,整個用戶會話期間,WEB應用程序必須跟蹤用戶身份、個人信息以及選擇購買的產品、數量、單價、折扣等信息,這些信息存儲在Cookie中。WEB應用程序在HTTP應答中使用SET-COOKIE指令來創建相關的Cookie。當WEB應用程序指示客戶端瀏覽器使用某個Cookie后,瀏覽器就會在以后的每個請求中發送該Cookie。由于Cookie中的數據非常重要,如果會話管理存在漏洞,則可能導致用戶會話被劫持。利用當前活動會話非法進入用戶賬號,獲得訪問WEB應用程序的權限,在未經授權的情況下實施非法操作。
會話管理漏洞在2010年的OWASP TOP 10中排名第三,而在2013年的OWASP TOP 10中排名第二,說明會話管理攻擊事件在不斷增加,安全風險在上升。本文對WEB會話管理漏洞進行了詳細分析,然后提出WEB會話管理漏洞的檢測方法,最后針對該漏洞提出一些防范措施。
1 Web會話管理漏洞分析
會話管理漏洞主要是由于WEB應用程序的會話管理缺陷。Cookie屬性設置不當等原因造成的。例如:
(1)WEB應用程序或客戶端使用非加密信道傳送Cookie,攻擊者通過網絡監聽,非法獲取Cookie,導致Cookie內容泄露或者被篡改。
(2)WEB應用程序的會話ID生成算法缺乏足夠的隨機性,攻擊者通過逆向分析,偽造一個有效的Cookie,實施未授權的非法訪問。
(3)WEB應用程序在會話中使用了固定的會話ID,攻擊者通過會話劫持攻擊,假冒合法用戶繞過WEB應用程序的身份認證機制,非法進入該用戶賬戶。
(4)Cookie屬性設置不當,導致Cookie屬性設置漏洞,為攻擊者提高了攻擊Cookie的機會。
(5)WEB應用程序提供了不安全的請求方法,允許客戶端使用GET請求來傳送Cookie。與POST請求的方法相比,GET請求方法容易被操控,引發安全風險。
會話管理的攻擊方法主要有Cookie篡改、Cookie溢出、會話劫持、跨站請求偽造等。
1.1 COOKIE篡改攻擊
Cookie篡改攻擊一般采用如下步驟:
(1)Cookie收集。收集足夠數量的COOKIE樣本。
(2)Cookie逆向分析。分析會話ID生成算法。
(3)Cookie偽造。當加密的Cookie被第三方獲取,并通過密文分析、暴力破解等方式獲取了相應的加密密鑰,第三方就可以偽造Cookie,獲得訪問WEB應用程序的權限,實施非法操作。
攻擊者一旦從Cookie中得到足夠多的用戶信息,就能夠對Cookie內容進行篡改。例如:移動電信運營商用戶通過互聯網發送彩信消息,在身份認證過程結束后,在Cookie中包含了發件人的電話號碼,這個Cookie是服務收費程序用來識別用戶的。如果攻擊者得到電話號碼以明文方式存儲的,并且沒有任何保護,則可以將Cookie中的電話號碼改成攻擊者的電話號碼,那么被攻擊者將會為攻擊者支付彩信的費用。
1.2COOKIE欺騙攻擊
由于在Cookie中存在用戶的敏感信息,所以開發者往往采用MD5對Cookie內容進行加密處理,即使攻擊者獲得了Cookie也很難破解其中的內容。但在某種情況下。攻擊者并不需要知道Cookie的明文內容,就可以采用Cookie欺騙的方式進行攻擊,將截獲的Cookie提交給服務器,從而假冒他人的身份登錄到網站。
實施Cookie欺騙攻擊的前提條件是服務器的驗證程序存在漏洞,并且攻擊者能夠獲得被假冒者的Cookie信息。網站的驗證程序要驗證所有的非法登錄是非常困難的,并且編寫驗證程序的語言也可能存在漏洞。獲得他人的Cookie信息比較容易,下面是利用PHP腳本語言編寫的用于收集Cookie的程序代碼:
攻擊者把以上代碼放到論壇里,并附上讓人感興趣的話題。吸引大家點擊瀏覽,這樣就可以收集到大量的Cookie,攻擊者利用這些信息嘗試提交給服務器驗證。如果服務器驗證成功。就可以成功登錄到該網站。
1.3 會話固定漏洞攻擊
會話固定(Session Fixation)漏洞是指WEB應用程序沒有廢止當前會話ID,而是繼續使用同一個會話ID來認證其它用戶身份,導致會話劫持攻擊。攻擊者在WEB應用程序上創建一個新的會話并記錄相關的會話ID,當一個用戶使用同一個會話ID通過了WEB應用程序的身份認證后。攻擊者就有可能利用當前的活動會話進入該用戶賬戶,假冒該用戶非法訪問WEB應用程序。
1.4 URL重寫
WEB應用程序支持URL重寫,將用戶的會話ID直接放在URL中返回給用戶。如果用戶不小心泄露了該URL,則會導致會話ID泄露和被惡意利用。
例如。一個網站的機票預訂程序支持URL重寫,將用戶的會話ID直接放在URL中返回給用戶,即:
http://www.xxxx.com/ex:Isessionid:2POc2JDXMDOOSQXIEMDPSSDNXSHCJKJVMSL?dest=huawei
該網站一個用戶通過認證,該用戶想通知朋友知道機票打折信息,于是將這個鏈接發給朋友,但該用戶并不知道已經泄露了自己的會話ID。當該用戶的朋友點擊該鏈接時,將會使用該用戶的會話登錄這個網站,并可以惡意消費該用戶的信用卡。
1.5 CSRF攻擊
跨站請求偽造(CSRF)是一種惡意利用網站的攻擊方式。從字面來看,跨站請求偽造與跨站腳本有些相似,然而二者是兩種不同的攻擊方式。XSS攻擊的對象是網站用戶。而CSRF攻擊的對象則是網站或者WEB應用程序。與XSS攻擊相比,CSRF攻擊更難防范,比XSS攻擊更具危險性。
CSRF攻擊主要通過在用戶訪問的頁面包含惡意鏈接或者腳本的方式來實施。假設一個用戶使用GET請求來訪問一個網站,如果該用戶通過了網站WEB應用程序身份驗證,則下次提交的GET請求可以由如下的用戶來產生。
(1)由實際使用WEB應用程序的用戶來產生。
(2)由直接在瀏覽器輸入URL的用戶來產生。
(3)由使用外部鏈接訪問網站的用戶來產生。
由于WEB應用程序無法判斷由誰產生的GET請求,因此攻擊者可以利用這一特征來實施跨站請求偽造攻擊。攻擊者首先將一個執行惡意操作的外部鏈接通過嵌入在一個電子郵件、圖片、或者網站等形式發布出來,引誘用戶點擊。如果一個通過了WEB身份驗證的用戶點擊了該鏈接。則瀏覽器就會向WEB應用程序發出包含該用戶Cookie的GET請求,由于該用戶的Cookie是有效的,因此WEB就會執行該外部鏈接所規定的操作,導致跨站請求偽造攻擊。
1.6 隱私信息泄露
跨站Cookie和超級Cookie的存在,可能導致用戶隱私信息泄露。
1.6.1 跨站Cookie
由于Cookie的敏感性,使Cookie具有專屬性質,即A網站存在Cookie中的信息,B網站是沒有權限直接獲取的。然而,一些第三方廣告聯盟的代碼使用范圍非常廣,這就可能通過第三方廣告代碼形成跨站Cookie。例如,A網站和B網站都使用了同一家第三方廣告代碼,如果用戶首先在A網站搜索了一個“心臟病”關鍵詞,然后再去訪問B網站,第三方廣告代碼就可以從Cookie中獲取到用戶在A網站的搜索行為。在用戶瀏覽器上就會即刻出現治療心臟病的廣告信息,雖然實現了精準投放廣告,但是未經用戶同意,對用戶的隱私構成了侵犯,造成用戶隱私信息泄露。
1.6.2 超級Cookie
超級Cookie存在于某些瀏覽器中,如Mozilla、谷歌Chrome、蘋果IOS瀏覽器等,能夠在瀏覽器隱私模式下執行普通會話,導致瀏覽器隱私模式的失效。IE瀏覽器不存在這種問題,因為IE瀏覽器內部并沒有提供對特殊操作的記憶功能。例如,用戶在瀏覽器地址欄使用前綴https://,對某個網站的通信進行加密保護。一些瀏覽器對此進行記憶,保存一個“超級Cookie”,當用戶下次訪問該網站時,瀏覽器會自動進入HTTPS通道,即使用戶在瀏覽器設置了隱私模式,禁用了Cookie,但是這個超級Cookie依然存在。
2 Web會話管理漏洞檢測
會話管理漏洞主要是由于WEB應用程序的會話管理缺陷和Cookie屬性設置不當等原因造成的,通常采用動態檢測技術來檢測會話管理漏洞。檢測系統由兩部分組成:檢測主機和被檢測網站。兩者之間通過網絡連接起來,在檢測主機運行檢測程序,對被測網站進行測試:在被測網站上運行WEB服務器及應用程序,圖1是會話管理漏洞檢測系統模型。
動態檢測方法的一般步驟如下:
(1)Cookie獲取。根據測試項目,檢測主機采用GET或者POS了請求方法向被測網站發出HTTP請求包。
(2)Cookie分析。對被測網站返回的Cookie信息進行分析,確定是否存在相應的漏洞,給出檢測結果。
2.1 COOKIE屬性設置漏洞檢測
分析被測網站返回的Cookie,對Cookie屬性設置進行逐項檢測,檢查是否存在Cookie屬性設置漏洞,即:
(1)Seetlre屬性。檢查是否使用安全方式來傳送含有敏感信息或會話ID的Cookie。例如,當登錄WEB應用程序后,應用程序在Cookie中設置了會話ID。檢測是否設置了secure屬性,如果沒有設置,則存在Cookie信息泄露風險。
(2)HTTP OnlY屬性。檢查是否設置了HTTPOnly屬性,如果沒有設置,則存在客戶端腳本利用該Cookie進行攻擊的風險。
(3)Domain屬性。檢查Domain設置情況,應該將其設置為需要接收該Cookie的服務器。例如,如果WEB應用程序存儲在app.myweb.con服務器上,則應該設置成“Domain=app.myweb.con”,而不能設置成“”,因為這種設置允許其它存在漏洞的服務器接收到Cookie。
(4)Path屬性。檢查PATH屬性,如果PATH是設置在根目錄“/”下,則同樣允許其它存在漏洞的WEB應用程序接收該Cookie。例如,如果WEB應用程序存儲在“/myapp/”目錄,則Cookie路徑應設置為“path=/myapp/”,而不能設置為“path=/”或“path=/myapp”。
(5)Expires屬性。檢查Expires屬性情況,如果該屬性設置成一個未來的截止日期,則需要確認該Cookie不包含任何敏感信息,否則有權讀取這個Cookie的用戶就有可能在截止日期前通過重復提交這個Cookie進入WEB應用程序。
2.2 會話固定漏洞檢測
會話固定漏洞檢測方法如下:
(1)向被測試網站(例如:www.xxxx.con)發送get請求:
GET www.xxxx.com
(2)被測試網站響應如下信息:
從網站服務器響應的信息可知,WEB應用程序為客戶建立了一個新的會話ID:JSESSIONID=CD7F8599FDD1BB09FDB2F9DFF3276EA2.jvm_0.
(3)利用POST方法向WEB服務器提交身份認證請求:
利用POST方法提交身份認證成功之后,從WEB響應的信息可知,WEB服務器并沒有重新產生新的會話ID,因此,存在會話固定漏洞。攻擊者利用這種漏洞就可以實施會話劫持攻擊。假冒該用戶進行各種非法操作。
2.3 CSRF漏洞檢測
CSRF漏洞檢測方案如下:
(1)使用U代表被測URL,例如,U=http=www.mytest.com/action.
(2)建立一個包含URL的HTTP請求的HTML頁面,并列出所有相關參數。如果使用GET請求方法,則可以直接完成,如果使用POST請求方法,則需要通過JavaScfpt腳本來完成。
(3)確保有效的用戶能夠登陸到WEB應用程序。
(4)模擬用戶點擊到一個指向被測網站的鏈接。
(5)檢查被測網站是否執行了所指定的操作。
2.4 請求方法弱點檢測
由于GET請求方法容易被操控,存在安全弱點,因此在傳輸Cookie時,最好使用POST請求。雖然POST請求可以通過JavaScript腳本等手段來模擬,但是增加了攻擊的難度。
請求方法弱點檢測是對使用POST請求方法傳送數據的WEB程序進行檢測,檢查WEB應用程序是否接受通過GET請求方法傳送的數據。
例如:一個WEB登陸產生如下的POST請求:
根據以上POST請求信息,經過修改后采用GET方法提交請求,直接在瀏覽器地址欄輸入如下內容:
http://www.xxxx.com/denglu.php?name=xiaoli&password=xiel23456&SessionID=987654321
如果能夠成功登陸,說明該WEB程序存在安全漏洞,容易被攻擊者利用。
3 Web會話管理漏洞防范
由于WEB應用程序的會話管理缺陷,以及Cookie屬性設置不當等原因導致產生會話漏洞。因此需要從正確使用會話管理功能,合理設置Cookie屬性等方面提高會話管理的安全性,防止攻擊者利用會話管理漏洞實施攻擊。可以采用如下防范措施:
(1)Web應用程序和客戶端應避免使用非加密信道傳送Cookie,防止攻擊者通過網絡監聽來獲取Cookie,導致Cookie內容泄露。
(2)應避免使用缺乏足夠隨機性的會話ID生成算法,防止攻擊者通過逆向分析來偽造Cookie。
(3)避免使用固定的會話,防止攻擊者利用固定會話漏洞實施會話劫持攻擊。
(4)正確設置Cookie屬性對Cookie進行保護,防止攻擊者利用Cookie屬性設置漏洞實施Cookie攻擊。
(5)避免使用GET請求方法來傳送Cookie,防止攻擊者利用GET請求來實施攻擊。
(6)避免使用持久性Cookie,盡量使用一次性Cookie,使Cookie只在當前活動會話中有效,并設置合理的Cookie有效期,瀏覽器應當及時刪除過期的Cookie。
(7)不要在URL錯誤信息或者日志中暴露會話ID,會話ID應當只出現在HTTP Cookie頭信息中,不要以GET參數來傳遞會話ID。
(8)通過在每個請求或者每個會話中使用強制隨機令牌或者參數,為敏感或者關鍵的操作提供標準的會話管理。
(9)在身份認證時,如果連接從HTTP變為HTTPS,則應當生成一個新的會話ID。在WEB應用程序中,推薦持續使用HTTPS而并非在HTTP和HTTPS之間切換使用。
(10)禁止連續的登錄并強制執行周期性的會話終止。即使是活動的會話,特別是對于支持網絡連接或者連接到關鍵系統的WEB應用程序。終止時間應當根據業務需求做適當的調整。
(11)將Cookie設置為HTTP only屬性。除非在WEB應用程序中明確要求客戶端腳本程序讀取或者設置Cookie的值。
4 結束語
本文介紹了WEB會話在實際應用中的作用。詳細分析了會話管理漏洞產生的原因以及利用會話漏洞實施攻擊的各種手段:提出了由于不同原因造成的會話漏洞的檢測方法:最后給出一些防范WEB會話管理漏洞的建議。通過以上的分析與研究,為下一步對WEB安全的學習打下基礎,指明方向。