6.4 對會話管理進行安全防范

在一般情況下，Web開發人員在開發過程中是會留意常規的Web安全漏洞的，但也有一些鮮為人知的漏洞廣泛存在于Web應用程序中。大多數開發人員針對這些漏洞不做任何考慮，使得Web應用程序仍然處于危險中。鑒于會話管理機制主要受兩類漏洞的影響，Web應用程序必須采取相應的防御措施，防止這些機制受到攻擊。為執行安全的會話管理，應用程序必須以可靠的方式生成令牌，并且必須在令牌生成到廢止的整個生命周期中確保它們的安全。

6.4.1 設置最有效的令牌生成機制

從理論上講，只要擁有足夠的時間和資源，任何數據，無論其長度和復雜程度如何，都可以使用蠻力猜測出來。設計強大的令牌生成機制的目的：在連續請求中重新標識用戶身份的令牌，在其生成過程中，不應給攻擊者提供任何機會，使其能夠以常規方式預測或推斷發布給其他用戶的令牌，從而從應用程序中獲得大量的令牌樣本。即使攻擊者擁有大量帶寬和處理資源，他也絕無可能在令牌的有效期限內成功猜測出任何一個有效的令牌。

最有效的令牌生成機制應當使用數量極其龐大的一組可能值，并且包含強大的偽隨機源，確保令牌以無法預測的方式平均分布在可能值范圍內。

令牌中不應包含其他任何內容（除服務器用來定位處理用戶請求的相關會話對象的一個標識符）。無論是公開顯示還是隱藏在幾層編碼或模糊處理中，令牌都不應含有意義或采用結構。所有關于會話所有者與狀態的數據都應保存在與會話令牌對應的服務器會話對象中。

選擇最為穩定可靠的隨機源。開發者應當認識到，各種可用的隨機源在強度上可能存在巨大的差異。和java.util.Random一樣，一些隨機源非常適用于各種需要不斷變化的輸入源的情況，但只需根據唯一一個輸出項就可以準確地推斷出它的前后隨機數。開發者應研究不同的可用隨機源實際使用算法的數學特性，并閱讀相關文檔資料，了解API的推薦用法。一般來說，如果某種算法沒有明確說明它具有加密安全性，那么應認為它可被預測。

除選擇最為穩定可靠的隨機源外，以與其生成令牌請求有關的一些信息作為熵源，也是一種良好的做法。這些信息可能并不是那個請求獨有的，但能夠非常有效地消除所使用的核心偽隨機數發生器存在的任何缺陷。可被合并的信息包括請求時間（毫秒）、請求中的User-Agent消息頭、來源IP地址（source IP address）及接收請求的端口號等元素。

合并這個熵的最有效公式是建立一個特殊的字符串，連接一個偽隨機數、一串上面列出的與請求有關的數據以及一個僅服務器知道并在每次重啟時重新生成的機密字符串。然后，使用適當的散列算法對這個字符串進行處理，生成一個固定長度、便于管理的字符串，并以它作為令牌。

決定生成會話令牌的算法后，一個有用的“思想試驗”是想象偽隨機源被完全攻破，并總是返回相同的隨機數。如果出現這種情況，那么從應用程序中獲得大量令牌樣本的攻擊者能夠截獲發布給其他用戶的令牌嗎？使用上面描述的公式，即使攻擊者完全了解生成令牌所使用的算法，一般也絕無這種可能。來源IP、端口號、User-Agent消息頭和請求時間共同生成一個數目龐大的熵。即使掌握所有這些信息，如果不知道服務器使用的機密字符串，攻擊者仍然無法生成對應的令牌。

6.4.2 保障令牌使用過程中的安全

在令牌生成到廢止的整個生命周期中保障它的安全，達到不會將其泄露給除令牌用戶以外的其他任何人的目標要做到以下幾方面。

（1）令牌只能通過HTTPS傳送。

