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

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

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

讓我們開始吧！

密碼哈希化

不言而喻，存儲(chǔ)在數(shù)據(jù)庫(kù)中的所有密碼應(yīng)該被哈希化并且具有單獨(dú)的salt（稍后更多關(guān)于單獨(dú)的salt的信息）。在任何情況下，密碼都不能以純文本形式存儲(chǔ)。當(dāng)您存儲(chǔ)純文本密碼時(shí)，您不僅會(huì)冒著被黑客攻擊的風(fēng)險(xiǎn)，而且網(wǎng)站上的用戶帳戶可能會(huì)被盜用，但由于人們傾向于在多個(gè)網(wǎng)站上使用相同的密碼，所以在他們使用的每個(gè)網(wǎng)站上，你都有可能成為用戶痛苦的來源。

使用 ASP.net Core Identity

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

讓我們開始動(dòng)手吧

雖然現(xiàn)在開始使用ASP.net Core Identity框架是絕對(duì)可取的，但有時(shí)你需要自己動(dòng)手。但你自己動(dòng)手的版本只能擴(kuò)展C＃代碼用來驗(yàn)證，在任何情況下你都不應(yīng)該“發(fā)明”自己的哈希算法來存儲(chǔ)密碼。

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

什么是Salt？

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

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

在此基礎(chǔ)上，這意味著共享相同密碼的所有用戶具有相同的哈希值。當(dāng)一個(gè)用戶的密碼被“破解”或者甚至被猜出時(shí)，任何使用相同密碼的人現(xiàn)在也都泄露了他們的密碼。

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

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

如果你使用的是ASP.net Identity，那么salt會(huì)和密碼一起存儲(chǔ)在數(shù)據(jù)庫(kù)中的同一列（因?yàn)閟alt每次都是相同的長(zhǎng)度，所以我們只把這些字符當(dāng)作salt來計(jì)算，其余部分就是哈希值）。在先前的ASP迭代中（在.NET完整框架中），salt存儲(chǔ)在一個(gè)單獨(dú)的列中。然而只要每個(gè)用戶都有salt，而不是整個(gè)應(yīng)用程序范圍內(nèi)擁有，就都可以。

暴露Session標(biāo)識(shí)符

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

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

通過未加密的連接發(fā)送數(shù)據(jù)

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

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

鎖定，超時(shí)，等等

最后，我們?cè)诒疚闹幸呀?jīng)討論了ASP.net Core Identity。但我想再次指出的是，良好的習(xí)慣對(duì)這有多大的影響。我們來看看通常放置在您的Configure Services方法中的Identity的設(shè)置。

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; });

看看你在這里的選項(xiàng)。有很好的密碼執(zhí)行選項(xiàng)（盡管你可以提出一些論點(diǎn)：但不要過分要求像字母數(shù)字這樣的東西，因?yàn)槿藗儍A向于把它們寫在紙上...），如果他們鎖定用戶帳戶不斷輸入錯(cuò)誤的密碼，甚至需要電子郵件確認(rèn)（這也是身份框架的一部分）。

而在cookies如何存儲(chǔ)在用戶機(jī)器上，我們有這些選項(xiàng)：

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

又一次很棒的實(shí)踐。用戶cookie在默認(rèn)情況下應(yīng)該總是有一個(gè)過期值。一個(gè)來自O(shè)WASP的例子甚至明確指出了在攻擊的例子中公共計(jì)算機(jī)session超時(shí)的問題:

在此基礎(chǔ)上，我們應(yīng)該盡可能使用HttpOnly cookie。當(dāng)一個(gè)cookie被設(shè)置為HttpOnly時(shí)，這意味著它不能通過Javascript訪問（因此，可能存在XSS漏洞），并且只能在作為請(qǐng)求的一部分發(fā)送時(shí)才能被訪問。

我之所以使用這些例子，是因?yàn)樗鼈兪窃谶M(jìn)行身份驗(yàn)證和session管理時(shí)最佳實(shí)踐指南。即使您決定自己動(dòng)手，您也應(yīng)該調(diào)查Identity給您的是什么，這樣您就可以復(fù)制一些或所有的功能，并且始終保持對(duì)框架最新的的改進(jìn)。

總結(jié)

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

相關(guān)文章：

• ASP.NET Core中的OWASP Top 10 十大風(fēng)險(xiǎn)-SQL注入
  

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

---

.NET社區(qū)新聞，深度好文，歡迎訪問公眾號(hào)文章匯總 http://www.csharpkit.com

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。