本博文翻譯自：
https://dotnetcoretutorials.com/2017/10/16/owasp-top-10-asp-net-core-broken-authentication-session-management/

在我們之前關于OWASP Top 10的文章中，我們討論了SQL注入。SQL注入有一個非常明確的解釋和例子，但這次我們講的個關于“失效的訪問控制和Session管理”有一個更開放的結尾。它涵蓋了從糟糕的密碼存儲系統(純文本，弱哈希)到通過Session暴露用戶的所有內容(例如，URL中的Session字符串)，我們演示的所有方法都是相對簡單的，例如超時驗證session。

和往常一樣，雖然我們在這里討論的話題是如何保護ASP.net Core應用程序讓它有個好的開始，但這絕不是我們保護道路的盡頭。特別是當涉及到密碼的哈希時。這是一款總是與最新的威脅保持同步的游戲，我們需要時刻更新我們的的應用程序。

讓我們開始吧！

密碼哈希化

不言而喻，存儲在數據庫中的所有密碼應該被哈希化并且具有單獨的salt（稍后更多關于單獨的salt的信息）。在任何情況下，密碼都不能以純文本形式存儲。當您存儲純文本密碼時，您不僅會冒著被黑客攻擊的風險，而且網站上的用戶帳戶可能會被盜用，但由于人們傾向于在多個網站上使用相同的密碼，所以在他們使用的每個網站上，你都有可能成為用戶痛苦的來源。

使用 ASP.net Core Identity

如果您使用ASP.net Core Identity框架，你將會有安全的密碼哈希和使用的單獨的salt。Identity使用PBKDF2哈希函數來輸入密碼，并且它們會為每個用戶生成一個隨機salt。理想情況下，如果你不確定你在做什么，那就現在開始使用吧! 微軟在啟動和運行框架方面確實有很好的文檔.。

讓我們開始動手吧

雖然現在開始使用ASP.net Core Identity框架是絕對可取的，但有時你需要自己動手。但你自己動手的版本只能擴展C＃代碼用來驗證，在任何情況下你都不應該“發明”自己的哈希算法來存儲密碼。

OWASP建議使用4種不同的單向哈希函數來存儲密碼。他們分別是Argon2，PBKDF2，scrypt和bcrypt。如果你打算編寫你自己的認證層，你必須使用其中的一個。

什么是Salt？

Salt是在哈希之前向您的密碼添加隨機字符串的行為。這樣，即使相同的密碼被哈希化，所得到的哈希值將會不同...是不是有些疑惑？我們用一個例子。本例中我將使用PBKDF2哈希函數。

比方說，我正在使用密碼 apples4tea 。當我哈希化密碼時我得到的結果： 09ADB1C51A54C33C11CD3AE113D820305EFA53A173C2FF4A3150B5EC934E76FF 。現在，如果第二個用戶注冊到我的網站并使用相同的密碼，他們將得到完全相同的哈希值。您可以在這里使用PBKDF2在線計算器來自己測試。為什么這不好？因為這意味著任何黑客基本上都可以“預先計算”密碼哈希值（例如，現在就拿一個最流行的密碼列表），然后在數據庫中簡單地進行字符串比較。

在此基礎上，這意味著共享相同密碼的所有用戶具有相同的哈希值。當一個用戶的密碼被“破解”或者甚至被猜出時，任何使用相同密碼的人現在也都泄露了他們的密碼。

現在我為用戶添加一個隨機Salt值，我將它連接到密碼的開始處。第一次我的Salt值是 H786Bnh54A 。哈希化后H786Bnh54Aapples4tea的完整字符串 給了我 DfsjpycJwtWkOu8UcP8YXC / G09HES8LU + kku0iSllO4 =的哈希值 。另一個用戶注冊到該站點，并隨機生成一個Salt值給他們 76HNhg67Ac 。現在我們使用相同的密碼對salt進行哈希化，最后得到一個哈希值 RP62 + SmFCJLeQzROTtk5HpMId0zuFtsPeBFuBLpH / Sc =。現在我們有相同的密碼，但有不同的哈希值。

眾所周知，Adobe在2013年有一個巨大的數據泄露，泄露了用戶的密碼。密碼并不是每個用戶都加了Salt值，最糟糕的是，所有密碼提示都存儲在密碼的旁邊。也就是說，如果一個提示幫助您猜測一個用戶密碼，那么使用相同密碼的任何用戶在數據庫中都會有相同的哈希值! Sophos在這里做了一個很好的報告.