任何以明文形式傳送的令牌都應視為被“污染”，也就是說，不能確保用戶身份不被泄露。如果使用HTTP Cookies傳送令牌，應將這些Cookies標記為安全，以防止用戶瀏覽器通過HTTP傳送它們。如果可能，應對每個應用程序頁面使用HTTPS，包括靜態內容（如幫助頁面、圖像等）。如果沒有可能，并且仍然采用HTTP服務，那么應用程序應將任何訪問敏感內容（包括登錄頁面）的請求重定向到HTTPS服務。幫助頁面之類的靜態資源一般不屬于敏感內容，不需要使用通過驗證的會話即可訪問。因此，可以通過使用Cookies范圍指令強化Cookies的使用安全，防止在訪問這些資源的請求中提交令牌。

（2）絕不能在URL中傳送會話令牌。

因為這樣做易于受到會話固定攻擊，并可能使令牌出現在各種日志機制中。有時候，開發者在禁用Cookies的瀏覽器中使用這種技巧執行會話。然而，最好是對所有導航使用POST請求實現這一目的，并將令牌保存在HTML表單隱藏字段中。

（3）應總是執行退出功能。

通過它刪除服務器上的所有會話資源并終止會話令牌。

（4）處于非活動狀態一段時間執行會話終止。

會話終止的效果應和用戶完全退出的作用完全相同。

（5）防止并行登錄。

每次一名用戶登錄，都應發布一個新會話令牌，同時廢止任何屬于該用戶的現有會話，就好像他已經退出應用程序一樣。如果舊令牌被保存一段時間，那么隨后收到任何使用該令牌提出的請求，都應向用戶發出安全警報，告訴他會話已被終止，因為他已經從其他位置登錄。

（6）嚴密保護會話令牌的管理或診斷功能。

嚴密保護會話令牌的管理或診斷功能，以防止未授權的訪問。許多時候，這種功能根本沒有必要顯示會話令牌，相反，它應提供足夠的與會話所有者有關的信息，以便執行任何支持和診斷任務。這樣做就不會泄露該用戶提交的會話令牌，使攻擊者劫持他的會話。

（7）盡可能限定應用程序會話Cookies的域和路徑范圍。

范圍過于寬泛的Cookies通常是由配置不佳的Web應用程序平臺或Web服務器生成的，而不是由應用程序開發者本人生成的。通過應用程序Cookies范圍中的域名或URL路徑，應無法訪問其他Web應用程序或不可信的功能。應特別注意用于訪問應用程序域名的任何現有子域。有時，為了確保不會造成這種漏洞，必須修改組織所使用的各種應用程序的域和路徑命名方案。

（8）采取特殊措施保護會話管理機制的安全。

這可以防止應用程序用戶成為各種攻擊的目標。

（9）嚴格審查應用程序的代碼庫。

這可以確定并刪除任何跨站點腳本漏洞。許多這類漏洞可被用于攻擊會話管理機制，特別是保存型（或二階）XSS攻擊，它可對每一種會話濫用與劫持防御造成破壞。

（10）不應接受用戶提交但服務器并不認可的任何令牌。

應立即在瀏覽器中取消該令牌，并將用戶返回到應用程序的起始頁面。

（11）進行兩步確認或重新驗證。

在執行轉賬之類的重要操作之前，可有效防御跨站點請求偽造和其他會話攻擊。

（12）不完全依賴HTTP Cookies傳送會話令牌。

這樣可以防御跨站點請求偽造攻擊。使用Cookies機制會造成這種漏洞是因為無論什么原因提出請求，瀏覽器都會自動提交Cookies。如果總是通過HTML表單隱藏字段傳送令牌，那么除非攻擊者已經知道令牌，否則他就無法建立一個表單，再通過提交該表單執行未授權操作。當然，如果他已經知道令牌，就可以輕易實施劫持攻擊。每頁面令牌也有助于防止這些攻擊。

（13）成功驗證后應總是建立一個新的會話。

