基于Web會話管理漏洞檢測技術的研究

基于Web會話管理漏洞檢測技術的研究謝品章曾德生龐雙龍摘要：WEB會話管理涵蓋了從登錄到離開WEB應用程序的所有用戶控制，在提高應用的易用性和友好性方面發(fā)揮了重要作用，同時也增加了在無須提供正確憑證就能非法訪問WEB應用程序的風險。本文首先對WEB會話管理漏洞進行詳細分析，針對不同類型的WEB會話管理漏洞設計相對應的檢測方法，并在此基礎上提出WEB會話管理漏洞的防范措施。口關鍵詞：Web安全;會話管理;漏洞檢測；防范措施口0引言HTTP是一種無狀態(tài)協(xié)議。WEB服務器并不需要關聯(lián)客戶端請求就會做出響應。為了避免不斷地認證網(wǎng)站或者服務的每一個頁面。WEB應用程序通常采用某種會話管理機制將多個客戶端請求關聯(lián)起來組成一個“會話”，每個會話使用一個會話標識符或者Cookie來標識。通過在預先確定的時間范圍內存儲和驗證其會話憑證，實現(xiàn)對網(wǎng)站用戶交互方式的控制，會話管理涵蓋了從登錄到離開WEB應用程序的所有用戶控制，在提高應用的易用性和用戶的友好性方面發(fā)揮了重要作用，同時也增加了在無須提供正確憑證的情況下進入用戶賬號。非法訪問WEB應用程序的安全風險?？诖蠖鄶?shù)的WEB應用程序都是通過Cookie來關聯(lián)一個會話中的多個請求，RFC6265文檔對這一方法給出了詳細的說明。一個典型的應用例子就是在線購物車，整個用戶會話期間，WEB應用程序必須跟蹤用戶身份、個人信息以及選擇購買的產(chǎn)品、數(shù)量、單價、折扣等信息，這些信息存儲在Cookie中。WEB應用程序在HTTP應答中使用SET-COOKIE指令來創(chuàng)建相關的Cookie。當WEB應用程序指示客戶端瀏覽器使用某個Cookie后，瀏覽器就會在以后的每個請求中發(fā)送該Cookie。由于Cookie中的數(shù)據(jù)非常重要，如果會話管理存在漏洞，則可能導致用戶會話被劫持。利用當前活動會話非法進入用戶賬號，獲得訪問WEB應用程序的權限，在未經(jīng)授權的情況下實施非法操作。會話管理漏洞在2022年的OWASPTOP10中排名第三，而在2022年的OWASPTOP10中排名第二，說明會話管理攻擊事件在不斷增加，安全風險在上升。本文對WEB會話管理漏洞進行了詳細分析，然后提出WEB會話管理漏洞的檢測方法，最后針對該漏洞提出一些防范措施。1Web會話管理漏洞分析口會話管理漏洞主要是由于WEB應用程序的會話管理缺陷。Cookie屬性設置不當?shù)仍蛟斐傻?。例如：WEB應用程序或客戶端使用非加密信道傳送Cookie，攻擊者通過網(wǎng)絡監(jiān)聽，非法獲取Cookie，導致Cookie內容泄露或者被篡改?？赪EB應用程序的會話ID生成算法缺乏足夠的隨機性，攻擊者通過逆向分析，偽造一個有效的Cookie，實施未授權的非法訪問。口WEB應用程序在會話中使用了固定的會話ID，攻擊者通過會話劫持攻擊，假冒合法用戶繞過WEB應用程序的身份認證機制，非法進入該用戶賬戶。Cookie屬性設置不當，導致Cookie屬性設置漏洞，為攻擊者提高了攻擊Cookie的機會?？赪EB應用程序提供了不安全的請求方法，允許客戶端使用GET請求來傳送Cookie。與POST請求的方法相比，GET請求方法容易被操控,引發(fā)安全風險。會話管理的攻擊方法主要有Cookie篡改、Cookie溢出、會話劫持、跨站請求偽造等。COOKIE篡改攻擊口Cookie篡改攻擊一般采用如下步驟：口（1）Cookie收集。收集足夠數(shù)量的COOKIE樣本。口（2）Cookie逆向分析。分析會話ID生成算法?？冢?）Cookie偽造。當加密的Cookie被第三方獲取，并通過密文分析、暴力破解等方式獲取了相應的加密密編，第三方就可以偽造Cookie,獲得訪問WEB應用程序的權限，實施非法操作?？谇小昶垓_攻擊口由于在Cookie中存在用戶的敏感信息，所以開發(fā)者往往采用MD5對Cookie內容進行加密處理，即使攻擊者獲得了Cookie也很難破解其中的內容。但在某種情況下。攻擊者并不需要知道Cookie的明文內容，就可以采用Cookie欺騙的方式進行攻擊，將截獲的Cookie提交給服務器，從而假冒他人的身份登錄到網(wǎng)站。實施Cookie欺騙攻擊的前提條件是服務器的驗證程序存在漏洞，并且攻擊者能夠獲得被假冒者的Cookie信息。網(wǎng)站的驗證程序要驗證所有的非法登錄是非常困難的，并且編寫驗證程序的語言也可能存在漏洞。獲得他人的Cookie信息比較容易，下面是利用PHP腳本語言編寫的用于收集Cookie的程序代碼：口攻擊者把以上代碼放到論壇里，并附上讓人感興趣的話題。吸引大家點擊瀏覽，這樣就可以收集到大量的Cookie,攻擊者利用這些信息嘗試提交給服務器驗證。如果服務器驗證成功。就可以成功登錄到該網(wǎng)站。固定漏洞攻擊會話固定(SessionFixation)漏洞是指WEB應用程序沒有廢止當前會話ID，而是繼續(xù)使用同一個會話ID來認證其它用戶身份，導致會話劫持攻擊。攻擊者在WEB應用程序上創(chuàng)建一個新的會話并記錄相關的會話ID，當一個用戶使用同一個會話ID通過了WEB應用程序的身份認證后。攻擊者就有可能利用當前的活動會話進入該用戶賬戶，假冒該用戶非法訪問WEB應用程序?？贚重寫口WEB應用程序支持URL重寫，將用戶的會話ID直接放在URL中返回給用戶。如果用戶不小心泄露了該URL，則會導致會話ID泄露和被惡意利用。例如。一個網(wǎng)站的機票預訂程序支持URL重寫，將用戶的會話ID直接放在URL中返回給用戶，即：口該網(wǎng)站一個用戶通過認證，該用戶想通知朋友知道機票打折信息，于是將這個鏈接發(fā)給朋友，但該用戶并不知道已經(jīng)泄露了自己的會話ID。當該用戶的朋友點擊該鏈接時，將會使用該用戶的會話登錄這個網(wǎng)站，并可以惡意消費該用戶的信用卡。RF攻擊口跨站請求偽造(CSRF)是一種惡意利用網(wǎng)站的攻擊方式。從字面來看，跨站請求偽造與跨站腳本有些相似，然而二者是兩種不同的攻擊方式。XSS攻擊的對象是網(wǎng)站用戶。而CSRF攻擊的對象則是網(wǎng)站或者WEB應用程序。與XSS攻擊相比，CSRF攻擊更難防范，比XSS攻擊更具危險性?？贑SRF攻擊主要通過在用戶訪問的頁面包含惡意鏈接或者腳本的方式來實施。假設一個用戶使用GET請求來訪問一個網(wǎng)站，如果該用戶通過了網(wǎng)站W(wǎng)EB應用程序身份驗證，則下次提交的GET請求可以由如下的用戶來產(chǎn)生。（1）由實際使用WEB應用程序的用戶來產(chǎn)生?？冢?）由直接在瀏覽器輸入URL的用戶來產(chǎn)生?？冢?）由使用外部鏈接訪問網(wǎng)站的用戶來產(chǎn)生。由于WEB應用程序無法判斷由誰產(chǎn)生的GET請求，因此攻擊者可以利用這一特征來實施跨站請求偽造攻擊。攻擊者首先將一個執(zhí)行惡意操作的外部鏈接通過嵌入在一個電子郵件、圖片、或者網(wǎng)站等形式發(fā)布出來，引誘用戶點擊。如果一個通過了WEB身份驗證的用戶點擊了該鏈接。則瀏覽器就會向WEB應用程序發(fā)出包含該用戶Cookie的GET請求，由于該用戶的Cookie是有效的，因此WEB就會執(zhí)行該外部鏈接所規(guī)定的操作，導致跨站請求偽造攻擊。信息泄露跨站Cookie和超級Cookie的存在，可能導致用戶隱私信息泄露?？诳缌⒄綜ookie口由于Cookie的敏感性，使Cookie具有專屬性質，即A網(wǎng)站存在Cookie中的信息，B網(wǎng)站是沒有權限直接獲取的。然而，一些第三方廣告聯(lián)盟的代碼使用范圍非常廣，這就可能通過第三方廣告代碼形成跨站Cookie。例如，A網(wǎng)站和B網(wǎng)站都使用了同一家第三方廣告代碼，如果用戶首先在A網(wǎng)站搜索了一個“心臟病”關鍵詞，然后再去訪問B網(wǎng)站，第三方廣告代碼就可以從Cookie中獲取到用戶在A網(wǎng)站的搜索行為。在用戶瀏覽器上就會即刻出現(xiàn)治療心臟病的廣告信息，雖然實現(xiàn)了精準投放廣告，但是未經(jīng)用戶同意，對用戶的隱私構成了侵犯，造成用戶隱私信息泄露。超級Cookie口2Web會話管理漏洞檢測口會話管理漏洞主要是由于WEB應用程序的會言舌管理缺陷和Cookie屬性設置不當?shù)仍蛟斐傻?，通常采用動態(tài)檢測技術來檢測會話管理漏洞。檢測系統(tǒng)由兩部分組成：檢測主機和被檢測網(wǎng)站。兩者之間通過網(wǎng)絡連接起來，在檢測主機運行檢測程序，對被測網(wǎng)站進行測試：在被測網(wǎng)站上運行WEB服務器及應用程序，圖1是會話管理漏洞檢測系統(tǒng)模型。口動態(tài)檢測方法的一般步驟如下：Cookie獲取。根據(jù)測試項目，檢測主機采用GET或者POS了請求方法向被測網(wǎng)站發(fā)出HTTP請求包?？贑ookie分析。對被測網(wǎng)站返回的Cookie信息進行分析，確定是否存在相應的漏洞，給出檢測結果。COOKIE屬性設置漏洞檢測口分析被測網(wǎng)站返回的Cookie,對Cookie屬性設置進行逐項檢測，檢查是否存在Cookie屬性設置漏洞，即：口Seetlre屬性。檢查是否使用安全方式來傳送含有敏感信息或會話ID的Cookie。例如，當?shù)卿沇EB應用程序后，應用程序在Cookie中設置了會話ID。檢測是否設置了secure屬性，如果沒有設置，則存在Cookie信息泄露風險?？冢?）HTTPOnlY屬性。檢查是否設置了HTTPOnly屬性，如果沒有設置，則存在客戶端腳本利用該Cookie進行攻擊的風險。口（3）Domain屬性。檢查Domain設置情況，應該將其設置為需要接收該Cookie的服務器。例如，如果WEB應用程序存儲在app.myweb.con服務器上，則應該設置成“Domain二app.myweb.con”，而不能設置成“”，因為這種設置允許其它存在漏洞的服務器接收到Cookie?？冢?）Path屬性。檢查PATH屬性，如果PATH是設置在根目錄“/”下，則同樣允許其它存在漏洞的WEB應用程序接收該Cookie。例如，如果WEB應用程序存儲在“小丫@口口/”目錄，則Cookie路徑應設置為“path二/myapp/"，而不能設置為“path=/”或“path二/myapp"?？冢?）Expires屬性。檢查Expires屬性情況，如果該屬性設置成一個未來的截止日期，則需要確認該Cookie不包含任何敏感信息，否則有權讀取這個Cookie的用戶就有可能在截止日期前通過重復提交這個Cookie進入WEB應用程序?？跁捁潭┒礄z測會話固定漏洞檢測方法如下：（2）被測試網(wǎng)站響應如下信息：從網(wǎng)站服務器響應的信息可知，WEB應用程序為客戶建立了一個新的會話ID：JSESSIONID=CD7F8599FDD1BB09FDB2F9DFF3276EA2.jvm_0.口(3)利用POST方法向WEB服務器提交身份認證請求：口利用POST方法提交身份認證成功之后，從WEB響應的信息可知，WEB服務器并沒有重新產(chǎn)生新的會話ID，因此，存在會話固定漏洞。攻擊者利用這種漏洞就可以實施會話劫持攻擊。假冒該用戶進行各種非法操作。CSRF漏洞檢測口CSRF漏洞檢測方案如下：口(2)建立一個包含URL的HTTP請求的HTML頁面，并列出所有相關參數(shù)。如果使用GET請求方法，則可以直接完成，如果使用POST言青求方法，則需要通過JavaScfpt腳本來完成。口(3)確保有效的用戶能夠登陸到WEB應用程序?？?4)模擬用戶點擊到一個指向被測網(wǎng)站的鏈接。(5)檢查被測網(wǎng)站是否執(zhí)行了所指定的操作。請求方法弱點檢測由于GET請求方法容易被操控，存在安全弱點，因此在傳輸Cookie時，最好使用POST請求。雖然POST請求可以通過JavaScript腳本等手段來模擬，但是增加了攻擊的難度。請求方法弱點檢測是對使用POST請求方法傳送數(shù)據(jù)的WEB程序進行檢測，檢查WEB應用程序是否接受通過GET請求方法傳送的數(shù)據(jù)。口例如：一個WEB登陸產(chǎn)生如下的POST請求：口根據(jù)以上POST請求信息，經(jīng)過修改后采用GET方法提交請求，直接在瀏覽器地址欄輸入如下內容：如果能夠成功登陸，說明該WEB程序存在安全漏洞，容易被攻擊者利用。3Web會話管理漏洞防范口由于WEB應用程序的會話管理缺陷，以及Cookie屬性設置不當?shù)仍驅е庐a(chǎn)生會話漏洞。因此需要從正確使用會話管理功能，合理設置Cookie屬性等方面提高會話管理的安全性，防止攻擊者利用會話管理漏洞實施攻擊。可以采用如下防范措施：（1）Web應用程序和客戶端應避免使用非加密信道傳送Cookie，防止攻擊者通過網(wǎng)絡監(jiān)聽來獲取Cookie，導致Cookie內容泄露。口（2）應避免使用缺乏足夠隨機性的會話ID生成算法，防止攻擊者通過逆向分析來偽造Cookie?？冢?）避免使用固定的會話，防止攻擊者利用固定會話漏洞實施會話劫持攻擊。（4）正確設置Cookie屬性對Cookie進行保護，防止攻擊者利用Cookie屬性設置漏洞實施Cookie攻擊?？冢?）避免使用GET請求方法來傳送Cookie，防止攻擊者利用GET請求來實施攻擊。（6）避免使用持久性Cookie，盡量使用一次性Cookie，使Cookie只在當前活動會話中有效，并設置合理的Cookie有效期，瀏覽器應當及時刪除過期的Cookie。口（7）不要在URL錯誤信息或者日志中暴露會話ID，會話ID應當只出現(xiàn)在HTTPCookie頭信息中，不要以GET參數(shù)來傳遞會話ID?？冢?）通過在每個請求或者每個會話中使用強制隨機令牌或者參數(shù)，為敏感或者關鍵的操作提供標準的會話管理。（9）在身份認證時，如果連接從HTTP變?yōu)镠TTPS,則應當生成一個新的會話ID。在WEB應用程序中，推薦持續(xù)使用HTTPS而并非在HTTP和HTTPS