駭客攻防技術寶典——web實戰篇

標籤：應用程式   駭客   技術   使用者   認證   

第7章 攻擊會話管理

在絕大多數Web應用程式中，會話管理機制是一個基本的安全性群組件。它輔助應用程式從大量不同的請求中確認特定的使用者，並處理它收集的關於使用者與應用程式互動狀態的資料。會話管理在應用程式執行登入功能時顯得特別重要，因為它可在使用者通過請求提交他們的認證後，持續嚮應用程式保證任何特定使用者身份的真實性。

由於會話管理機制所發揮的關鍵作用，它們成為針對應用程式的惡意攻擊的主要目標。如果攻擊者能夠破壞應用程式的會話管理，他就能輕易避開其實施的驗證機制，不需要使用者認證即可偽裝成其他應用程式使用者。如果攻擊者以這種方式攻破一個系統管理使用者，那麼他就能夠控制整個應用程式。

和驗證機制一樣，通常會話管理功能中也存在著大量缺陷。在最容易遭受攻擊的情況下，攻擊者只需遞增應用程式向他們發布的令牌值，就可以轉換到另一名使用者的賬戶。在這種情況下，任何人都可以訪問應用程式的全部功能。另一方面，如果應用程式受到嚴密保護，攻擊者必須付出巨大的努力，破解幾層模糊處理並實施複雜的自動攻擊，才能發現應用程式中存在的細小漏洞。

本章將分析我們在現實世界的Web應用程式中發現的各種漏洞，詳細說明發現和利用這些漏洞所需執行的實際步驟。最後還將描述應用程式為防止這些攻擊所應採取的防禦措施。

錯誤觀點 "我們使用智慧卡進行驗證，沒有智慧卡攻擊者不可能攻破使用者會話。"

無論應用程式的驗證機制多麼安全穩定，使用者隨後提出的請求只有通過會話才能與驗證機制建立聯絡。如果應用程式的會話管理存在缺陷，攻擊者仍然能夠避開可靠的驗證機制，危及使用者的安全。

7.1　狀態要求

從本質上講，HTTP協議沒有狀態。它基於一種簡單的要求-回應模型，其中每對訊息代表一個獨立的事務。協議本身並無將某位使用者提出的各種請求聯絡起來的機制，並將它們與Web伺服器收到的所有其他請求區分開來。在Web發展的早期階段，並沒有必要建立這種機制：因為Web網站公布的是任何人都可以查閱的靜態HTML頁面。但如今，情況已經發生巨大變化。

絕大多數的Web"網站"實際為Web應用程式。它們允許使用者註冊與登入；協助使用者購買及銷售產品。它們能夠在使用者下次訪問時記住他的喜好。它們可根據使用者的單擊和輸入，通過動態建立的內容提供豐富、多媒體形式的使用體驗。為執行這些功能，應用程式就需要使用會話。

支援登入是會話在應用程式中的最主要用途。輸入使用者名稱和密碼後，可以用輸入的認證所屬的使用者身份使用應用程式，直到退出會話或由於會話處於非使用中而終止。使用者不希望在每個應用程式頁面重複輸入密碼。因此，一旦使用者通過驗證，應用程式就為他們建立一個會話，把所有屬於這個會話的請求當作該使用者提出的請求處理。

不具備登入功能的應用程式通常也需要使用會話。許多出售商品的網站並不要求顧客建立賬戶。但是，它們允許使用者瀏覽目錄、往購物籃中添加商品、提供交貨資訊並進行支付。在這種情形下，就沒有必要驗證使用者的身份：應用程式並不知道或關心絕大多數使用者的身份。但是，為了與他們進行交易，應用程式需要知道它收到的哪些請求來自同一名使用者。

執行會話的最簡單、也是最常見的方法就是向每名使用者發布一個唯一的會話令牌或標識符。使用者在隨後嚮應用程式提出的每一個請求中提交這個令牌，輔助應用程式在當前請求與前面提出的請求之間建立關聯。

在大多數情況下，應用程式使用HTTP cookie作為在伺服器與客戶間傳送這些會話令牌的傳輸機制。伺服器對新客戶的第一個響應中包含以下HTTP訊息頭：

650) this.width=650;" class="fit-image" border="0" src="http://images.51cto.com/files/uploadimg/20090723/1324410.jpg" width="475" height="31" />

客戶隨後提出的請求中包含如下訊息頭：

650) this.width=650;" class="fit-image" border="0" src="http://images.51cto.com/files/uploadimg/20090723/1324411.jpg" width="477" height="29" />

這種標準的會話管理機制非常容易受到各種類型的攻擊。當攻擊會話機制時，攻擊者的主要目標是以某種方式劫持一名合法使用者的會話，並因此偽裝成這名使用者。如果該使用者已經通過應用程式的驗證，攻擊者就可以訪問屬於這名使用者的私人資料，或者以他的身份執行未授權操作。如果該使用者未能通過驗證，攻擊者仍然能夠查看使用者在會話過程中提交的敏感資訊。

和前面樣本中運行ASP.NET的Microsoft IIS伺服器一樣，許多商業Web伺服器和Web應用程式平台執行它們自己的基於HTTP cookie的非定製會話管理解決方案。Web應用程式開發人員可使用它們提供的API將會話依賴功能與這種解決方案整合起來。

