本文主要翻譯自Security Code Scan的官方Github文檔，結合自己的初步使用簡單介紹一下這款工具，大家可以結合自己團隊的情況參考使用。此外，對.NET Core開發團隊來說，可以參考張隊的《.NET Core 必備安全措施》看看可以使用哪些方法提高我們.NET Core應用程序的安全性，此文也算是對張隊的那篇文章的一個補充。此外，本文不會介紹常見的Web攻擊及其場景，有興趣的園友可以讀讀參考書《白帽子講Web安全》一書。
一、Why SCS？
最近公司官網被Google拉入了安全黑名單，我們被迫把安全性的優先級提高了，先是啟用HTTPS，然后是安全掃描，最后漏洞修復。以前做內部系統時往往不會很在意安全問題，現在經歷了這么一波后印象深刻了。我們希望找尋一款工具，能夠在代碼開發階段就能夠分析出我們得代碼存在的風險（至少是常見的風險，比如XSS、CSRF等），讓開發人員第一時間能夠知道並選擇性地進行改正。
在Visual Studio Marketplace上，我們發現了一款工具：Security Code Scan，以下簡稱SCS，它是一款開源的代碼安全分析工具，其Github地址為：https://github.com/security-code-scan/security-code-scan，目前Star數量只有150+，但作者一直在維護，我們可以選擇性使用。當然，有機會我們也可以為其提Issue甚至PR。
SCS能夠檢測的安全問題有哪些？
（1）SQL注入
（2）XSS跨站點攻擊
（3）CSRF跨站點請求偽造攻擊
（4）XXE（XML External Entity Injection）XML外部實體注入攻擊
（5）......
SCS能夠支持哪些項目類型？
當然是我們喜歡的.NET 和 .NET Core項目啦！
SCS能夠支持CI嗎？
可以，通過MSBuild完美實現，后續會有介紹。
SCS支持哪些Visual Studio版本？
Visual Studio 2015及以上版本均支持，包括社區版、專業版和企業版。
二、SCS的安裝與基本使用
2.1 SCS的安裝
目前，SCS支持兩種方式的安裝：
（1）VS擴展插件
（2）Nuget包
目前最新版本為3.0.0，2018年12月4日更新。
推薦使用Nuget包方式使用，因為CI也會依賴該Nuget包。
2.2 SCS的使用
為了演示SCS的使用，這里我們使用一個SCS在官方文檔中准備好的一個故意留有安全問題的ASP.NET 項目（不是ASP.NET Core）叫做WebGoat.NET來初步使用一下。下載完成后，發現該示例項目是一個VS2010的項目，於是將其升級到.NET Framework 4.6.1並使用VS2017打開，最后效果如下圖所示：
WebGoal.NET項目結構
第一步，當然是通過Nuget管理器引入SCS的包啦：
PS：VS2017的話選擇SecurityCodeScan.VS2017版本，VS2015的話直接選擇SecurityCodeScan。
第二步，確保錯誤列表窗口的選項是生成+IntelliSense：
第三步，編譯該項目，查看錯誤列表Tab的警告信息：
當然，我們也可以將安全警告信息篩選出來，它們都是以SCS開頭的規則：
第四步，點開其中一個安全問題，比如SCS0008，看看是什么提示信息：
原來是說Cookie缺少了Secure標記，推薦我們在設置新Cookie時都加上Secure標記。至於為什么要加上Secure標記，這個是OWASP推薦的一個最佳實踐，你可以通過這篇《SecureFlag》來了解了解。大概意思就是：如果一個cookie被設置了Secure=true，那么這個cookie只能用https協議發送給服務器，用http協議是不發送的。換句話說，cookie是在https的情況下創建的，而且他的Secure=true，那么之后你一直用https訪問其他的頁面（比如登錄之后點擊其他子頁面），cookie會被發送到服務器，你無需重新登錄就可以跳轉到其他頁面。但是如果這是你把url改成http協議訪問其他頁面，你就需要重新登錄了，因為這個cookie不能在http協議中發送。從另一個側面來看，整站HTTPS的必要性也得以體現。
一個設置了Secure屬性的C#代碼示例：
HttpCookie cookie = new HttpCookie("UID"); cookie.Path = "/"; cookie.Value = loginId.ToLower(); cookie.Expires = DateTime.Now.AddDays(1); cookie.Secure = true; Response.Cookies.Add(cookie);
因此，這里我們可以定位到有漏洞問題的代碼行，為其添加Secure=true，再次編譯后，這一條SCS0008的警告就已經不再了。當然，你為此得付出的工作卻沒有結束，你還需要為系統配置Https證書和端口等等。
下一步？繼續查看SCS給出的安全警告，選擇性地進行修復，迭代反復。
三、SCS的規則集設置
和StyleCop.Analyzers之類的代碼風格分析器一樣，SCS也可以設置其規則集，對我們來說最有用的就是可以統一設置其嚴重性級別（比如：警告、信息還是錯誤）。怎么做呢？看下面的介紹。
在分析器上選擇“打開活動規則集”：
在分析器規則集列表中定位到“SecurityCodeScan”中，可以看到SCS開頭的一系列規則集，這里假設我們為SCS0008這條規則的嚴重性設置為錯誤：
保存后再次進行編譯，可以看到，SCS0008已經是一個錯誤信息，編譯不通過了：
通過改變安全規則的嚴重性，我們可以在開發階段確保團隊注意安全性，前提是要篩選出來哪些規則你要設置為錯誤，哪些規則你要設置為警告或信息等不影響編譯的級別。
更多的規則想要了解？點擊這里，你想要了解的都在這里：
四、SCS與CI的集成
前面提到可以修改規則嚴重性來影響編譯，那么在CI持續集成中，我們如果使用MSBuild，那么作為Nuget包的SCS可以直接影響CI過程中的編譯。
五、ASP.NET Core中的安全
這里參考張隊的《.NET Core 必備安全措施》一文中的部分內容：
在ASP.NET Core 2.1中，默認會讓你啟用HTTPS，而在2.0中，默認是不啟用的。
對於CSRF攻擊，ASP.NET Core使用 ASP.NET Core data protection stack 來實現防請求偽造。默認情況下處於啟用狀態，CSRF令牌將自動添加為隱藏輸入字段。
對於XSS攻擊，可以使用內容安全策略（CSP），它是一個增加的安全層，可幫助緩解XSS（跨站點腳本）和數據注入攻擊。實現上主要是在header里加了Content-Security-Policy的安全策略，ASP.NET Core中的代碼參考如柳隨風的這篇《ASP.NET Core2中使用CSP內容安全策略》。
對於微服務應用架構，我們默認會借助IdentityServer4實現標准的OIDC進行身份驗證，則無需擔心如何存儲用戶、密碼或對用戶進行身份驗證。
.......
參考資料
（1）Security Code Scan，GitHub文檔
（2）張善友，《.NET Core 必備安全措施》
（3）Forwill，《Cookie的Secure屬性》
（4）如柳隨風，《ASP.NET Core2中使用CSP內容安全策略》
推薦閱讀
吳翰清，《白帽子講Web安全》