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

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