身份認證和會話管理：
在進一步解釋這種危險的漏洞之前，讓我們了解一下身份認證和會話管理的基本知識。身份認證，最常見的是登錄功能，往往是提交用戶名和密碼，在安全性要求更高的情況下，有防止密碼暴力破解的驗證碼，基於客戶端的證書，物理口令卡等等。
會話管理，HTTP本身是無狀態的，利用會話管理機制來實現連接識別。身份認證的結果往往是獲得一個令牌，通常放在cookie中，之後對用戶身份的識別根據這個授權的令牌進行識別，而不需要每次都要登陸。
什麼是失效的身份認證和會話管理？
用戶身份認證和會話管理是一個應用程序中最關鍵的過程，有缺陷的設計會嚴重破壞這個過程。在開發Web應用程序時，開發人員往往只關注Web應用程序所需的功能。由於這個原因，開發人員通常會建立自定義的認證和會話管理方案。但要正確實現這些方案卻很難，結果這些自定義的方案往往在如下方面存在漏洞：退出、密碼管理、超時、記住我、秘密問題、帳戶更新等等。因為每一個實現都不同，要找出這些漏洞有時會很困難。
一些存在此漏洞的例子：
1、用戶更改密碼之前不驗證用戶，而是依靠會話的IP地址;
2、沒有會話超時限制;
3、用戶忘記密碼後，密碼找回功能太過簡單。
4、。。。
例1：應用程序超時設置不當。用戶使用公共計算機訪問網站。離開時，該用戶沒有點擊退出，而是直接關閉瀏覽器。攻擊者在一個小時後能使用相同瀏覽器通過身份認證。
例2：機票預訂應用程序支持URL重寫，把會話ID放在URL里：
該網站一個經過認證的用戶希望讓他朋友知道這個機票打折信息。他將上面鏈接通過郵件發給他朋友們，並不知道自己已經泄漏了自己的會話ID。當他的朋友們使用上面的鏈接時，他們將會使用他的會話和信用卡。
例3：內部或外部攻擊者進入系統的密碼數據庫. 存儲在數據庫中的用戶密碼沒有被加密, 所有用戶的密碼都被攻擊者獲得。
如何驗證程序是否存在失效的認證和會話管理？
最需要要保護的數據是認證憑證(credentials) 和會話ID。
1.當存儲認證憑證時，是否總是使用hashing或加密保護嗎?
2. 認證憑證是否可猜測，或者能夠通過薄弱的的帳戶管理功能
(例如賬戶創建、密碼修改、密碼恢復, 弱會話ID)重寫？
3.會話ID是否暴露在URL里(例如, URL重寫) ？
4.會話ID是否容易受到會話固定(sessionfixation) 的攻擊?
5.會話ID會超時嗎? 用戶能退出嗎?
6.成功註冊後,會話ID會輪轉嗎?
7. 密碼、會話ID和其他認證憑據是否只通過TLS連接傳輸？
如何防範：
1、區分公共區域和受限區域
站點的公共區域允許任何用戶進行匿名訪問。受限區域只能接受特定用戶的訪問，而且用戶必須通過站點的身份驗證。考慮一個典型的零售網站。您可以匿名瀏覽產品分類。當您向購物車中添加物品時，應用程序將使用會話標識符驗證您的身份。最後，當您下訂單時，即可執行安全的交易。這需要您進行登錄，以便通過SSL驗證交易。
將站點分割為公共訪問區域和受限訪問區域，可以在該站點的不同區域使用不同的身份驗證和授權規則，從而限制對 SSL 的使用。使用SSL 會導致性能下降，為了避免不必要的系統開銷，在設計站點時，應該在要求驗證訪問的區域限制使用 SSL。
2、對最終用戶帳戶使用帳戶鎖定策略
當最終用戶帳戶幾次登錄嘗試失敗後，可以禁用該帳戶或將事件寫入日誌。如果使用 Windows 驗證(如 NTLM 或Kerberos協議)，操作系統可以自動配置並應用這些策略。如果使用表單驗證，則這些策略是應用程序應該完成的任務，必須在設計階段將這些策略合併到應用程序中。
請注意，帳戶鎖定策略不能用於抵制服務攻擊。例如，應該使用自定義帳戶名替代已知的默認服務帳戶(如IUSR_MACHINENAME)，以防止獲得 Internet 信息服務 (IIS)Web服務器名稱的攻擊者鎖定這一重要帳戶。
3、支持密碼有效期
密碼不應固定不變，而應作為常規密碼維護的一部分，通過設置密碼有效期對密碼進行更改。在應用程序設計階段，應該考慮提供這種類型的功能。
4、能夠禁用帳戶
如果在系統受到威脅時使憑證失效或禁用帳戶，則可以避免遭受進一步的攻擊。
5、不要在用戶存儲中存儲密碼
如果必須驗證密碼，則沒有必要實際存儲密碼。相反，可以存儲一個單向哈希值，然後使用用戶所提供的密碼重新計算哈希值。為減少對用戶存儲的詞典攻擊威脅，可以使用強密碼，並將隨機salt 值與該密碼結合使用。
6、要求使用強密碼
不要使攻擊者能輕鬆破解密碼。有很多可用的密碼編制指南，但通常的做法是要求輸入至少 8位字符，其中要包含大寫字母、小寫字母、數字和特殊字符。無論是使用平台實施密碼驗證還是開發自己的驗證策略，此步驟在對付粗暴攻擊時都是必需的。在粗暴攻擊中，攻擊者試圖通過系統的試錯法來破解密碼。使用常規表達式協助強密碼驗證。
7、不要在網絡上以純文本形式發送密碼
以純文本形式在網絡上發送的密碼容易被竊聽。為了解決這一問題，應確保通信通道的安全，例如，使用 SSL 對數據流加密。
8、保護身份驗證 Cookie
身份驗證 cookie被竊取意味着登錄被竊取。可以通過加密和安全的通信通道來保護驗證票證。另外，還應限制驗證票證的有效期，以防止因重複攻擊導致的欺騙威脅。在重複攻擊中，攻擊者可以捕獲cookie，並使用它來非法訪問您的站點。減少 cookie 超時時間雖然不能阻止重複攻擊，但確實能限制攻擊者利用竊取的 cookie來訪問站點的時間。
9、使用 SSL 保護會話身份驗證 Cookie
不要通過 HTTP 連接傳遞身份驗證 cookie。在授權 cookie 內設置安全的 cookie 屬性，以便指示瀏覽器只通過HTTPS 連接向服務器傳回 cookie。
10、對身份驗證 cookie 的內容進行加密
即使使用 SSL，也要對 cookie 內容進行加密。如果攻擊者試圖利用 XSS 攻擊竊取cookie，這種方法可以防止攻擊者查看和修改該 cookie。在這種情況下，攻擊者仍然可以使用 cookie 訪問應用程序，但只有當cookie 有效時，才能訪問成功。
11、限制會話壽命
縮短會話壽命可以降低會話劫持和重複攻擊的風險。會話壽命越短，攻擊者捕獲會話 cookie並利用它訪問應用程序的時間越有限。
12、避免未經授權訪問會話狀態
考慮會話狀態的存儲方式。為獲得最佳性能，可以將會話狀態存儲在 Web 應用程序的進程地址空間。然而這種方法在 Web場方案中的可伸縮性和內涵都很有限，來自同一用戶的請求不能保證由同一台服務器處理。在這種情況下，需要在專用狀態服務器上進行進程外狀態存儲，或者在共享數據庫中進行永久性狀態存儲。ASP.NET支持所有這三種存儲方式。
對於從 Web 應用程序到狀態存儲之間的網絡連接，應使用 IPSec 或 SSL 確保其安全，以降低被竊聽的危險。另外，還需考慮Web 應用程序如何通過狀態存儲的身份驗證。
在可能的地方使用 Windows驗證，以避免通過網絡傳遞純文本身份驗證憑據，並可利用安全的 Windows 帳戶策略帶來的好處。
除了上述之外，這裡根據個人經驗對防範措施作出一點補充：
1.不使用簡單或可預期的密碼回復問題。
2. 登錄出錯時不給過多或者過於詳細的提示信息。
3. 驗證成功後更換sessionID。
留言列表