本文主要翻译自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内容安全策略》