關於session會話劫持+cookie劫持的一些事--ASP.NET防護

Cookie 和身份驗證

Cookie 之因此存在，是由於它們能夠幫助開發人員達到必定目的。Cookie 充當了瀏覽器與服務器之間的一種持續性連接。特別是對於使用單次登陸的應用程序來講，失竊的 cookie 正是使得攻擊成爲可能的罪魁禍首。這對於一次單擊攻擊來講一點沒錯。

要使用 Cookie，無需以編程方式顯式建立和讀取它們。若是您使用會話狀態且實現表單身份驗證，您會隱式地使用 Cookie。固然，ASP.NET 支持無 cookie 的會話狀態，並且，ASP.NET 2.0 還引入了無 cookie 的表單身份驗證。所以，理論上您能夠在沒有 Cookie 的狀況下使用這些功能。我並非說您再也不必須這麼作了，但事實上這正是療法比疾病更糟的情形之一。無 Cookie 的會話，實際上將會話 ID 嵌入了 URL 中，這樣誰均可以看到。

與使用 Cookie 有關的潛在問題有哪些？Cookie 可能被盜（即被複制到黑客的計算機）和投毒（即被填充以惡意數據）。這些操做一般是即將發起的攻擊的前奏。若是被盜，Cookie 會「受權」外部用戶以您的名義鏈接到應用程序（並使用受保護的頁），這可能使黑客輕鬆地規避受權，並可以執行角色和安全設置所容許受害者執行的任何操做。所以，身份驗證 Cookie 一般被賦予相對較短的生存期，即 30 分鐘。（請注意，即便瀏覽器的會話完成所需的時間更長，cookie 仍會過時。）發生失竊時，黑客有 30 分鐘的時限來嘗試攻擊。

能夠將這個時限加長，以避免用戶不得不過於頻繁地登陸；但請注意，這麼作會將您本身置於危險境地。任何狀況下，都應避免使用 ASP.NET 持續性 Cookie。它將致使 cookie 具備幾乎永久的生存期，最長可達 50 年！下面的代碼片斷演示瞭如何輕鬆修改 cookie 的過時日期。

void OnLogin(object sender, EventArgs e) {
   // Check credentials
   if (ValidateUser(user, pswd)) {
      // Set the cookie's expiration date
      HttpCookie cookie;
      cookie = FormsAuthentication.GetAuthCookie(user, isPersistent);
      if (isPersistent) 
         cookie.Expires = DateTime.Now.AddDays(10);

      // Add the cookie to the response
      Response.Cookies.Add(cookie);

      // Redirect
      string targetUrl;
      targetUrl = FormsAuthentication.GetRedirectUrl(user, isPersistent);
   Response.Redirect(targetUrl);
   }
}

您能夠在本身的登陸表單中使用這些代碼來微調身份驗證 Cookie 的生存期。

返回頁首 

會話劫持

Cookie 還被用於檢索特定用戶的會話狀態。會話的 ID 被存儲到 cookie 中，該 cookie 與請求一塊兒來回傳送，存儲在瀏覽器的計算機上。一樣，若是失竊，會話 cookie 將可被用來使黑客進入系統並訪問別人的會話狀態。不用說，只要指定的會話處於活動狀態（一般不超 20 分鐘），這就有可能發生。經過冒充的會話狀態發起的攻擊稱爲會話劫持。有關會話劫持的詳細信息，請閱讀 Theft On The Web: Prevent Session Hijacking。

這種攻擊有多危險？很難講。這要取決於 Web 站點的功能，更爲重要的是，該站點的頁是如何設計的。例如，假定您可以得到別人的會話 cookie，並將它附加到對站點上某個頁的請求中。您加載該頁並逐步研究它的普通用戶界面。除了該頁使用另外一個用戶的會話狀態工做外，您沒法將任何代碼注入該頁，也沒法修改該頁中的任何內容。這自己並不太壞，可是若是該會話中的信息是敏感和關鍵性的，就有可能直接致使黑客成功實現利用。黑客沒法滲透到會話存儲的內容中，但他可使用其中存儲的信息，就像本身是合法進入的同樣。例如，假定有這樣一個電子商務應用程序，它的用戶在瀏覽站點時將物品添加到購物車中。

