自2019年9月23日起，我們將對(duì)公共Stack Overflow，Team Stack Stack for Teams和Stack Overflow Enterprise背后的某些代碼進(jìn)行靜態(tài)分析，以搶先查找和消除某些類型的漏洞。我們?nèi)绾巫龅竭@一點(diǎn)是一個(gè)有趣的故事，也說明了.NET開源社區(qū)的進(jìn)步。但首先…

在進(jìn)行靜態(tài)分析之前，我們有什么？

堆棧溢出代碼庫已經(jīng)持續(xù)開發(fā)了大約十年，從ASP.NET MVC Preview 2開始一直。隨著.NET的發(fā)展，我們采用了鼓勵(lì)安全實(shí)踐的工具，例如Razor（默認(rèn)情況下是對(duì)字符串進(jìn)行編碼，以幫助防止跨站點(diǎn)腳本漏洞）。我們還創(chuàng)建了鼓勵(lì)使用Right Way?做事的新工具，例如Dapper，它可以自動(dòng)處理參數(shù)化SQL，同時(shí)仍然是性能卓越的（精簡(jiǎn)版）ORM。

我們代碼庫中不完整但說明性的默認(rèn)安全模式列表：

• 使用Dapper自動(dòng)進(jìn)行SQL參數(shù)化

• 使用Razor的視圖中的默認(rèn)編碼字符串

• 默認(rèn)情況下，對(duì)于非等冪（即POST，PUT，DELETE等）路由，需要跨站點(diǎn)請(qǐng)求偽造（XSRF）令牌

• 具有默認(rèn)到期時(shí)間和通用驗(yàn)證碼的HMAC

• 采用TypeScript（一個(gè)持續(xù)的過程），可以提高我們對(duì)發(fā)布正確的JavaScript的信心

• 針對(duì)團(tuán)隊(duì)和企業(yè)的私有數(shù)據(jù)位于具有獨(dú)立訪問控制的獨(dú)立基礎(chǔ)架構(gòu)上

至少從理論上講，我們不受大多數(shù)類型的注入和跨站點(diǎn)腳本攻擊的影響。

靜態(tài)分析給了我們什么？

在很大程度上，我們有信心始終如一地遵循我們預(yù)先建立的最佳實(shí)踐。即使我們的工程師很有才華并且我們的工具易于使用，但我們還是有數(shù)十個(gè)人從事Stack Overflow的工作已有10多年了，不可避免地，一些錯(cuò)誤會(huì)滲入代碼庫中。因此，大多數(shù)修補(bǔ)程序只是在做“正確的方式”而做的很少。諸如“使用我們的路線注冊(cè)屬性代替[HttpPost] ”或“刪除SHA1的舊用法并切換到SHA256”之類的事情。

更加“令人興奮”的修復(fù)程序需要引入新模式并更新舊代碼以使用它們。盡管我們沒有證據(jù)表明其中的任何一個(gè)已被利用，甚至在實(shí)踐中都可以被利用，但我們認(rèn)為最好還是謹(jǐn)慎行事，并加以解決。作為采用靜態(tài)代碼分析的一部分，我們添加了三種新模式：

我們用System.Security.Cryptography.RandomNumberGenerator支持的等效接口替換了System.Random的使用。很難證明隨機(jī)數(shù)是可預(yù)測(cè)的還是不安全的，因此我們對(duì)始終難以預(yù)測(cè)的標(biāo)準(zhǔn)進(jìn)行了標(biāo)準(zhǔn)化。現(xiàn)在，我們默認(rèn)情況下禁止HTTP重定向到我們無法控制的域，要求所有異常都明確記錄在案。這里的問題是

開放重定向，可用于網(wǎng)絡(luò)釣魚或其他惡意目的。我們大多數(shù)重定向都已經(jīng)適當(dāng)?shù)仳?yàn)證了這一點(diǎn)，但是檢查分散在整個(gè)代碼庫中。有一些丟失或錯(cuò)誤的檢查，但我們沒有發(fā)現(xiàn)它們被利用的證據(jù)。

