我們注意到十分有趣的是，t可以從服務器返回到客戶的 HTTP Date 標頭中提取出來，與這個 cookie 第一次的設置一起。這意味著 TOKEN cookie 是完全可預測的。事實上，如果有人了解 cookie 所產生時的時間排列 T MILY: 'Andale Mono', 'Lucida Console', Monaco, fixed, monospace; MARGIN-BOTTOM: 0px; FONT-SIZE: 11px" class="displaycode"> 獲取第一對 (id1， TOKEN1)。記錄 t1 –
服務器時間(從 Date HTTP 標頭開始)
等待ΔT 秒鐘。獲取第二對 (id22， TOKEN2)。
記錄 t2–服務器時間從 Date HTTP 標頭開始)。
如果 (id2 > id1 +1) 開始 //
我們在這里插入看一個受害者會話。
對于 (x= t1 ; x < t2+1000 ; x++) //
它只是ΔT+1000 迭代開始
嘗試這對 (id1 +1, ( 31415821 * x + 1 ) mod 100000000) 終止
事實上，通過利用這樣的事實在某些案例中改進這個算法是可能的，在有些操作系統上，最小單位的計數器并沒有精確到毫秒的粒度，而是較粗糙的10毫秒的粒度。這可被用來減少更多的搜索空間。
上面所描述的攻擊可以使攻擊者來扮演一個受害者的角色，假定這樣的受害者被分配到兩個由站點 cookie 構成的樣例攻擊者之間。因為攻擊者可以任意重復很多次這樣的算法，這樣攻擊者就可能為客戶獲取這些 cookie ，以抽樣這個站點(就是說，每分鐘一個請求)為代價，此外，每次發現新客戶時就有1060個請求。正如上面所暗示的，在更近的間隔(每次一秒)中抽樣以及利用時鐘最小單位粒度的問題是有可能的，在這樣的案例中很可能達到每個新客戶100個請求。
如果在網絡擁擠時下載這個站點執行了一個客戶的模擬嘗試，那么額外的數百或者數千計的請求就會不被注意，至少不會立即被注意。
案例 2. 當 Random() 不是隨機時
在這個例子中，我們處理一個仍舊流行的(然而有些過時的)應用程序引擎。這個引擎為每個新會話產生一個單獨的 cookie (我們稱它為ID)，包括三個強制性的區域(F1，F2，以及F3)以及一個可選擇的(服務器配置從屬)區域(F4，在句號之前)的多連環體。這些區域如下所示：
F1 = 6 字符串(A-Z0-9) – PRNG (Pseudo Random Number Generator) 數據，
用基礎36附帶領頭的零來表示F2 = 3 字符串 (A-Z0-9) –
服務器時間(毫秒)，被 2000 除，
絕對值為 363 (=46656)， 用基礎36附帶領頭的零來表示
F3 = 3字符串(A-Z0-9) – 會話在這兩秒時間內計算，用基礎36來表示 36
F4 = 不變的字符串(每個服務器)
正如您所看到的，F4 (如果它存在的話) 是常量，因此可以進行瑣碎的預測。 F2 僅僅是這個服務器時間(以秒計算)除以2，模數為 46656，它是一個完全可預測性的，以及 F3 也不是特別不出名——它隨著時間的推移在每兩秒內連續地增長(通常從1開始)。
唯一有趣的區域是 F1。顯然，它有足夠的熵來確保這個系統的安全，因為它能夠假定 366值(=231.0)。然而，第一眼看起來安全的其實在執行完整的分析時并不那么安全。在 Appendix A 中闡述了 F1是如何以及為什么可以被預測的，因為太長所以這里沒有包含這部分呢內容。我們利用 F1所解決問題的事實是它使用了一個 PRNG (Pseudo Random Number Generator)，它本質上就是可預測的。因此了解幾個 F1 的值從而全面預測這個 PRNG，也就是未來的(和過去的) F1值。
這就是這樣一次攻擊的概要：
準備工作：
獲取三個 ID，在最短的時間間隔中是可能的。
摘取 PRNG 內部狀態(正如 Appendix A 中所闡述的)。
截獲周期獲得一個 ID，以及記錄服務器時間，t。
簡單地說，假設t是偶數。
找出 PRNG 內部曾經用來產生這個 ID 的狀態(正如 Appendix 中所描述的)
等到 ΔT 秒 (這里的ΔT 是偶數) 就獲取一個新的 ID。
增加這個 PRNG，并記錄舊的 ID 和產生這個 ID 之間的內部狀態(正如 Appendix 中所描述的)。使內部值的列表為 L
//ΔT/2 迭代：
for (T=t; T
begin
for each internal PRNG state L, i.
begin
Try an ID cookie consisting of:
F1=generate from sample of PRNG at state i and i+1;
F2=T;
F3=1; // first session in this 2-second time period
F4=F4 of any ID above; //constant per server
end
end
正如您所看到的，它是可行的，盡管比較重要，可以預測一些 ID cookie 。對于可行性，它要求時間間隔(ΔT)很簡短(并且與這臺服務器的期望使用是相關的)，為了最小化 L 的長度(內部 PRNG 狀態可能的列表)。如果這些間隔的確十分簡短(不超過兩秒)，并且是正確地計時，是可能的，要分辨一個新的會話是否在當前兩秒鐘時間內被插入，它可以使的這次攻擊有更高的效率(只有當了解一個新的受害者會話的確已經創建后它才需要啟用額外的請求)。它還應該被提到的是，避免丟失與這個網站的同步化 (PRNG 內部狀態的同步化)，還需要保持不時地請求新 ID 的狀態，從而加強這個攻擊者對新值的 PRNG 內部狀態。要記住的是，PRNG 很可能因為各種目的而是使用，這樣就導致一個快速的去同步化 (要為它計算，就需要在一個封閉的時間間隔中重新使其同步化，比如每幾分鐘)。從另一方面看，通過檢查應用在這個網站中其它的隨機值，可能更清楚地看清 PRNG 的內部狀態。這樣可能會提供一個捷徑，節省大量的計算能量。
值得注意的是，當這個攻擊者與這個網站同步時，如果 IDs 可以頻繁地被提取，就可能在發送一些請求的消耗中模擬任何客戶端 (它取決于 PRNG 的使用)。
相關供應商的看法
Vendor 1 承認這些缺陷，并通知我們他的消費客戶對于會與管理應該使用 SSL 資格認證。盡管這對于一些消費者來說可能是一個好消息 (但是明確地說并不是所有的消費者，因為移動到 SSL 以及 SSL 資格認證的確很重要 并且有時是不可能的)，這個產品的文獻引導讀者相信這個內嵌的會話管理是安全的(在他們給開發人員的文獻中，他們稱它為“客戶安全標識”)。當然，這個供應商并沒有把這個建議公開。
Vendor 2 承認了這些缺陷，然后給我們寫信說：“會話 cookie 不是一個可代替的認證標識。一個連接中的會話 cookie 與一個隨機鑒定標識或者鑒定登陸審核都是合理的機制。這在設計基于腳本的會話是可實現的——即使這里的會話標識今天是‘可信任的’�！币虼�，他們將這個責任交到開發人員的手中。
這兩個供應商，都從技術上承認了這個問題，卻將它解散成一個非安全性問題。也就是說，兩個供應商假設他們的消費客戶執行他們自己的會話安全標識，而不是依賴于這個供應商的標識，因此，他們聲稱他們的標識僅僅是用來(或者應該用來)更好區分不同的用戶，而不是作為一個安全性評估。在這個文獻中，我們沒有找到任何關于將這個標識作為安全會話標識符的警告。進一步說， Vendor 1的文獻使用了引導用戶相信這個標識是安全的短語。然而實際上，絕大多數站點使用這個由供應商發布的標識作為安全會話的標識符，而忽略了它是有缺陷的事實。
從某種意義上說，應用程序開發人員又回到了這個一致性問題：開發人員不能相信這個內嵌的會話確認機制;因此，他們強調用他們最大的努力編寫他們自己的機制，從而實現先前所提到的所有需求，避免密碼系統的細微陷阱。
結論
病毒的闖入導致會話安全出現問題的事情發生頻率非常高。Vendors 沒有將它改正，也沒有在乎它，或者將這個責任委托給開發人員。內部的開發是很容易出錯的，并且需要對安全性有深入的理解。這篇文章提供了商業應用程序引擎中以及自身應用程序中不安全的真實案例。
這個結論很簡單： Web 應用程序的世界應該包括三個部：
應用程序(它是在內部開發，表達了商業邏輯，以及這個公司或網站的新穎和獨特之處)。
應用程序的環境(這個應用程序引擎和 Web 服務器，它使軟件開發變得更容易，并且集中強調應用程序而不是組織結構)。
Web 應用程序安全構件，它負責這個軟件的安全性，再次將開發人員(在某種程度上，也是這個應用程序引擎的開發人員!)從他們的應用程序安全執行的擔憂中解救出來。
在這里所描述的案例中， 很顯然 Web 應用程序防火墻應該加強這個應用程序引擎或者內部開發的應用程序對標識的產生(開發人員甚至不需要意識到這個問題)。他應該確�！ㄟ^使用加強的密碼系統和安全測試機制——發送到應用程序的標識確實是真實的，而非虛假的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