• 方案 1。 購物車的內容存儲在會話狀態中。可是，在結賬時，用戶被要求經過安全的 SSL 鏈接確認和輸入付款詳細信息。這種狀況下，經過接入其餘用戶的會話狀態，黑客僅能夠了解到一些有關受害者的購物喜愛的細節。在這種環境下劫持實際上並不會致使任何損害。受威脅的只是保密性。

• 方案 2。應用程序爲每位註冊用戶處理一份檔案，並將檔案保存在會話狀態中。糟糕的是，檔案中（可能）包括信用卡信息。爲何要將用戶檔案詳細信息存儲到會話中？可能應用程序的其中一個目標是，從根本上避免使用戶不得不重複鍵入本身的信用卡和銀行信息。所以，在結算時，應用程序會將用戶定位到一個具備預先填充的域的頁。而有失謹慎的是，這些域的其中一個是從會話狀態中獲取的信用卡號。如今您能夠猜到故事的結局了嗎？

應用程序的頁的設計，是防止會話劫持攻擊的關鍵所在。固然，還有兩點沒有理清。第一點是，如何防止 cookie 盜竊？第二點是，ASP.NET 能夠如何檢測和阻止劫持？

ASP.NET 會話 cookie 極其簡單，僅限於包含會話 ID 字符串自己。ASP.NET 運行庫從 cookie 中提取會話 ID，並將其與活動的會話進行比較。若是 ID 有效，ASP.NET 將鏈接到對應的會話並繼續。這種行爲極大地方便了已經偷到或者能夠猜出有效的會話 ID 的黑客。

XSS 和中間人 (man-in-the-middle) 攻擊以及對客戶端 PC 的強力訪問，都是獲取有效 cookie 的方法。爲了防止盜竊，您應當實現安全最佳實踐來防止 XSS 及其各變種得手。

而爲了防止會話 ID 猜想，您應當乾脆避免過高估計本身的技能。猜想會話 ID 意味着您知道如何預測有效的會話 ID 字符串。對於 ASP.NET 所使用的算法（15 個隨機數字，映射爲啓用 URL 的字符），隨機猜想到有效 ID 的機率接近於零。我想不到任何理由來用本身的會話 ID 生成器替換默認的會話 ID 生成器。許多狀況下，這麼作只會爲攻擊者提供方便。

會話劫持更爲糟糕的後果是一旦 cookie 被盜或者被猜出，ASP.NET 並無什麼辦法來檢測欺詐性的 cookie 使用。一樣，緣由是 ASP.NET 將本身限制爲檢查 ID 的有效性，以及 cookie 的來源地。

我在 Wintellect 的朋友 Jeff Prosise 爲 MSDN Magazine 寫了一篇很好的關於會話劫持的文章。他的結論並不使人安慰：幾乎不可能創建可以徹底抵禦依靠偷來的會話 ID Cookie 所發起的攻擊的防護工事。可是他開發的代碼爲進一步提高安全標準提供了很是明智的建議。Jeff 建立了一個 HTTP 模塊，該模塊爲會話 ID Cookie 監視傳入的請求和傳出的響應。該模塊將一條哈希代碼附加到會話 ID 以後，使攻擊者重用 cookie 更爲困難。您能夠在此處閱讀詳情。

VIA:詳情能夠看這兒

http://msdn.microsoft.com/zh-cn/library/ms972969.aspx 利用 ASP.NET 的內置功能抵禦 Web 攻擊
http://msdn.microsoft.com/zh-cn/magazine/cc300500(en-us).aspx 此處爲Jeff 建立了一個 HTTP 模塊，該模塊爲會話 ID Cookie 監視傳入的請求和傳出的響應。該模塊將一條哈希代碼附加到會話 ID 以後，使攻擊者重用 cookie 更爲困難。