一个适合.NET Core的代码安全分析工具 - Security Code Scan

时间:2024-03-02 21:48:52

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