【電腦網路學習筆記】什麼是cookie以及cookie劫持的基本概念

標籤：style   http   color   io   os   使用   ar   strong   for   

謹為今後學習參考的筆記。內容來自互連網。

Cookie的基本概念：

Cookie是由伺服器端產生，發送給User-Agent（一般是瀏覽器），瀏覽器會將Cookie的key/value儲存到某個目錄下的文字檔內，下次請求同一網站時就發送該Cookie給伺服器（前提是瀏覽器設定為啟用cookie）。Cookie名稱和值可以由伺服器端開發自己定義，對於JSP而言也可以直接寫入jsessionid，這樣伺服器可以知道該使用者是否合法使用者以及是否需要重新登入等，伺服器可以設定或讀取Cookies中包含資訊，藉此維護使用者跟伺服器會話中的狀態。

 

什麼是Cookies（“小甜餅”）呢？　　簡單來說，Cookies就是伺服器暫時存放在你的電腦裡的資料（.txt格式的文字檔），好讓伺服器用來辨認你的電腦。當你在瀏覽網站的時候，Web伺服器會先送一小小資料放在你的電腦上，Cookies 會幫你在網站上所打的文字或是一些選擇都記錄下來。當下次你再訪問同一個網站，Web伺服器會先看看有沒有它上次留下的Cookies資料，有的話，就會依據Cookie裡的內容來判斷使用者，送出特定的網頁內容給你。

 

cookies有什麼作用呢？　　現在上許多網站都用新使用者註冊這一項，有時註冊了一下，等到下次再訪問該網站時，會自動識別到你，並且向你問好，是不是覺得很親切？當然這種作用只是表面現象，更重要的是，網站可以利用cookies跟蹤統計使用者訪問該網站的習慣，比如什麼時間訪問，訪問了哪些頁面，在每個網頁的停留時間等。利用這些資訊，一方面是可以為使用者提供個人化的服務，另一方面，也可以作為瞭解所有使用者行為的工具，對於網站經營策略的改進有一定參考價值。例如，你在某家航空公司網站查閱航班時刻表，該網站可能就建立了包含你旅行計劃的Cookies，也可能它只記錄了你在該網站上曾經訪問過的Web頁，在你下次訪問時，網站根據你的情況對顯示的內容進行調整，將你所感興趣的內容放在前列。這是進階的Cookie應用。目前Cookies 最廣泛的是記錄使用者登入資訊，這樣下次訪問時可以不需要輸入自己的使用者名稱、密碼了——當然這種方便也存在使用者資訊泄密的問題，尤其在多個使用者共用一台電腦時很容易出現這樣的問題。

 

另外，有人認為網站利用cookies可能存在侵犯使用者隱私的問題，但由於大多使用者對此瞭解不多，而且這種對使用者個人資訊的利用多數作為統計資料之用，不一定造成使用者的直接損失，因此現在對於cookies與使用者隱私權的問題並沒有相關法律約束，很多網站仍然在利用cookie跟蹤使用者行為，有些程式要求使用者必須開啟cookie才能正常應用。IE瀏覽器使用者可以通過“隱私”選項中的隱私權設定的高低來決定是否允許網站利用cookie跟蹤自己的資訊，從全部限制到全部允許，或者限制部分網站，也可以通過手動方式對具體的網站設定允許或者禁止使用cookies進行編輯。IE瀏覽器的預設設定是 “中級”－對部分網站利用cookie有限制。個人電腦的cookies設定（對IE瀏覽器而言）可通過菜單“工具－Internet選項－隱私”來查看和修改。  針對Cookie的指令碼攻擊：  儘管cookie沒有病毒那麼危險，但它仍包含了一些敏感資訊：使用者名稱，電腦名稱，使用的瀏覽器和曾經訪問的網站。使用者不希望這些內容泄漏出去，尤其是當其中還包含有私人資訊的時候。  這並非危言聳聽，一種名為跨網站指令碼攻擊（Cross site scripting）可以達到此目的。通常跨網站指令碼攻擊往往利用網站漏洞在網站頁面中植入指令碼代碼或網站頁面引用第三方法指令碼代碼，均存在跨網站指令碼攻擊的可能，在受到跨網站指令碼攻擊時，指令碼指令將會讀取當前網站的所有 Cookie 內容（已不存在 Cookie 範圍限制），然後通過某種方式將 Cookie 內容提交到指定的伺服器（如：AJAX）。一旦 Cookie 落入攻擊者手中，它將會重現其價值。　　建議開發人員在向用戶端 Cookie 輸出敏感的內容時（譬如：該內容能識別使用者身份）：　　1）設定該 Cookie 不能被指令碼讀取，這樣在一定程度上解決上述問題。 　　　　2）對 Cookie 內容進行加密，在加密前嵌入時間戳記，保證每次加密後的密文都不一樣（並且可以防止訊息重放）。 　　　　3）用戶端請求時，每次或定時更新 Cookie 內容（即：基於第2小條，重新加密） 　　　　4）每次向 Cookie 寫入時間戳記，資料庫需要記錄最後一次時間戳記（防止 Cookie 篡改，或重放攻擊）。 　　　　5）用戶端提交 Cookie 時，先解密然後校正時間戳記，時間戳記若小於資料資料庫中記錄，即意味發生攻擊。　　基於上述建議，即使 Cookie 被竊取，卻因 Cookie 被隨機更新，且內容無規律性，攻擊者無法加以利用。另外利用了時間戳記另一大好處就是防止 Cookie 篡改或重放。　　 Cookie 竊取：搜集使用者cookie並發給攻擊者的駭客。攻擊者將利用cookie資訊通過合法手段進入使用者帳戶。 　　Cookie 篡改：利用安全機制，攻擊者加入代碼從而改寫 Cookie 內容，以便持續攻擊。

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 更為困難。

 

【電腦網路學習筆記】什麼是cookie以及cookie劫持的基本概念