可以避免會話固定攻擊的影響。如果應用程序并不使用驗證機制，但允許提交敏感數據，那么會話固定攻擊造成的威脅就更難以解除。一種可能的解決辦法是使提交敏感數據的頁面序列盡可能短，并且在這個序列的第一個頁面建立一個新的會話（如有必要，從現有會話中復制任何需要的數據，如購物車的內容），或者使用每頁面令牌，防止知道第一個頁面所使用的令牌攻擊者訪問隨后的頁面。除非完全有必要，否則不得向用戶顯示個人數據。即使有必要（如顯示地址的“確認訂單”頁面），也不得向用戶顯示信用卡號碼和密碼之類的敏感數據，并且應在應用程序的響應中隱藏這些數據。

（14）應用每頁面令牌。

應在會話令牌的基礎上使用每頁面令牌，對會話實施更加嚴格的控制，更有效地防御或阻斷各種會話攻擊。使用每頁面令牌時，每次用戶請求一個應用程序頁面（而不是圖像），應用程序都會建立一個新的頁面令牌，并通過Cookies或HTML表單隱藏字段將其傳送給客戶。用戶每次提出一個請求，除通過主會話令牌進行正常確認外，頁面令牌還根據最后發布的令牌值進行再次檢驗。如果出現不匹配的情況，整個會話將被終止。

雖然使用每頁面令牌確實給導航造成一些限制（如使用“后退”和“前進”按鈕以及多窗口瀏覽方面），但它能夠有效防御會話固定攻擊，并確保如果合法用戶和攻擊者同時使用一個被劫持的會話提出相同的請求，該請求會立即被應用程序終止。每頁面令牌還可用于追蹤用戶的位置和在應用程序中的活動情況，檢測出不按預定順序訪問某些功能的企圖，并有助于防止某些訪問控制缺陷。

6.4.3 使用日志、監控等輔助功能

應用程序的會話管理功能應與它的日志、監控與警報機制緊密結合，以在適當時記錄反常行為，并幫助管理員在必要時采取防御措施。應用程序應監控包含無效令牌的請求。除非令牌很容易被預測，否則，攻擊者就需要提出大量包含無效令牌的請求，才能成功猜測出應用程序發布給其他用戶的令牌，從而在應用程序的日志中留下明顯的痕跡。

很難完全阻止針對會話令牌的蠻力攻擊，因為我們無法通過禁用特殊用戶賬戶或會話來終止這種攻擊。一種可能的防御方法是在收到大量包含無效令牌的請求時將其來源IP地址屏蔽一段時間。然而，如果一個用戶的請求來自幾個IP地址（如AOL用戶），或者幾個用戶的請求來自同一個IP地址（如執行網絡地址轉換的代理服務器或防火墻中的用戶），這種方法就不能發揮太大的作用。

即使無法立即有效防止針對會話的蠻力攻擊，但保留詳細的日志并向管理員發出警報仍然可幫助他們對攻擊進行調查，并盡其所能采取適當的行動。

只要有可能，應向用戶警告與會話有關的反常事件，如并行登錄或明顯的劫持攻擊（使用每頁面令牌檢測）。即使用戶的令牌已被攻破，這樣做也可促使用戶進行檢查，看是否發生轉賬之類的未授權操作。

那么什么又叫反應性會話終止呢？會話管理機制可非常有效地防御許多針對應用程序的其他攻擊。如果收到用戶提交的反常請求（例如，任何包含被修改的隱藏HTML表單字段或URL查詢字符串參數的請求、任何包含與SQL注入或跨站點腳本攻擊有關的字符串請求，以及任何正常情況下已經被長度限制之類的客戶端檢查阻止的用戶輸入），那么一些安全性至關重要的應用程序（如電子銀行）會極其迅速地終止用戶的會話。

當然，任何使用這類請求可對其加以利用的漏洞都必須從源頭進行清除。但是，迫使用戶每次提交一個無效請求時都需要進行重新驗證會顯著延長探查應用程序漏洞所需的時間，即使采用自動技巧完成這一任務也是如此。如果殘余的漏洞確實存在，其他人就更不可能發現它們。

如果執行這種防御，為方便測試，建議在需要時將其關閉。如果在對應用程序進行合法滲透測試時，這種防御就像是遇到真正的攻擊者那樣減緩應用程序的響應速度，那么它的效率就會顯著降低。與不使用這種機制相比，使用它很可能會在代碼中造成更多的漏洞。