摘要：Dino 探究無(wú) Cookie 會(huì )話(huà)的優(yōu)缺點(diǎn)，并且討論為什么應該避免在會(huì )話(huà)狀態(tài)中存儲有價(jià)值的信息。
我們承認這一點(diǎn) — 我們對會(huì )話(huà)狀態(tài)這一概念是如此習以為常，以至于我們忘記了會(huì )話(huà)狀態(tài)是在 1997 年用 Active Server Pages （ASP） 引入的一個(gè)手段。會(huì )話(huà)狀態(tài)使開(kāi)發(fā)人員能夠在用戶(hù)與應用程序交互這段時(shí)間內持久保存有關(guān)該用戶(hù)的一塊信息。特定于用戶(hù)的信息通常會(huì )保留 20 分鐘長(cháng)的時(shí)段，而每當用戶(hù)返回該站點(diǎn)時(shí)，該時(shí)段都將重新開(kāi)始計時(shí)。
當用戶(hù)首次連接到站點(diǎn)時(shí)，將以?xún)却鎵K的形式創(chuàng )建一個(gè)全新的會(huì )話(huà)狀態(tài)以存放數據，同時(shí)，還會(huì )創(chuàng )建一個(gè) ID 以便將其與當前用戶(hù)唯一地聯(lián)系起來(lái)。當下一次發(fā)出請求時(shí)，該用戶(hù)將被要求提交該會(huì )話(huà) ID，以便檢索并正確地還原會(huì )話(huà)狀態(tài)。會(huì )話(huà) ID 是 ASP 和 ASP.NET 完全自主生成的字母數字字符串。用戶(hù)如何管理它并確保用每個(gè)后續請求來(lái)包裝它呢？
HTTP 協(xié)議的性質(zhì)是無(wú)狀態(tài)的，并且沒(méi)有任何人試圖更改這一事實(shí)。差不多二十年以前，當 Netscape Corporation 開(kāi)發(fā)它的第一個(gè)瀏覽器時(shí)，它“發(fā)明”了一種通過(guò) HTTP 工作的持久性機制。它將其稱(chēng)為 HTTP Cookie.有趣的是，計算機科學(xué)行話(huà)中的術(shù)語(yǔ)“Cookie”僅僅表示一塊由應用程序持有的不透明數據，它會(huì )影響用戶(hù)但永遠不會(huì )由用戶(hù)直接管理。
因此，Cookie 存儲會(huì )話(huà)的 ID，而瀏覽器則在 Web 服務(wù)器和本地用戶(hù)的計算機之間來(lái)回移動(dòng)它們的內容。當啟用了 Cookie 的瀏覽器收到響應數據包時(shí)，它將尋找附加的 Cookie，并將它們的內容存儲到本地 Windows 目錄中特定文件夾的某個(gè)文本文件中。Cookie 還包含有關(guān)該源站點(diǎn)的信息。接下來(lái)，當瀏覽器向該站點(diǎn)發(fā)送請求時(shí)，它會(huì )在 Cookie 文件夾中查找源自該域的 Cookie.如果找到，則該 Cookie 自動(dòng)附加到傳出的數據包中。該 Cookie 將命中服務(wù)器應用程序，并在此被檢測、提取和處理。
最終，Cookie 使 Web 站點(diǎn)更加易于導航，因為它們在用戶(hù)體驗之上提供了必然跨越多個(gè)請求的連續性錯覺(jué)。
Cookies 是不是一個(gè)問(wèn)題？
多年以來(lái)，Cookie 只被視為一種技術(shù)功能，并且在很大程度上被忽略了。幾年以前，針對 Web 安全的世界范圍的浪潮將人們的注意力集中于 Cookie 身上。Cookie 被斷定包含危險的程序，它們甚至能夠超出計算機的物理邊界來(lái)竊取有價(jià)值的信息。
不言而喻，Cookie 不是程序，因而無(wú)法自行收集任何信息 — 更不用說(shuō)有關(guān)用戶(hù)的任何個(gè)人信息。更加清楚的是，Cookie 是 Web 站點(diǎn)可以放置在用戶(hù)的計算機中以便以后檢索和重用的一段文本。所存儲的信息是由無(wú)害的名稱(chēng)-值對組成的。
要點(diǎn)在于，Cookie 不是標準 HTTP 規范的一部分，因此它們意味著(zhù)瀏覽器和 Web 站點(diǎn)之間的一種協(xié)作。并非所有瀏覽器都支持 Cookie，而且更為重要的是，并非所有用戶(hù)都在他們自己的瀏覽器副本中啟用 Cookie 支持。
在歷史上，有一些 Web 站點(diǎn)功能是如此緊密地與 Cookie 相聯(lián)系，以至于很難區分究竟是哪個(gè)功能最先出現。一方面，用 Cookie 對會(huì )話(huà)狀態(tài)管理和用戶(hù)身份驗證進(jìn)行編碼要容易得多。另一方面，如果您觀(guān)察一下站點(diǎn)與用于訪(fǎng)問(wèn)頁(yè)的瀏覽器有關(guān)的統計信息，那么您可能會(huì )驚訝地發(fā)現，相當一部分用戶(hù)在連接時(shí)禁用了 Cookie.這一點(diǎn)會(huì )對開(kāi)發(fā)人員有所啟示。
總而言之，Cookie 本身并不是問(wèn)題，但它們的使用無(wú)疑給予一些服務(wù)器代碼在客戶(hù)端計算機中存儲一段數據的能力。這預示著(zhù)一些潛在的安全風(fēng)險和一種不夠理想的總體狀況。（在某些情況以及某些國家/地區中，應用程序要求 Cookie 工作甚至是非法的。）
返回頁(yè)首進(jìn)入無(wú) Cookie 會(huì )話(huà)在 ASP.NET 中，無(wú)需使用 Cookie，就可以有選擇地建立必要的會(huì )話(huà)-用戶(hù)聯(lián)系。非常有趣的是，除了以下配置設置以外，您無(wú)需在 ASP.NET 應用程序中更改任何內容即可啟用無(wú) Cookie 會(huì )話(huà)。
<sessionState cookieless="true" />
ASP.NET 會(huì )話(huà)狀態(tài)的默認設置是在 machine.config 文件中定義的，并且可以在應用程序根文件夾中的 web.config 文件中重寫(xiě)。通過(guò)確保上述行出現在根 web.config 文件中，您可以啟用無(wú) Cookie 會(huì )話(huà)。就是這樣 — 簡(jiǎn)單而有效！
<sessionState>節點(diǎn)還可以用于配置會(huì )話(huà)狀態(tài)管理的其他方面，包括存儲介質(zhì)和連接字符串。但是，就 Cookie 而言，只需您將 cookieless 屬性設置為 true（默認設置為 false）。
請注意，會(huì )話(huà)設置是應用程序范圍的設置。換句話(huà)說(shuō)，您站點(diǎn)中的頁(yè)要么都將使用要么都將不使用 Cookie 來(lái)存儲會(huì )話(huà) ID.
當不使用 Cookie 時(shí)，ASP.NET 在哪里存儲會(huì )話(huà) ID 呢？在這種情況下，會(huì )話(huà) ID 插入到 URL 內的特定位置中。下圖顯示一個(gè)使用無(wú) Cookie 會(huì )話(huà)的真實(shí)站點(diǎn)的快照。
圖 1. 使用無(wú) Cookie 會(huì )話(huà)的 MapPoint
假設您請求了一個(gè)類(lèi)似于
[url]http://yourserver/folder/default.aspx[/url] 的頁(yè)。正如您可以從 MapPoint 快照中看到的那樣，資源名稱(chēng)前面的相鄰斜杠進(jìn)行了擴展，以便包含在內部填充了會(huì )話(huà) ID 的括號，如下所示。
[url]http://yourserver/folder/[/url]（session ID here）/default.aspx
會(huì )話(huà) ID 嵌入到 URL 中，并且無(wú)需在其他任何地方持久保存它。唔，并不完全是這樣。請考慮以下方案。
您訪(fǎng)問(wèn)了一個(gè)頁(yè)，并且被分配了一個(gè)會(huì )話(huà) ID.接下來(lái)，您清除了同一瀏覽器示例的地址欄，轉到另一個(gè)應用程序并且開(kāi)始工作。然后，您重新鍵入了上一個(gè)應用程序的 URL，并且（猜猜看）在您進(jìn)入的過(guò)程中檢索會(huì )話(huà)值。
如果您使用無(wú) Cookie 會(huì )話(huà)，那么當您第二次訪(fǎng)問(wèn)該應用程序時(shí)，您將被分配一個(gè)不同的會(huì )話(huà) ID，并且丟失以前的所有狀態(tài)。這是無(wú) Cookie 會(huì )話(huà)的一個(gè)典型的副作用。為了了解其原因，讓我們進(jìn)一步探討無(wú) Cookie 會(huì )話(huà)的實(shí)現。
返回頁(yè)首實(shí)現無(wú) Cookie 會(huì )話(huà)的實(shí)現得益于下列兩個(gè)運行時(shí)模塊的努力：一個(gè)名為 SessionStateModule 的標準會(huì )話(huà) HTTP 模塊，以及一個(gè)名為 aspnet_filter.dll 的可執行文件。后者是一小段 Win32 代碼，它充當 ISAPI 篩選器。HTTP 模塊和 ISAPI 篩選器實(shí)現了相同的思想，不同之處在于 HTTP 模塊由托管代碼組成，并且需要 ASP.NET 和 CLR 觸發(fā)才能工作。像 aspnet_filter.dll 這樣的傳統 ISAPI 篩選器是由 Internet 信息服務(wù) （IIS） 調用的。二者都截獲在請求處理過(guò)程中激發(fā)的 IIS 事件。
當新瀏覽器會(huì )話(huà)的第一個(gè)請求進(jìn)入時(shí)，會(huì )話(huà)狀態(tài)模塊讀取 web.config 文件中有關(guān) Cookie 支持的設置。如果 節的 cookieless 屬性設置為 true，則該模塊生成一個(gè)新的會(huì )話(huà) ID，通過(guò)將該會(huì )話(huà) ID 填充到資源名稱(chēng)前面的相鄰位置來(lái)分割 URL，并且使用 HTTP 302 命令將瀏覽器重定向到新的 URL.
當每個(gè)請求到達 IIS 入口時(shí)（遠遠早于它被移交給 ASP.NET），aspnet_filter.dll 獲得了一個(gè)查看它的機會(huì )。如果該 URL 將會(huì )話(huà) ID 嵌入到括號中，則會(huì )提取該會(huì )話(huà) ID 并將其復制到一個(gè)名為 AspFilterSessionId 的請求標頭中。然后，重寫(xiě)該 URL 以使其看起來(lái)像原來(lái)請求的資源，并且將其釋放。這一次，ASP.NET 會(huì )話(huà)狀態(tài)模塊從請求標頭中檢索會(huì )話(huà) ID，并且通過(guò)會(huì )話(huà)-狀態(tài)綁定繼續工作。
只要該 URL 包含可用來(lái)獲取會(huì )話(huà) ID 的信息，無(wú) Cookie 機制就可以很好地工作。正如您稍后將看到的那樣，這會(huì )造成一些使用限制。
讓我們研究一下無(wú) Cookie 會(huì )話(huà)的優(yōu)缺點(diǎn)。
返回頁(yè)首優(yōu)點(diǎn)在 ASP.NET 中，會(huì )話(huà)管理和表單身份驗證是唯一的兩個(gè)在后臺使用 Cookie 的系統功能。通過(guò)無(wú) Cookie 會(huì )話(huà)，您現在可以部署無(wú)論用戶(hù)的有關(guān) Cookie 的首選項如何都能正常工作的有狀態(tài)應用程序。然而，就 ASP.NET 1.x 而言，仍然需要使用 Cookie 來(lái)實(shí)現表單身份驗證。好消息是，在 ASP.NET 2.0 中，表單身份驗證可以選擇以無(wú) Cookie 方式工作。
另一個(gè)經(jīng)常提出的反對 Cookie 的理由是安全性。這是一個(gè)值得予以更多關(guān)注的要點(diǎn)。
Cookies 是無(wú)活動(dòng)能力的文本文件，因此，這些文件可能被攻擊者替換或損壞 — 只要他們獲得了對計算機的訪(fǎng)問(wèn)。真正的威脅并不在于 Cookie 可以在客戶(hù)端計算機上安裝什么，而是在于它們可以向目標站點(diǎn)上載什么。Cookie 不是程序，并且永遠不會(huì )像程序那樣運行；然而，您計算機上安裝的其他軟件可以使用對 Cookie 的瀏覽器內置支持來(lái)遠程從事破壞活動(dòng)。
此外，Cookie 要受到被盜竊的風(fēng)險。一旦失竊，包含有價(jià)值的和私人的信息的 Cookie 就可能將其內容泄露給惡意攻擊者，并且為其他類(lèi)型的 Web 攻擊提供便利?？傊?，通過(guò)使用 Cookie，您將自己暴露在本可以消除的風(fēng)險之中。這是真的嗎？
返回頁(yè)首缺點(diǎn)讓我們從另一個(gè)角度來(lái)考察安全性。您是否曾經(jīng)聽(tīng)說(shuō)過(guò)會(huì )話(huà)劫持？如果沒(méi)有，則請閱讀一下 TechNet Magazine 文章 Theft On The Web： Prevent Session Hijacking.簡(jiǎn)單說(shuō)來(lái)，當攻擊者獲得對特定用戶(hù)的會(huì )話(huà)狀態(tài)的訪(fǎng)問(wèn)時(shí)，將發(fā)生會(huì )話(huà)劫持。其實(shí)質(zhì)是，攻擊者竊取有效的會(huì )話(huà) ID，并且使用它侵入系統和窺探數據。獲取有效會(huì )話(huà) ID 的一種常見(jiàn)方式是竊取有效的會(huì )話(huà) Cookie.鑒于此，如果您認為無(wú) Cookie 會(huì )話(huà)保護了您應用程序的安全，那您就完全錯了。實(shí)際上，對于無(wú) Cookie 會(huì )話(huà)，會(huì )話(huà) ID 直接顯示在地址欄中！請嘗試下列操作：
1.連接到使用無(wú) Cookie 會(huì )話(huà)的 Web 站點(diǎn)（例如，MapPoint）并獲得一個(gè)映射。此時(shí)，該地址存儲在會(huì )話(huà)狀態(tài)中。
2.抓取 URL（直至頁(yè)名稱(chēng)）。不要包括查詢(xún)字符串，但請確保該 URL 包括會(huì )話(huà) ID.
3.將該 URL 保存到文件中，并將該文件復制/發(fā)送到另一臺計算機。
4.在第二臺計算機上打開(kāi)該文件，并將該 URL 粘貼到新瀏覽器實(shí)例中。
5.只要會(huì )話(huà)超時(shí)仍然有效，就會(huì )顯示同一個(gè)映射。
通過(guò)無(wú) Cookie 會(huì )話(huà)，可以比以往任何時(shí)候都更加容易地竊取會(huì )話(huà) ID.
從道德的觀(guān)點(diǎn)來(lái)看，竊取會(huì )話(huà)是應該受到譴責的操作，我相信大家會(huì )一致認同這一點(diǎn)。但它是否也是有害的？這取決于會(huì )話(huà)狀態(tài)中實(shí)際存儲的內容。竊取會(huì )話(huà) ID 本身并不會(huì )執行超出代碼控制范圍的操作。但是，它可能向未經(jīng)授權的用戶(hù)泄露私有數據，并且使一些壞家伙能夠執行未經(jīng)授權的操作。有關(guān)如何在 ASP.NET 應用程序中阻止會(huì )話(huà)劫持的提示，請閱讀 Wicked Code： Foiling Session Hijacking Attempts.（而且，它并不依賴(lài)于無(wú) Cookie 會(huì )話(huà)?。?br>
使用無(wú) Cookie 會(huì )話(huà)還會(huì )引起與鏈接有關(guān)的問(wèn)題。例如，您不能在 ASP.NET 頁(yè)中具有絕對的、完全限定的鏈接。如果您這樣做，那么源自該超鏈接的每個(gè)請求都將被視為新會(huì )話(huà)的一部分。無(wú) Cookie 會(huì )話(huà)要求您總是使用相對 URL，就像在 ASP.NET 回發(fā)中一樣。僅當您可以將會(huì )話(huà) ID 嵌入到 URL 中時(shí)，您才可以使用完全限定的 URL.但是，既然會(huì )話(huà) ID 是在運行時(shí)生成的，那么您如何才能做到這一點(diǎn)呢？
下面的代碼中斷了該會(huì )話(huà)：
<a runat="server" href="/test/page.aspx">Click</a>
要使用絕對 URL，可以借助于一個(gè)小技巧，即，使用 HttpResponse 類(lèi)上的 ApplyAppPathModifier 方法：
<a runat="server" href=<% =Response.ApplyAppPathModifier（"/test/page.aspx"）%> >Click</a>
ApplyAppPathModifier 方法采用一個(gè)表示 URL 的字符串作為參數，并且返回一個(gè)嵌入了會(huì )話(huà)信息的絕對 URL.例如，當您需要從 HTTP 頁(yè)重定向到 HTTPS 頁(yè)時(shí)，該技巧尤其有用。最后，請特別注意，每當您在同一個(gè)瀏覽器內部鍵入指向某個(gè)站點(diǎn)的路徑時(shí)，您都將丟失無(wú) Cookie 會(huì )話(huà)的狀態(tài)。還要請您注意的是，對于移動(dòng)應用程序，如果設備無(wú)法處理專(zhuān)門(mén)格式化的 URL，則無(wú) Cookie 會(huì )話(huà)可能會(huì )出現問(wèn)題。
返回頁(yè)首小結ASP.NET 中存在無(wú) Cookie 會(huì )話(huà)的主要原因是用戶(hù)（無(wú)論出于什么原因）可能在他們的瀏覽器中禁用了 Cookie.如果您的應用程序需要會(huì )話(huà)狀態(tài)，那么無(wú)論您是否喜歡，您都必須面對這種情況。無(wú) Cookie 會(huì )話(huà)將會(huì )話(huà) ID 嵌入到 URL 中，并且得到了雙重結果。一方面，它們?yōu)?nbsp;Web 站點(diǎn)提供了一種正確標識發(fā)出請求的用戶(hù)的方式。然而，另一方面，它們使會(huì )話(huà) ID 清楚地顯現在潛在的攻擊者面前，從而使攻擊者可以輕松地竊取它并以您的身份進(jìn)行操作。
要實(shí)現無(wú) Cookie 會(huì )話(huà)，您無(wú)需修改自己的編程模型 — 只需在 web.config 文件中進(jìn)行簡(jiǎn)單更改，就可以完成相關(guān)工作 — 但是，還要強烈建議您重構您的應用程序，以免在會(huì )話(huà)狀態(tài)中存儲有價(jià)值的信息。同時(shí)，將會(huì )話(huà)的生存期縮短至默認的 20 分鐘以?xún)扔兄诒Ｗo您的用戶(hù)和站點(diǎn)的安全。
關(guān)于作者
Dino Esposito 是 Wintellect 的講師和顧問(wèn)，他居住在意大利。他是 Programming Microsoft ASP.NET 以及更新的 Introducing Microsoft ASP.NET .0（兩者都由 Microsoft Press 出版）的作者，他的大多數時(shí)間都用來(lái)講授有關(guān) ASP.NET 和 ADO.NET 的課程以及在會(huì )議上發(fā)表講演。請在
[url]http://weblogs.asp.net/despos[/url] 瀏覽 Dino 的網(wǎng)絡(luò )日記。
