NET Core的代码安全分析工具

NET Core的代码安全分析工具 - Security Code Scan

https://www.cnblogs.com/edisonchou/p/edc_security_code_scan_simple_introduction.html

一个适合.NET Core的代码安全分析工具 - Security Code Scan
　　本文主要翻译自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内容安全策略》