這篇文章闡述了為什么會話管理和會話管理安全性都是復雜的工作，這就是為什么它們經常會留給商業產品來處理。這篇文章描述這兩個商業應用程序引擎的語言符號是怎樣產生的。作者分析了每個機制的能力，闡述了它的弱勢，還論證了這樣的弱勢怎樣才能被利用，從而執行模擬和私人違規攻擊。他還討論了攻擊性的可行性。最后，他提出一種將安全性從功能中分開的會話管理的方法，并且后者由應用程序引擎實施，但是前者是由一個專門的應用程序安全產品所提供的。

　　cookie 篡改風險的特征

　　cookie 篡改 (cookie poisoning) 是一項主要以獲取模擬和隱私權泄密著稱的技術，通過維護客戶(或終端用戶)身份的會話信息操縱來實現的。通過打造這些 cookie ，一個黑客可以模擬一個有效的客戶，因此獲取詳細信息并執行代表病毒的行為。這種打造的能力，像會話 cookie (或者更通俗地說，會話標識)源自于這些標識不是以安全的方式產生的事實。

　　內部會話維護的無休止工作

　　在 Web 應用程序程序設計中，會話管理是復雜且笨拙的。程序設計者會擔心會話管理的許多方面，它能夠將他/她從主要目標中的注意力分散：執行這個使此網站唯一且有用的商業邏輯。

　　具體問題：

　　會話的創建和識別：您如何能夠確定何時的確需要一個新的會話，而且它確實已經創建了?程序設計者必須鑒定有一個客戶確實需要一個會話，并創建這個會話以及為這個客戶分配一個會話。

　　并發問題：當兩個客戶同時訪問這個網站時，每個都需要一個新的會話，就有必要確保這個會話創建過程仍然能夠正確地運行。

　　會話的終止和暫停：是什么導致一個會話終止的呢?這些終止的會話資源是如何被重新循環使用的呢?當正在進行終止過程時客戶訪問這個網站，又會發生什么情況呢?當客戶訪問帶有就的會話的網站時會發生什么情況呢?

　　會話數據存儲，多個服務器，失敗。會話的數據儲存在什么地方呢?磁盤上?隨機存儲器上?會有什么樣的高性能懲罰?如果一個客戶訪問第一個服務器(并建立一個會話跟它一起)，然后被(負載均衡服務器)導向到第二個服務器，那么在一個多服務器站點將會發生什么?如果原始服務器壞掉，對這個客戶會話數據將會有什么樣影響?

　　安明智，下面這些點非常重要，值得思考：

　　一個客戶要想預測另一個客戶所接受的，或者正在接受的，或者即將接受的標識，幾乎是不可能的。這很顯然是一個必須防止的模擬攻擊，因此也會違背隱私權。

　　此外，理想的情況是，當訪問一個站點時，客戶不能夠預測下一個他們即將獲取的標識。這對當它來回漫游(不受阻礙)時最小化竊取標識的損壞很有用處，而且在它儲存在客戶的計算機上也很有用。

　　任何標識都應該有一個合理的期限——可再次將它被竊取的損壞程度降到最低。

　　正如您所說，要實現所有的請求并不十分容易，尤其是當這個會話機制發展成無線自組織網時。就會有更復雜的安全需求來明確開發人員，尤其是對安全并不十分熟悉的人員，他們更容易遺忘。

　　在標識中有很多安全不足的例子。這些在 MIT Laboratory for Computer Science 的著作中有很好的證明(請看Dos and Don'ts of Client Authentication on the Web由 Kevin Fu， Emil Sit， Kendra Smith， 以及 Nick Feamster 合著)。這樣，我們就清楚生產一個良好的會話管理解決方案是相當困難的，更不用說一個安全的會話管理解決方案了。這就是為什么應用服務器如此這樣受人歡迎的原因之一。

　　應用服務器和引擎：解決方案和問題

　　一個 Application Server(或者 Application Engine)就是一個軟件程序，是用來使這個應用程序開發者的工作更輕松。它通常會為程序開發者提供編寫 HTML 網頁的便利，而且這些網頁中帶有服務器嵌入的指導，指示這個服務器來執行各種任務。大多數應用服務器會為程序開發者提供自動管理會話的環境，將程序開發人員從上面板塊中所有提到的擔憂中解救出來。

　　應用服務器的案例：

　　Microsoft® ASP .NET， 是在 IIS 頂端進行運行的

　　Macromedia

　　ColdFusion

　　Apache Tomcat

　　Apache JServ

　　PHP

　　BEA WebLogic

　　IBM ® WebSphere® Application Server。

　　Security Space Web 網站的 Internet Cookie Report 網頁通過將這些 cookie 的名稱和發行它們的服務器聯合起來，從而提供了一些頻率分析。當然，這樣說是不全面的，因為一些服務器和站點以參數的形式而不是 cookie 的形式來使用標識的。

　　應用程序引擎的上面反應了這樣一個事實：他們完全將程序開發者從會話管理的擔憂中釋放出來。會話管理功能的各個方面，通常以更好的方式來管理，而并非內部程序員所能達到的。

　　應用程序引擎的下面反應了這樣的事實：他們看起來是把程序員從標識安全性問題的擔憂中釋放出來。然而我們可以從損害的事實顯示中看到，遠不是這樣的。事實上，一些十分受歡迎的應用程序殷勤根本就不提供安全標識。因此，程序員對安全性就有錯誤的意識。

　　我的合作伙伴和我檢測到這些標識是由兩個十分受歡迎的應用服務器所產生的。在這兩個案例中，我們曾經證明這個標識并不是像它看起來那樣的隨意，它只是可能(在一個案例中，比較簡單)會預測下一個會話(是不同客戶的會話)標識的值。

　　案例 1. 打敗一個基于時間的標識

　　這次攻擊的目標是一個非常受歡迎的商業應用程序引擎。這個產品利用兩個 cookie 來鑒定一個會話。由兩個 cookie 形成的這對來鑒定一個會話。第一個 cookie 僅僅是一個計算器，每次有新的會話時就會增加。它大概能確保不可能有兩對是相同的。第二個 cookie 是標識 cookie ，顯然是通過“不可預知”來確保這對的安全。假設可以很輕松地預測第一個 cookie ，那么我們這里所關注的第一個 cookie ，就會被標識為TOKEN。

　　第一眼看到的時候，TOKEN 看起來是一個隨機的八進制數字的序列。這里的熵是108 = 226.57，它可能是經過充分的考慮過，嘗試如此多的請求(一億次)次數是可行的，而不是一個沒有控制警告和人們注意的網站。但是靠近看就會發現，事實上， TOKEN 符合以下的方程式：

我們用t表示 GMT 時間，按秒計算，因為 01/01/1970 00:00，與這個應用服務器上的設置一樣。 我們用m表示這個應用服務器上最小單位毫秒。 那么： TOKEN= ( 31415821 * (t+m) + 1 ) mod 100000000

　

原文轉自：http://www.anti-gravitydesign.com