事實證明，一些非定製會話管理解決方案易於受到各種攻擊，導致使用者的會話被攻破（這一問題將在本章後面討論）。此外，一些開發人員發現，他們需要比內建解決方案所提供的控制更加全面的會話行為控制，或者希望避免基於cookie的解決方案中存在的一些固有漏洞。鑒於這些原因，安全性至關重要的應用程式（如電子銀行）通常使用預定義或並非基於cookie的會話管理機制。

會話管理機制中存在的漏洞主要分為兩類：

會話令牌產生過程中的薄弱環節；

在整個生命週期過程中處理會話令牌的薄弱環節。

我們將分別分析這些弱點，描述在現實世界的會話管理機制中常見的各種漏洞，以及發現和利用這些漏洞的實用技巧。最後將描述應用程式為防止這些攻擊所應採取的防禦措施。

滲透測試步驟

許多應用程式使用標準的cookie機制傳輸會話令牌，這樣可直接確定哪些資料包含令牌。然而，在其他情況下，可能需要進行一番探測才能找到令牌。

應用程式常常使用幾個不同的資料共同表示一個令牌，包括cookie、URL參數和隱藏表單欄位。其中一些資料可用於在不同的後端組件中維護工作階段狀態。如果沒有得到確認，不要想當然地認為某個特殊的參數就是會話令牌，或者只使用一個資料追蹤會話。

有時，一些資料似乎是應用程式的會話令牌，其實並非如此。具體來說，由Web伺服器或應用程式平台產生的標準會話cookie可能存在，但實際並不被應用程式使用。

使用者通過驗證後，觀察瀏覽器收到哪些新資料項目。應用程式通常會在使用者通過驗證後建立新的會話令牌。

為確定應用程式到底使用哪些資料項目作為令牌，找到一個確信依賴會話的頁面（如某一名使用者的"使用者資料"頁面），並向它提出幾個請求，系統性地刪除疑似被用作令牌的資料。如果刪除某個資料後，應用程式不再返回會話依賴頁面，即可確定該資料為會話令牌。Burp Repeater是執行這類測試的有效工具。

會話替代方案

並非每一種Web應用程式都使用會話，一些具備驗證機制、功能複雜的安全性至關重要的應用程式選擇使用其他技術管理狀態。有兩種會話替代方案。

HTTP驗證。使用各種基於HTTP驗證技術（基本、摘要、NTLM驗證等）的應用程式有時避免使用會話。在HTTP驗證中，客戶組件使用HTTP訊息頭通過瀏覽器直接與驗證機制互動，而不是通過包含在任何單獨頁面中的針對特殊應用程式的代碼與驗證機制互動。一旦使用者在瀏覽器對話方塊中輸入他的認證，瀏覽器將會在隨後向相同伺服器提出的每個請求中重複提交這些認證（或重複執行任何必要的握手）。這種做法等同於應用程式使用基於HTML表單的驗證，並在每個應用程式頁面插入一個登入表單，要求使用者通過他們執行的每一項操作重複驗證自己的身份。因此，如果使用基於HTTP的驗證，應用程式可以不必使用會話，而通過多個請求重複確定使用者身份。然而，基於網際網路的應用程式很少使用HTTP驗證。而且，由於發展完善的會話機制能夠提供其他用途非常廣泛的功能，實際上，幾乎所有的Web應用程式都採用這種機制。

無工作階段狀態機制。一些應用程式並不發布會話令牌系統管理使用者與應用程式的互動狀態，而是傳送所有必要資料（一般儲存在cookie或隱藏表單欄位中），由客戶管理狀態。實際上，這種機制以類似於ASP.NET ViewState的方式使用無工作階段狀態。為保證這種機制的安全，必須對通過客戶傳送的資料加以適當保護。這通常要求建立一個包含所有狀態資訊的二進位巨對象，並使用一種公認的演算法對這些資料進行加密或簽名。還必須在資料中包含足夠的上下文，以防止攻擊者將在應用程式某個位置收集到的狀態物件提交到另一個位置，造成某種意外行為。應用程式還必須在對象的資料中包含一個終止時間，執行與會話逾時相同的功能。我們已在第5章詳細介紹過通過客戶傳送資料的各種安全機制。

滲透測試步驟

如果應用程式使用HTTP驗證，它可能並不執行會話管理機制。使用前面描述的方法分析任何可能是令牌的資料的作用。

如果應用程式使用無工作階段狀態機制，通過客戶傳送所有必要資料進行狀態維護，有時我們可能很難檢測出這種機制，但如果發現下列跡象，即可確定應用程式使用這種機制。

向客戶發布的可能令牌的資料相當長（如100B或超過100B）。

應用程式對每個請求做出響應，發布一個新的資料。

資料似乎被加密（因此無法辨別其結構）或包含簽名（由有意義的結構和幾個位元組的無意義位元據組成）。

應用程式拒絕通過幾個請求提交相同資料的做法。

如果相關證據明確表明應用程式並未使用會話令牌管理狀態，那麼本章描述的任何攻擊都不可能達到其目的。因此，最好著手去尋找其他嚴重的漏洞，如存取控制不完善或代碼注入。

本文出自 “勇客部落格” 部落格，請務必保留此出處http://yongke.blog.51cto.com/8001532/1441393

駭客攻防技術寶典——web實戰篇