我們加強(qiáng)了XSRF檢查，以解決用戶在未認(rèn)證狀態(tài)和已認(rèn)證狀態(tài)之間移動(dòng)的情況。我們的XSRF檢查以前假設(shè)存在與用戶身份相關(guān)的單個(gè)令牌。由于此過程在身份驗(yàn)證期間發(fā)生了變化，因此我們的某些代碼抑制了此檢查，并依賴于其他驗(yàn)證（例如，完成OAuth流）。即使所有案例確實(shí)都有某種XSRF預(yù)防措施，但選擇退出我們的默認(rèn)XSRF檢查代碼還是有風(fēng)險(xiǎn)的。因此，我們決定改進(jìn)檢查以處理這種情況。我們的解決方法是允許在某些路由上短暫地接受兩個(gè)令牌。 

我們的檢查會(huì)針對(duì)每個(gè)Stack Overflow的PR進(jìn)行檢查，此外（明確地）針對(duì)每個(gè)Enterprise版本進(jìn)行檢查-這意味著我們不僅有信心我們今天遵循的是最佳實(shí)踐，而且我們有信心在此過程中繼續(xù)遵循它們。未來。

我們?nèi)绾翁砑屿o態(tài)代碼分析？

這很無聊，因?yàn)槲覀兯龅闹皇蔷帉懸粋€(gè)配置文件，并將PackageReference添加到SecurityCodeScan。

而已。Visual Studio會(huì)將其用作分析器（因此您會(huì)產(chǎn)生彎曲），而C＃編譯器將執(zhí)行相同的操作，從而根據(jù)需要獲取警告或錯(cuò)誤。

所有使之成為可能的開源東西都更加有趣：

• 2014年，Microsoft開源了Roslyn，他們的C＃和VB.NET編譯器。

• Visual Studio 2015附帶了Roslyn分析儀的支持。

• 安全代碼掃描的作者于2016年開始工作。

• 我做出了一些 小 改動(dòng)，以適應(yīng)2019年的Stack Overflow特性。

如果您在六年前告訴我，我們能夠免費(fèi)，免費(fèi)地以某種方式為Stack Overflow解決方案添加任何類型的代碼分析，并且可以回饋給更大的開發(fā)者社區(qū)，那么我就不會(huì)相信你 很高興看到“新微軟”行為如此直接地使我們受益，但是看到OSS社區(qū)因之而建立的東西就更重要了。

我們只是發(fā)貨了，這就引出了一個(gè)問題……

靜態(tài)代碼分析的下一步是什么？

安全性是一個(gè)持續(xù)的過程，無需您動(dòng)手或添加功能。因此，總會(huì)有更多工作要做和我們需要改進(jìn)的地方，靜態(tài)代碼分析也是如此。

就像我在一開始提到的那樣，我們僅分析Stack Overflow背后的一些代碼。更準(zhǔn)確地說，我們不是在分析視圖或通過過程間調(diào)用進(jìn)行跟蹤，而對(duì)兩者進(jìn)行分析顯然是下一步。

一旦完成向ASP.NET Core的遷移，我們就可以開始分析視圖。核心Razor之前的視圖編譯無法為我們提供添加任何分析器的簡(jiǎn)便方法，但是應(yīng)該升級(jí)后變得微不足道。Razor的默認(rèn)行為使我們對(duì)注入式攻擊有了一定的信心，并且視圖通常不會(huì)做任何令人恐懼的事情-但將來有更強(qiáng)的正確性保證會(huì)很好。

不通過過程間調(diào)用進(jìn)行跟蹤會(huì)更加復(fù)雜。從技術(shù)上講，這是安全代碼掃描的限制，因?yàn)榇嬖谝粋€(gè)問題。由于我們幾乎總是將用戶提供的數(shù)據(jù)傳遞到視圖中，因此我們無法分析視圖降低了今天的過程間分析的價(jià)值?，F(xiàn)在，我們可以輕松地專注于我們的控制器動(dòng)作方法，因?yàn)榛旧纤杏脩籼峁┑臄?shù)據(jù)都會(huì)在進(jìn)入視圖或其他過程間調(diào)用之前通過它們。

開源的魅力在于，當(dāng)我們回來做這些下一步（以及其他生活質(zhì)量的變化）時(shí)，我們將使它們對(duì)社區(qū)可用，從而使每個(gè)人都受益。能夠同時(shí)使我們自己，我們的客戶和世界各地的.NET開發(fā)人員受益，這是一件很棒的事情。