ASP.NET中無Cookie會話的優點與缺點
無Cookie會話的優點
在 ASP.NET 中，會話管理和表單身份驗證是唯一的兩個在后臺使用 Cookie 的系統功能。通過無 Cookie 會話，您現在可以部署無論用戶的有關 Cookie 的首選項如何都能正常工作的有狀態應用程序。然而，就 ASP.NET 1.x 而言，仍然需要使用 Cookie 來實現表單身份驗證。好消息是，在 ASP.NET 2.0 中，表單身份驗證可以選擇以無 Cookie 方式工作。
另一個經常提出的反對 Cookie 的理由是安全性。這是一個值得予以更多關注的要點。
Cookies 是無活動能力的文本文件，因此，這些文件可能被攻擊者替換或損壞 — 只要他們獲得了對計算機的訪問。真正的威脅并不在于 Cookie 可以在客戶端計算機上安裝什么，而是在于它們可以向目標站點上載什么。Cookie 不是程序，并且永遠不會像程序那樣運行；然而，您計算機上安裝的其他軟件可以使用對 Cookie 的瀏覽器內置支持來遠程從事破壞活動。
此外，Cookie 要受到被盜竊的風險。一旦失竊，包含有價值的和私人的信息的 Cookie 就可能將其內容泄露給惡意攻擊者，并且為其他類型的 Web 攻擊提供便利。總之，通過使用 Cookie，您將自己暴露在本可以消除的風險之中。這是真的嗎？
無Cookie會話的缺點
讓我們從另一個角度來考察安全性。您是否曾經聽說過會話劫持？如果沒有，則請閱讀一下 TechNet Magazine 文章 Theft On The Web: Prevent Session Hijacking。簡單說來，當攻擊者獲得對特定用戶的會話狀態的訪問時，將發生會話劫持。其實質是，攻擊者竊取有效的會話 ID，并且使用它侵入系統和窺探數據。獲取有效會話 ID 的一種常見方式是竊取有效的會話 Cookie。鑒于此，如果您認為無 Cookie 會話保護了您應用程序的安全，那您就完全錯了。實際上，對于無 Cookie 會話，會話 ID 直接顯示在地址欄中！請嘗試下列操作：
連接到使用無Cookie會話的 Web 站點（例如，MapPoint）并獲得一個映射。此時，該地址存儲在會話狀態中。
◆抓取 URL（直至頁名稱）。不要包括查詢字符串，但請確保該 URL 包括會話 ID。
◆將該 URL 保存到文件中，并將該文件復制/發送到另一臺計算機。
◆在第二臺計算機上打開該文件，并將該 URL 粘貼到新瀏覽器實例中。
◆只要會話超時仍然有效，就會顯示同一個映射。
◆通過無Cookie會話，可以比以往任何時候都更加容易地竊取會話 ID。
從道德的觀點來看，竊取會話是應該受到譴責的操作，我相信大家會一致認同這一點。但它是否也是有害的？這取決于會話狀態中實際存儲的內容。竊取會話 ID 本身并不會執行超出代碼控制范圍的操作。但是，它可能向未經授權的用戶泄露私有數據，并且使一些壞家伙能夠執行未經授權的操作。有關如何在 ASP.NET 應用程序中阻止會話劫持的提示，請閱讀 Wicked Code: Foiling Session Hijacking Attempts。（而且，它并不依賴于無 Cookie 會話！）
使用無Cookie會話還會引起與鏈接有關的問題。例如，您不能在 ASP.NET 頁中具有絕對的、完全限定的鏈接。如果您這樣做，那么源自該超鏈接的每個請求都將被視為新會話的一部分。無 Cookie 會話要求您總是使用相對 URL，就像在 ASP.NET 回發中一樣。僅當您可以將會話 ID 嵌入到 URL 中時，您才可以使用完全限定的 URL。但是，既然會話 ID 是在運行時生成的，那么您如何才能做到這一點呢？
下面的代碼中斷了該會話：
- < a runat="server" href="/test/page.aspx">Click< /a>
要使用絕對 URL，可以借助于一個小技巧，即，使用 HttpResponse 類上的 ApplyAppPathModifier 方法：
- < a runat="server" href=< % =Response.ApplyAppPathModifier("/test/page.aspx")%> >Click< /a>
ApplyAppPathModifier 方法采用一個表示 URL 的字符串作為參數，并且返回一個嵌入了會話信息的絕對 URL。例如，當您需要從 HTTP 頁重定向到 HTTPS 頁時，該技巧尤其有用。最后，請特別注意，每當您在同一個瀏覽器內部鍵入指向某個站點的路徑時，您都將丟失無 Cookie 會話的狀態。還要請您注意的是，對于移動應用程序，如果設備無法處理專門格式化的 URL，則無 Cookie 會話可能會出現問題。
【編輯推薦】
