将静态代码分析添加到Stack Overflow

自2019年9月23日起，我们将对公共Stack Overflow，Team Stack Stack for Teams和Stack Overflow Enterprise背后的某些代码进行静态分析，以抢先查找和消除某些类型的漏洞。我们如何做到这一点是一个有趣的故事，也说明了.NET开源社区的进步。但首先…

在进行静态分析之前，我们有什么？

堆栈溢出代码库已经持续开发了大约十年，从ASP.NET MVC Preview 2开始一直。随着.NET的发展，我们采用了鼓励安全实践的工具，例如Razor（默认情况下是对字符串进行编码，以帮助防止跨站点脚本漏洞）。我们还创建了鼓励使用Right Way™做事的新工具，例如Dapper，它可以自动处理参数化SQL，同时仍然是性能卓越的（精简版）ORM。

我们代码库中不完整但说明性的默认安全模式列表：

• 使用Dapper自动进行SQL参数化

• 使用Razor的视图中的默认编码字符串

• 默认情况下，对于非等幂（即POST，PUT，DELETE等）路由，需要跨站点请求伪造（XSRF）令牌

• 具有默认到期时间和通用验证码的HMAC

• 采用TypeScript（一个持续的过程），可以提高我们对发布正确的JavaScript的信心

• 针对团队和企业的私有数据位于具有独立访问控制的独立基础架构上

至少从理论上讲，我们不受大多数类型的注入和跨站点脚本攻击的影响。

静态分析给了我们什么？

在很大程度上，我们有信心始终如一地遵循我们预先建立的最佳实践。即使我们的工程师很有才华并且我们的工具易于使用，但我们还是有数十个人从事Stack Overflow的工作已有10多年了，不可避免地，一些错误会渗入代码库中。因此，大多数修补程序只是在做“正确的方式”而做的很少。诸如“使用我们的路线注册属性代替[HttpPost] ”或“删除SHA1的旧用法并切换到SHA256”之类的事情。

更加“令人兴奋”的修复程序需要引入新模式并更新旧代码以使用它们。尽管我们没有证据表明其中的任何一个已被利用，甚至在实践中都可以被利用，但我们认为最好还是谨慎行事，并加以解决。作为采用静态代码分析的一部分，我们添加了三种新模式：

我们用System.Security.Cryptography.RandomNumberGenerator支持的等效接口替换了System.Random的使用。很难证明随机数是可预测的还是不安全的，因此我们对始终难以预测的标准进行了标准化。现在，我们默认情况下禁止HTTP重定向到我们无法控制的域，要求所有异常都明确记录在案。这里的问题是

开放重定向，可用于网络钓鱼或其他恶意目的。我们大多数重定向都已经适当地验证了这一点，但是检查分散在整个代码库中。有一些丢失或错误的检查，但我们没有发现它们被利用的证据。

我们加强了XSRF检查，以解决用户在未认证状态和已认证状态之间移动的情况。我们的XSRF检查以前假设存在与用户身份相关的单个令牌。由于此过程在身份验证期间发生了变化，因此我们的某些代码抑制了此检查，并依赖于其他验证（例如，完成OAuth流）。即使所有案例确实都有某种XSRF预防措施，但选择退出我们的默认XSRF检查代码还是有风险的。因此，我们决定改进检查以处理这种情况。我们的解决方法是允许在某些路由上短暂地接受两个令牌。 

我们的检查会针对每个Stack Overflow的PR进行检查，此外（明确地）针对每个Enterprise版本进行检查-这意味着我们不仅有信心我们今天遵循的是最佳实践，而且我们有信心在此过程中继续遵循它们。未来。

我们如何添加静态代码分析？

这很无聊，因为我们所做的只是编写一个配置文件，并将PackageReference添加到SecurityCodeScan。

而已。Visual Studio会将其用作分析器（因此您会产生弯曲），而C＃编译器将执行相同的操作，从而根据需要获取警告或错误。

所有使之成为可能的开源东西都更加有趣：

• 2014年，Microsoft开源了Roslyn，他们的C＃和VB.NET编译器。

• Visual Studio 2015附带了Roslyn分析仪的支持。

• 安全代码扫描的作者于2016年开始工作。

• 我做出了一些 小 改动，以适应2019年的Stack Overflow特性。

如果您在六年前告诉我，我们能够免费，免费地以某种方式为Stack Overflow解决方案添加任何类型的代码分析，并且可以回馈给更大的开发者社区，那么我就不会相信你 很高兴看到“新微软”行为如此直接地使我们受益，但是看到OSS社区因之而建立的东西就更重要了。

我们只是发货了，这就引出了一个问题……

静态代码分析的下一步是什么？

安全性是一个持续的过程，无需您动手或添加功能。因此，总会有更多工作要做和我们需要改进的地方，静态代码分析也是如此。

就像我在一开始提到的那样，我们仅分析Stack Overflow背后的一些代码。更准确地说，我们不是在分析视图或通过过程间调用进行跟踪，而对两者进行分析显然是下一步。

一旦完成向ASP.NET Core的迁移，我们就可以开始分析视图。核心Razor之前的视图编译无法为我们提供添加任何分析器的简便方法，但是应该升级后变得微不足道。Razor的默认行为使我们对注入式攻击有了一定的信心，并且视图通常不会做任何令人恐惧的事情-但将来有更强的正确性保证会很好。

不通过过程间调用进行跟踪会更加复杂。从技术上讲，这是安全代码扫描的限制，因为存在一个问题。由于我们几乎总是将用户提供的数据传递到视图中，因此我们无法分析视图降低了今天的过程间分析的价值。现在，我们可以轻松地专注于我们的控制器动作方法，因为基本上所有用户提供的数据都会在进入视图或其他过程间调用之前通过它们。

开源的魅力在于，当我们回来做这些下一步（以及其他生活质量的变化）时，我们将使它们对社区可用，从而使每个人都受益。能够同时使我们自己，我们的客户和世界各地的.NET开发人员受益，这是一件很棒的事情。