如果你使用的是ASP.net Identity，那么salt會和密碼一起存儲在數據庫中的同一列（因為salt每次都是相同的長度，所以我們只把這些字符當作salt來計算，其余部分就是哈希值）。在先前的ASP迭代中（在.NET完整框架中），salt存儲在一個單獨的列中。然而只要每個用戶都有salt，而不是整個應用程序范圍內擁有，就都可以。

暴露Session標識符

在以前的ASP.net版本中，你可以有一個“無cookie”的session。然后，您會看到與以下網址相似的網址：http：//www.example.com/(S(lit3py55t21z5v55vlm25s55))/orderform.aspx 。會話數據實際上包含在URL中而不是cookie中。由于多種原因，這造成了嚴重的后果。想象一下把這個URL發給一個朋友，現在他們可以訪問你的會話數據！更糟糕的是，如果您點擊此頁面上的任何出站鏈接，引用鏈接頭將被設置為包含您的session。

在ASP.net Core中無cookie的sessions實際上從來沒有實現，所以你不會看到這樣的URL。但這并不意味著人們不會用自己的方式實現類似的東西。簡而言之，通過任何方式給予另一個用戶的URL都不能突然冒充用戶。

通過未加密的連接發送數據

實際上有一個關于加密連接的完整的OWASP Top 10文章，但是這里值得特別提一下。即使你的密碼全部被用戶salt哈希化，而且你也不會在URL中暴露Session標識符，但是如果你容易受到“中間人”攻擊的話，這意味著根本沒有安全。一個用戶連接到一些不可靠的開放wifi，可能意味著他們在登錄時無意中泄露了我們的明文密碼。

SSL意味著您從用戶計算機到服務器進行加密，無論它需要什么路由 - 包括狡猾的wifi。鑒于免費的SSL提供商如Let's Encrypt的出現，甚至像Cloudflare這樣的網站提供免費的SSL。沒有理由不利用SSL來保護您的用戶。

鎖定，超時，等等

最后，我們在本文中已經討論了ASP.net Core Identity。但我想再次指出的是，良好的習慣對這有多大的影響。我們來看看通常放置在您的Configure Services方法中的Identity的設置。

services.Configure(options => { ? ?// Password settingsoptions.Password.RequireDigit = true;options.Password.RequiredLength = 8;options.Password.RequireNonAlphanumeric = false;options.Password.RequireUppercase = true;options.Password.RequireLowercase = false;options.Password.RequiredUniqueChars = 6;options.Lockout.DefaultLockoutTimeSpan = TimeSpan.FromMinutes(30);options.Lockout.MaxFailedAccessAttempts = 10;options.SignIn.RequireConfirmedEmail = true;options.User.RequireUniqueEmail = true; });

看看你在這里的選項。有很好的密碼執行選項（盡管你可以提出一些論點：但不要過分要求像字母數字這樣的東西，因為人們傾向于把它們寫在紙上...），如果他們鎖定用戶帳戶不斷輸入錯誤的密碼，甚至需要電子郵件確認（這也是身份框架的一部分）。

而在cookies如何存儲在用戶機器上，我們有這些選項：

services.ConfigureApplicationCookie(options => {options.Cookie.HttpOnly = true;options.Cookie.Expiration = TimeSpan.FromHours(1)options.SlidingExpiration = true; });

又一次很棒的實踐。用戶cookie在默認情況下應該總是有一個過期值。一個來自OWASP的例子甚至明確指出了在攻擊的例子中公共計算機session超時的問題:

在此基礎上，我們應該盡可能使用HttpOnly cookie。當一個cookie被設置為HttpOnly時，這意味著它不能通過Javascript訪問（因此，可能存在XSS漏洞），并且只能在作為請求的一部分發送時才能被訪問。

我之所以使用這些例子，是因為它們是在進行身份驗證和session管理時最佳實踐指南。即使您決定自己動手，您也應該調查Identity給您的是什么，這樣您就可以復制一些或所有的功能，并且始終保持對框架最新的的改進。

總結

身份驗證和session管理是一個廣泛的話題，我認為它被一些呆滯的遺留應用程序所困擾。通常，當我向新的開發人員展示諸如session標識符之類的東西時，他們無法想象為什么有人會這樣做。“人們真的認為那是安全的嗎?”這是我與之合作的一名初級開發人員的和我說過的話。我認為這是這個話題的本質，我們需要站在新安全的前沿，在認證和使用session的時候，我們要保持領先

相關文章：

• ASP.NET Core中的OWASP Top 10 十大風險-SQL注入
  

原文地址：http://www.cnblogs.com/chen-jie/p/owasp-top-10-asp-net-core-broken-authentication-session-management.html

---

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結

以上是生活随笔為你收集整理的ASP.NET Core中的OWASP Top 10 十大风险-失效的访问控制与Session管理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。