十一、安全的应用生命周期管理

到目前为止，我已经花了整本书的大部分时间来讨论可以用来帮助确保应用安全的特定编程和配置技术。现在是时候讨论如何验证您的应用实际上是安全的了。让我们从解决一件事情开始:事后增加安全性从来都不会有好结果。在上线之前立即开始安全检查“只是为了确保万无一失”，这将确保您没有足够的时间来修复最严重的问题，并且在进行任何研究之前就上线意味着您客户的信息处于风险之中。举个最近的例子，Disney+上线几小时后就被黑了。 1

表 11-1

基于引入点的错误修复时间(来自 NIST)

|   |

找到阶段

| | --- | --- | |

阶段介绍

|

要求

|

编码/单元测试

|

综合

|

Beta 测试

|

产品发布后

| | --- | --- | --- | --- | --- | --- | | 要求 | One point two | Eight point eight | Fourteen point eight | Fifteen | Eighteen point seven | | 编码/单元测试 | 不适用的 | Three point two | Nine point seven | Twelve point two | Fourteen point eight | | 综合 | 不适用的 | 不适用的 | Six point seven | Twelve | Seventeen point three |

似乎这还不够，一旦 bug 进入生产阶段，修复起来就更加昂贵了。为了证明这一点，表 11-1 显示了 NIST 根据引入时间修复一个错误的时间表。 2

显然，在过程的早期修复 bug 要比后期修复更容易。在编写代码时改进安全性实践是加速开发的必要步骤，并且可以让您专注于用户喜欢的特性。阅读这本书，从而了解安全方面的最佳实践，是一个很好的开始！但是您还需要验证您做得(或做得不好),所以让我们来探索一下安全专业人员都做些什么。

测试工具

绝大多数安全评估都是从安全专家针对您的网站运行各种工具开始的。有时工具会返回特定的发现，有时工具会返回可疑的响应，渗透测试人员会使用这些响应进行更深入的挖掘。您已经在我们对 Burp Suite 进行的各种测试中提到了这一点。但是因为寻找可疑的结果和深入挖掘不是你能经常做的事情，所以让我们把重点放在可重复和自动化的测试类型上。以下是目前可用的测试工具类型列表:

  • 动态应用安全测试(【DAST】):这些扫描器攻击您的网站，使用相对良性的有效载荷，以便找到常见的漏洞。

  • 静态应用安全测试(【SAST】):这些扫描器分析你网站的源代码，寻找常见的安全漏洞。

  • 源组件分析( SCA ) :这些扫描器会比较您网站组件的版本号(例如特定的 JavaScript 库或 NuGet 包)，并将该列表与已知的易受攻击组件列表进行比较，以便找到您应该升级的软件。

  • 交互式应用安全测试(*)*:这些扫描器在代码运行时监控代码的执行，寻找各种漏洞。

**有一个由其他类型的工具组成的大型生态系统，这些工具也可以检测网站中的安全问题，其中大多数都是针对网站周围的服务器、主机或网络的。由于这本书主要面向开发人员，所以我将把重点放在最有助于发现由网站源代码中的问题引起的 bug 的工具上。

DAST 工具

DAST 工具会自动攻击你的网站，虽然没有人工渗透测试有效。DAST 扫描仪的第一步通常被称为被动扫描，它打开你的网站，登录(如果合适的话)，点击所有链接，提交所有表格，等等。，它找到这些信息是为了确定你的网站有多大。然后，它通过表单、URL 和 API 调用发送各种(大部分是良性的)有效载荷，寻找表明攻击成功的响应。这个步骤被称为主动扫描。

这种方法意味着绝大多数 DAST 扫描器是语言不可知的——这意味着除了少数例外，如识别 CSRF 令牌或会话 cookies，它们将同样有效地扫描用大多数语言构建的网站。这也意味着任何特定于语言的漏洞可能不包括在扫描中。

让我们来看几个典型的 DAST 扫描器可能会发送到您的网站以试图找到漏洞的有效负载示例:

  • 以评论形式发送<script>alert([random number])</script>。如果稍后在扫描中用该随机数弹出警报，则网站中可能存在 XSS 漏洞。

  • 发送' WAITFOR DELAY '00:00:15' --以查看页面处理中是否出现 15 秒的延迟。如果是这样，那么网站的某个地方存在 SQL 注入漏洞。

  • 尝试更改任何 XML 请求以包含已知的第三方 URL。如果该 URL 被命中，那么该特定端点几乎肯定容易受到 XXE 攻击。

扫描器会经历数十或数百种变化，试图解释网站中可能出现的各种情况。例如，如果您的 XSS 漏洞存在于 HTML 标记属性中，而不是标记的文本中，onmouseover="alert([random number])将比前面的示例更有可能成功。要了解原因，清单 11-1 显示了攻击，用户的输入用斜体显示。

<input type="text" value="onmouseover="alert([number])"/>

Listing 11-1XSS attack within an HTML element attribute

更好的扫描器将考虑更多的变化，以发现更多的漏洞。

一旦你的扫描完成，任何 DAST 扫描仪将记录下它发现的任何漏洞，并为每个漏洞分配一个严重性(有多严重)。大多数扫描器还会给每个发现分配一个置信度(它实际上是一个问题的可能性有多大)。

在大多数情况下，对网站进行主动扫描是相对安全的，因为他们不会故意损坏你的网站或删除数据。不过，我强烈建议对您网站的测试版本运行 DAST 扫描，而不是生产版本，因为以下问题很常见:

  • 因为主动扫描会将这些攻击的数百种变体发送到您的网站，所以它会尝试提交表单数百次。如果您的网站在每次提交表单时都发送一封电子邮件(或执行一些其他操作)，您将会收到数百封电子邮件。

  • 如果您有一个容易受到 XSS 攻击的页面，并且扫描程序找到了它，那么每当您导航到该页面时，您都会收到数百个警报。

  • 扫描仪会提交每一份表格，甚至是密码更改表格。在运行扫描后，您可能会发现您的测试用户有了一个新密码(并且是您不知道的密码)。

  • 一些扫描仪为了尽快完成扫描，会猛烈攻击你的网站，每秒发送几十个请求。如果您的硬件不是特别强大，这种流量可以在 DoS 攻击中使您的网站瘫痪。

  • 除非另行配置，否则这些扫描器会不加选择地点击链接。如果有一个链接做了一些极端的事情，比如删除数据库中某种类型的所有记录，那么在扫描完成后，您可能会发现所有类型的数据都丢失了。

  • 在极端的情况下，DAST 扫描器可能会偶然发现一个问题，一旦被发现，就会导致整个网站瘫痪。我在扫描 WebGoat 的 ASP.NET web forms 版本时遇到了这个问题，web goat 是 OWASP 为培训目的而故意创建的易受攻击的网站。

如果您知道您的网站，您可以从扫描中排除发送电子邮件和删除项目的路径，但如果您对测试网站运行扫描，而没有对生产安全运行扫描所必需的限制，则会更安全，并且会获得更好的结果。

运行 DAST 扫描器的最后一个提示:确保关闭任何可能保护你网站的网络应用防火墙。大多数 DAST 扫描仪不会试图隐藏自己，所以对一个有 WAF 的网站运行 DAST 扫描基本上是测试你的 WAF 是否能检测到笨拙的攻击。相反，你应该想测试你的网站的安全性。

DAST 扫描仪的优势

DAST 扫描器不能发现所有的东西，但是它们善于发现可以通过一个请求/响应发现的错误。例如，他们通常很擅长寻找反射的 XSS，因为执行请求并在响应中寻找脚本相对容易。他们通常也善于发现大多数类型的 SQL 注入攻击，因为要求数据库延迟响应并比较延迟请求和非延迟请求的响应时间相对容易。你也可以期待任何体面的 DAST 扫描仪找到

  • 缺少和/或错误配置的标题和 cookies

  • 错误配置的 cookies

  • HTTPS 证书发行

  • 各种 HTML 问题，比如允许在密码文本框上自动完成

  • 查找未正确保护的文件路径的问题，例如文件读取操作可能被劫持以在屏幕上显示操作系统文件

DAST 扫描仪的弱点

我听到的关于 DAST 扫描仪的最大抱怨是它们产生了太多的“噪音”换句话说，大多数扫描仪会产生大量的误报、重复和不重要的发现，您可能永远也不会修复它们。当您在任何特定的报告中有如此多的干扰时，有时很难找到您真正想要修复的项目。(有一些扫描器宣称它们的误报率很低，但这些扫描器的误报率通常也很低，这意味着它们会错过其他扫描器会发现的许多真正的漏洞。)

最重要的是，DAST 扫描器通常不擅长发现需要多个步骤才能发现的漏洞。例如，优秀的扫描器通常不会发现存储的 XSS 和 SQL 注入漏洞。他们也不容易发现任何业务逻辑实现的缺陷，例如页面的认证和授权缺失或配置错误，隐藏字段中敏感信息的存储不当，或者错误处理上传的文件。由于 DAST 扫描仪无法访问您的源代码，您不能指望他们找到以下内容:

  • 加密问题，如算法实现不佳、使用不安全的算法或密钥存储不安全

  • 记录和监控不足

  • 使用具有已知漏洞的代码组件

DAST 扫描仪之间的差异

有各种各样的 DAST 扫描仪的网站有各种各样的价格。一些扫描仪是免费和开源的，其他一些扫描仪安装和运行一年需要五位数的费用。很容易看到像 Sec 工具市场 3 这样的在线比较，并认为大多数扫描仪都非常相似，尽管价格不等。他们不是。它们在扫描速度、结果质量、报告质量、与其他软件的集成等方面有很大不同。您的里程将因可用工具而异。

如果您刚刚开始使用 DAST 扫描，我强烈推荐您从 OWASP 的 Zed 攻击代理(ZAP)开始。ZAP 远不是最好的扫描仪，但它免费且易于使用，是运行 DAST 扫描的低成本入口。

一旦你习惯了 ZAP 的工作方式，我推荐你使用专业版的 Burp 套件进行扫描。 5 Burp 是 ZAP 的高级扫描仪，拥有数十个开源插件来扩展扫描仪的功能，并且价格非常合理(撰写本文时为 400 美元/年)。除非您有特定的报告需求，否则很难超越 Burp Suite 带来的纯扫描质量。

一旦您的流程成熟，并且您需要更强大的报告功能，您可以考虑使用更昂贵的扫描仪。然而，推销可能与实际产品质量不同。以下是一些需要注意的事项:

  • 大多数扫描器声称它们支持现代单页应用(SPA) JavaScript 框架，但是不同扫描器之间的实现质量差别很大。如果你有一个 SPA 网站，一定要在购买前测试扫描仪。

  • 认证支持因扫描仪而异。一些扫描仪只支持用户名和密码进行认证，一些扫描仪是高度可配置的，一些扫描仪说它们是高度可配置的，但大多数配置选项都不好用。我建议寻找允许你编写或记录你的登录的扫描仪，因为这是我发现的最可靠的登录方式。

  • 如前所述，一些扫描器明确地试图最小化误报，目的是确保你不会在扫描器的错误上浪费时间。但是以我的经验来看，能最小化误报的扫描仪有着高得令人无法接受的误报率。大多数扫描仪都有一定的灵活性——允许你在需要时进行快速扫描，也允许你在有时间时进行详细扫描。不过，一般来说，不要使用那些主要卖点是能够最大限度减少误报的扫描仪。

我的最后一条建议，当谈到 DAST 扫描仪是，你应该强烈考虑运行多个品牌的 DAST 扫描仪对您的网站。有些扫描器通常比其他扫描器好，但有些扫描器通常比其他扫描器更善于发现某些类型的问题。将一个擅长发现配置问题的扫描器与一个擅长发现代码注入的扫描器配对，是获得最佳结果的一种(相对)简单的方法。

萨斯特工具

SAST 扫描器通过查看您的源代码工作，而不是试图攻击您网站的运行版本。虽然这意味着 SAST 扫描仪通常更容易配置和运行，但这并不意味着 SAST 工具是特定于语言的。也许正因为如此，SAST 扫描仪的可用数量要少得多。NET 程序员比 DAST 扫描仪。此外，与 DAST 扫描仪不同，没有任何真正好的免费选项——所有好的 SAST 扫描仪都非常昂贵。

因为你可能预算有限，所以我先从免费扫描仪说起。正如我刚才提到的，这些不是最好的扫描仪，但总比没有好。扫描仪。NET 有两种不同的类型:在 Visual Studio 外部运行的类型和在 Visual Studio 内部运行的类型。那些在 Visual Studio 之外运行的工具为您提供了更好的报告功能，并允许更容易地管理补救问题(以防您不想立即修复所有问题)。在 Visual Studio 中运行的扫描器提供即时反馈，但是没有报告或错误跟踪功能。

我在 Visual Studio 之外用来分析源代码的两个扫描器包括

坦率地说，SonarQube 很难称得上是安全扫描仪。我知道很多公司用它来做安全扫描，但他们不应该。SonarQube 在发现代码可维护性问题方面的卓越能力值得考虑，但它往往会忽略任何扫描器都应该发现的明显的安全问题。

VisualCodeGrepper 在发现安全问题方面稍好一些，但总体上是一个不太完美的产品。不像 SonarQube 有一个相当完美的 UI，VisualCodeGrepper 只提供简单的导出。我个人不会依赖中的任何一个来发现安全问题，但偶尔使用其中一个或两个来检查你的应用的健全性几乎肯定是值得的。

如前所述，在 Visual Studio 中工作的扫描器更善于给出即时反馈，但是没有报告功能。以下是我用过的开源软件列表:

其中，我实际上喜欢 FxCop，Visual Studio 要求您安装的分析器，是三者中最不喜欢的。Puma 扫描和安全代码扫描都比 FxCop 更善于发现问题。然而，这三个都不令人印象深刻。但是考虑到安装和使用的工作量很小，您应该使用这三者之一来帮助您发现安全问题。

将 Visual Studio 扫描仪用作 SAST 扫描仪

鉴于 SonarQube 的安全质量如此之差，以及 VisualCodeGrepper 产品的不发达程度，如果您需要在构建过程中运行扫描，您可能希望使用 Visual Studio 中的一个扫描器作为外部扫描器。虽然不直接支持将这些扫描仪用作外部扫描仪，但您只需做一点点工作就可以做到。这些使用罗斯林，一个允许你使用 C# 加载和解释代码的框架。不幸的是，现在你必须使用一个. NET 框架项目来完成，并且你需要使用一个第三方库来分析核心代码。

首先，您需要从 NuGet 安装几个项目:

  • 构建分析器和构建分析器。工作空间:这些允许你解析。网内核心项目。NET 框架罗斯林解析器。

  • 微软。代码分析和微软。CodeAnalysis.Workspaces :这些允许您运行加载和解释项目代码的 Roslyn 解析器。

清单 11-2 显示了加载您想要分析的解决方案中所有项目的代码。

private static List<Project> GetProjects()
{
  var workspace = new AdhocWorkspace();
  var projects = new List<Project>();
  var solutionFilePath = PATH_TO_YOUR_SOLUTION_FILE;

  var manager = new AnalyzerManager(solutionFilePath);

  foreach (var key in manager.Projects.Keys)
  {
    var analyzer = manager.GetProject(manager.Projects[key].
      ProjectFile.Path);
    projects.Add(analyzer.AddToWorkspace(workspace));
  }

  return projects;
}

Listing 11-2Loading projects from a solution

AdhocWorkspace和Project是来自Microsoft.CodeAnalysis名称空间的对象。这是我们将使用分析库分析的Projects列表。如果您正在分析一个使用旧框架的项目，您可以直接使用这些类。但是因为我们正在分析使用新内核的项目，我们需要从Buildalyzer包中取出使用AnalyzerManager的项目。

代码的其余部分相当容易理解，所以让我们看看从扫描仪库中提取分析器的代码。

private static void LoadAnalyzersFromAssembly(
  List<DiagnosticAnalyzer> analyzers, Assembly assembly)
{
  foreach (var type in assembly.GetTypes())
  {
    if (type.GetCustomAttributes(
      typeof(DiagnosticAnalyzerAttribute), false).Length > 0)
    {
      var attribute = (DiagnosticAnalyzerAttribute)type.↲
        GetCustomAttribute(↲
          typeof(DiagnosticAnalyzerAttribute));

      if (attribute.Languages.Contains("C#"))
        analyzers.Add(↲
          (DiagnosticAnalyzer)Activator.CreateInstance(type));
    }
  }
}

Listing 11-3Pulling analyzers from the code library

如果你了解反射，列出 11-3 非常简单。我们加载程序集中的所有类，并查看哪些类具有DiagnosticAnalyzer属性。我们为每个类创建一个实例，并将List返回给调用代码。

接下来，我们需要得到调查结果本身。

protected static List<Diagnostic> GetFindings(
  ImmutableArray<DiagnosticAnalyzer> analyzers,
  List<Project> projects)
{
  var cancellationToken = default(CancellationToken);

  var diagnostics = new List<Diagnostic>();
  foreach (var project in projects)
  {
    var compilation = project.GetCompilationAsync(↲
      cancellationToken).Result;

    var compilerErrors = compilation.GetDiagnostics().
      Where(i => i.Severity == DiagnosticSeverity.Error);

    if (compilerErrors.Count() == 1 &&
      compilerErrors.Single().Id == "CS5001")
    {
        compilation = compilation.↲
          WithOptions(new CSharpCompilationOptions(↲
            OutputKind.DynamicallyLinkedLibrary));
    }

    var compilationWithAnalyzers =
      compilation.WithAnalyzers(analyzers);

    compilationWithAnalyzers.GetAnalyzerDiagnosticsAsync().
      Result;
    var diagnosticResults = compilationWithAnalyzers.
      GetAllDiagnosticsAsync().Result;

    foreach (var diag in diagnosticResults)
    {
      if (diag.Location == Location.None ||
        diag.Location.IsInMetadata)
      {
        diagnostics.Add(diag);
      }
      else
      {
        foreach (var document in project.Documents)
        {
          var tree = document.GetSyntaxTreeAsync(↲
            cancellationToken).Result;
          if (tree == diag.Location.SourceTree)
          {
            diagnostics.Add(diag);
          }
        }
      }
    }
  }

  return diagnostics;
}

Listing 11-4Code to pull DiagnosticAnalyzer findings from projects

清单 11-4 的完整解释超出了本书的范围，因为完整解释需要对罗斯林有所了解。不过，有几件事值得强调:

  • 如果我们试图分析一个不打算直接执行的 DLL，编译器会抛出一个错误，所以我们需要检查具体的错误(CS5001)，如果存在，就用“DynamicallyLinkedLibrary”集合的输出类型重新编译。

  • 编译对象已经知道如何使用我们的分析器，所以我们只需要通过调用compilation.WithAnalyzers方法让我们的复杂对象知道我们正在使用的分析器。

  • foreach方法寻找错误的来源，如果它是可操作的，我们确保它被添加到我们要返回的错误列表中。

一旦您有了Diagnostic对象的列表，您就可以通过在您的 bug 跟踪系统中创建 bug、创建仪表板或者两者都创建来解析结果。

关于免费 SAST 扫描仪的最后说明

虽然这些不同的扫描仪的有效性存在一些差异，但还是出现了一些模式:

  • 没有一个扫描器直接查看 cshtml 页面，只有一个扫描器(VisualCodeGrepper)间接查看它们。因此，大多数扫描仪将无法找到绝大多数 XSS 问题。

  • 扫描器始终一次评估一行代码，这意味着如果用户输入在一行中被添加到 SQL 查询，但在另一行中被无保护地发送到数据库，扫描器不会发现漏洞。

  • 扫描器通常非常“愚蠢”，这意味着它们要么标记出漏洞的所有可能实例(例如将没有[Authorize]属性的每个方法标记为缺乏保护，尽管您几乎总是希望一些页面能够被未经认证的用户访问)，要么全部忽略它们。

但是，任何帮助都比没有帮助好，所以您应该考虑使用其中的一个或多个，尤其是如果您可以在 Visual Studio 中直接获得反馈。

商用 SAST 扫描仪质量

商业 SAST 扫描仪，如 Checkmarx 和 Fortify，比这里提到的要好得多。除了大多数商业扫描器比免费扫描器更具可配置性，因此能够更好地发现应用的问题，这些扫描器足够智能，能够理解简单的上下文(就像我前面提到的独立的 SQL 查询创建和调用)。不幸的是，它们也非常昂贵。但是如果你买得起，它们非常值得评估，然后根据你的需要买一个最好的。

SCA 工具

许多 DAST 和 SAST 扫描仪不会检查您网站中包含的易受攻击的库。例如，如果在您最喜欢的 JavaScript 框架中发现了一个漏洞，您通常需要自己去寻找过时和不安全的组件。SCA 工具旨在为您填补这一空白。这些工具要么有自己的漏洞数据库，要么实时检查国家漏洞数据库和其他类似的数据库，然后将您网站中的组件名称和版本与已知的坏组件列表进行比较。如果有匹配的，会通知你。

虽然 OWASP 依赖检查 6 做得很好并且是免费的，但是有几个免费的和商业的选项供你选择。

Caution

鲜为人知的组件中的大量漏洞永远不会出现在这些漏洞数据库中，因为安全研究人员根本不关注它们。组件经理经常在没有明确说明的情况下修复漏洞。虽然使用 SCA 工具来检查已知的坏组件是一个好主意，但是不要认为一个组件通过了 SCA 检查就是安全的。不管是否存在已知的安全问题，保持库的更新几乎总是一个好主意。

记住，攻击者也可以访问这些数据库。如果组件扫描确实发现了不安全的组件，尽快更新不安全的组件非常重要。如果您不使用具有漏洞的特定功能，也是如此。一旦组件被识别为易受攻击，您可能会错过对该组件中易受攻击功能列表的任何更新。如果您确实使用的某个特性稍后出现，并且您确实错过了它，您将为攻击者打开一扇门。

IAST 工具

如前所述，IAST 工具结合了源代码分析和动态测试。这些扫描器的工作方式是在服务器和/或网站上安装服务，配置服务，然后浏览网站(手动或通过脚本)。你不需要像 DAST 工具那样攻击网站——IAST 工具查看代码是如何执行的，并根据它看到的内容确定漏洞。

一方面，这似乎是两个世界中最糟糕的，因为它需要特定语言的监控，但需要运行应用来测试。不过，另一方面，它可能是两全其美的，因为您可以像 SAST 工具一样修复特定的代码行，但扫描器必须像 DAST 工具一样减少对实际漏洞的猜测。

IAST 扫描器的一个局限性非常值得一提——因为它们通过查看服务器上的代码是如何被处理来发现漏洞的，JavaScript 中的问题不会被发现。这是一个非常大的问题，因为随着单页应用(SPA)框架的使用激增，越来越多的网站逻辑可以在 JavaScript 中找到，而不是在服务器端代码中。看看有没有 IAST 的供应商能找到解决这个问题的方法，这将会很有趣。

IAST 仍然是一个相对较新的概念，这意味着

  • 这些扫描仪没有 DAST 和 SAST 的成熟。

  • 有更少的选择(包括免费的和商业的)。

  • 这些工具不像其他类型的扫描仪那样常用。

但是随着这些工具越来越广为人知，随着它们的进一步发展，它们将会产生更好的结果。我建议尽快熟悉它们。

Caution

我再怎么强调也不为过，这些工具——DAST、SAST、SCA、IAST 或这些工具的任何组合——都无法找到任何接近您所有漏洞的东西。我遇到太多的人说“[工具]验证了我没有漏洞。”如果你依靠这些工具找到所有的东西，你就会被攻破。这些工具只会找到你容易找到的项目。

Kali Linux

Kali Linux 本身并不是一种测试工具或一个独立的工具，相反，它是一个预装了数百个免费开源安全工具的 Linux 发行版。除了扫描 web 应用的工具，Kali 还包括无线破解工具、报告工具、漏洞利用工具等。实际上，我建议你不要使用 Kali，原因很简单，对于你实际使用的每一个工具，Kali 都提供了几十个你不会使用的工具。简单地安装你使用的工具会更容易，但是你的收获可能会有所不同。

将工具集成到您的 CI/CD 流程中

随着越来越多的开发人员和开发团队寻求自动化他们的发布，想要自动化安全测试是很自然的。大多数安全工具相对容易自动化，有些甚至宣传将这些工具集成到您的持续集成/持续部署(CI/CD)管道中是多么容易。但是自动化安全测试需要一些深谋远虑，因为尽管大肆宣传，它们不会像宣传的那样集成到您的过程中。

在我开始之前，让我们回顾一下大多数开发人员和经理在希望将安全工具集成到 CI/CD 流程中时的要求:

  1. 开发人员签入代码。

  2. 自动构建开始运行。

  3. 无论是在构建期间还是之后，都会立即运行 SAST 和 SCA 扫描。

    1. 如果发现任何高于特定严重性的漏洞，那么构建就会停止，在您的工作跟踪系统中创建一个 bug，并通知负责创建该漏洞的开发人员。

  4. 构建完成后，代码会自动部署到测试环境中。

  5. 自动启动针对测试环境运行的 DAST 扫描程序。

    1. 如果发现了某一严重程度或更严重程度的安全漏洞，则流程停止，创建一个 bug，并通知开发人员。

  6. 在所有问题解决之前，构建将被阻止。

自动化您的 SCA 扫描程序将会相对容易且相对无痛。我强烈推荐在每次构建后运行一次，如前所述。然而，由于这些类型的安全扫描器固有的局限性，要让这种方法在其他类型的扫描器上照原样工作，将比仅仅建立过程要花费更多的工作。我们来深究一下原因。

带 DAST 扫描仪的 CI/CD

以自动方式运行 DAST 扫描有几个挑战。

首先，好的 DAST 扫描需要时间。我的经验是，用好的扫描仪对一个重要的网站进行扫描，最少需要一个小时。花费几个小时的扫描并不罕见。扫描大型网站时，速度较慢的扫描仪甚至需要几天时间。对于大多数公司的 CI/CD 流程来说，几个小时的等待时间太长了。

第二，不是所有的结果都值得你关注。我听到的关于 DAST 扫描器的说法之一是“因为它们攻击你的网站，所以它们没有 SAST 扫描器的误报问题。”这显然是错误的。好的 DAST 扫描仪会发现许多安全问题，但也会产生许多误报。一些发现只需要人工检查来验证是否存在漏洞。

除此之外，你可以期待你的 DAST 扫描仪产生大量的复制品。特别是，尽管 ASP.NET Core 网站几乎总是在站点级别配置，但 DAST 扫描器往往会报告它发现的每一个标题问题。换句话说，如果您在共享代码中有一个漏洞，您可以预期该漏洞会出现在使用它的每个页面上。

最后，许多扫描仪的 DAST 扫描很难配置。特别是，认证和爬行对于扫描器来说可能很难正确执行。您可以通过配置扫描器对您的网站进行认证并抓取它错过的页面来解决这些问题，但这些配置往往很脆弱。

与在 CI/CD 过程中自动运行 DAST 扫描不同，如果您定期运行扫描而不是在构建过程中运行，您可能会更幸运。我建议您执行以下操作:

  • 定期运行扫描程序，如每天晚上或每个周末。

  • 让第二天分析结果成为你的过程的一部分，并尽可能快地向开发团队报告发现。

  • 建立 SLA(服务水平协议),开发团队将在 X 天内修复所有高发现，在 Y 天内修复中等发现，等等。，所以漏洞不会永远存在。

为了更有效，拥有一个 DAST 工具会很有帮助，它可以帮助你管理副本，可以突出显示上次扫描的新项目，等等。如果没有这种能力，管理列表会变得太麻烦，而且无法完成。

Caution

我早些时候说过，大多数 DAST 扫描仪产生了很多假阳性。我之前也说过，一些 DAST 扫描仪宣传他们不会产生大量假阳性的事实。值得强调的是，这些扫描仪错过了大多数其他 DAST 扫描仪捕捉到的明显项目。我宁愿捕捉更多的项目和一些扫描噪音，也不希望有一个小报告遗漏严重的、容易发现的问题。

带 SAST 扫描仪的 CI/CD

就 CI/CD 而言，SAST 扫描仪比 DAST 扫描仪有一个优势，那就是 SAST 扫描仪完成扫描所需的时间要少得多——大多数时间是几分钟到几小时，而不是几小时到几天。然而不幸的是，SAST 扫描仪通常比大多数 DAST 扫描仪有更高的假阳性率。如果您要运行 SAST 扫描仪作为 CI/CD 流程的一部分，您应该认真考虑设置该流程，使其仅报告新的发现，否则，使用我为 DAST 扫描仪推荐的相同流程也可以很好地用于 SAST 扫描仪。

带 IAST 扫描仪的 CI/CD

IAST 扫描仪在市场上被宣传为比 SAST 和 DAST 扫描仪更好的 CI/CD 流程解决方案，并且大多数都集成了内置的缺陷跟踪工具。然而，IAST 扫描仪的发现仍然不是 100%准确，这意味着对于给定的扫描，你可能会得到大量的假阳性或重复。像 SAST 和 DAST 扫描一样，如果你根据 IAST 扫描的结果自动创建 bug，你的 bug 跟踪系统中可能会有很多无用的 bug。最重要的是，IAST 扫描仪需要有一个运行的网站才能正常工作。有了这些限制，将 IAST 分析与任何 QA 分析结合起来可能是最有意义的，以便在您的过程中最有效地使用扫描。

手动捕捉问题

如前所述，扫描仪无法捕捉到一切。最值得注意的是，扫描器不能可靠地捕捉业务逻辑实现的问题，例如适当地保护安全资产或安全地处理计算(例如，计算购物车中的总价)。对于这类问题，你需要一个人来看一看。幸运的是，这并不十分困难，它从您可能已经在做的事情开始:代码审查。

代码审查和重构

您可能已经在使用代码评审作为获得关于代码质量的第二种意见的方法，因为易读的代码更容易发现错误，更容易维护，等等。易于阅读的代码也更容易发现安全问题。毕竟，如果没有人能理解你的代码，就没有人能发现它的安全问题。因此，现在您有了另一个理由来执行定期的代码审查，并修复在审查过程中发现的问题。

也就是说，您应该考虑进行单独的代码审查，只寻找安全问题。我遇到过几次需要测试我自己的软件的情况，我发现如果我纯粹以寻找错误的方式操作，而不是边操作边修复，我会发现更多的软件错误。发现安全问题也是如此。如果我在寻找各种各样的问题，我更有可能错过难以发现的安全问题。特定于安全的审查有助于避免这个问题。

最后，很少有安全专业人员能够发现源代码中的缺陷。但是，如果您发现了一个问题，您应该考虑让他们定期对您的代码进行手工检查，以发现问题。除了那些你在读完这本书后已经知道的简单问题之外，还有一些更难找到的东西，只有在发现一些可疑的东西并花时间更彻底地挖掘之后才能找到。丰富的安全经验可以使这一过程更快、更容易。

雇佣渗透测试员

手动捕捉问题的另一种方法是雇佣专业的渗透测试人员。好的渗透测试人员很昂贵并且很难找到，但是他们会发现扫描器、代码审查和糟糕的渗透测试人员永远不会发现的问题。

如果你雇佣了一个渗透测试员，确保你知道渗透测试员的流程是什么。我从多个渠道听说，有一些(或者可能不止几个)不道德和/或不称职的“渗透测试人员”会简单地用 Burp Suite 扫描你的网站，并称之为“渗透测试”为了防止这一点，你应该寻找一个渗透测试器，其过程看起来类似于 EC-Council 7 (认证道德黑客考试的提供者)概述的过程。我在本书前面概述了一个类似的过程，但是 CEH 的方法值得在这里重复一下:

  1. 侦察

  2. 扫描和计数

  3. 获得访问权限

  4. 保持访问

  5. 覆盖轨道

我将更详细地介绍每一步。

侦察

任何成功的黑客行动的第一步都是尽可能多地找到你所攻击的公司或网站的信息。对于一个网站，黑客将试图弄清楚该网站是做什么的，存储了什么信息，用什么语言或框架编写，托管在哪里，以及任何其他信息，以帮助黑客确定从哪里开始黑客攻击，并帮助他们知道他们应该期望找到什么。

为了进行更彻底的测试，黑客可能会通过 LinkedIn 或类似手段查找谁在你的公司进行可能的网络钓鱼攻击，进行一些简单的扫描，甚至潜入你的垃圾箱，寻找在废弃材料中发现的敏感信息。

扫描和计数

下一步是扫描您的系统，寻找漏洞。根据项目的范围，您可能会要求黑客只扫描生产环境、测试环境、网站，包括网络和服务器等。您应该知道正在扫描什么，以及使用哪些工具来避免前面提到的只有打嗝的“渗透测试”。

在自动扫描之后，黑客应该查看结果，并尝试找到自动扫描无法找到的进入系统的方法，例如业务逻辑中的缺陷，或者在扫描中寻找异常，以找到扫描器遗漏的项目。

获得访问权限

扫描后，正常的渗透测试会涉及黑客试图使用他们从扫描中收集的信息来渗透您的系统。这是很重要的一步，因为知道恶意参与者可以利用什么是很重要的。例如，正如我在本书前面谈到的，一个数据库用户权限被锁定的网站中的 SQL 注入漏洞比一个数据库用户拥有管理员权限的网站中的 SQL 注入漏洞要严重得多。

保持访问

大多数恶意攻击者不希望只是进入，他们希望停留足够长的时间来完成他们的目标，即窃取信息、破坏信息、污损您的网站、安装勒索软件或其他完全的东西。一个有道德的黑客会试图探查您的系统，以了解恶意黑客能够做哪些事情。

覆盖轨道

正如本书中已经多次提到的，黑客不想被发现。是的，这意味着黑客会试图在他们的攻击中变得隐秘。但这也意味着优秀的黑客会想删除任何可能存在于你系统中的证据。这包括删除相关日志、删除任何已安装的软件或恶意软件等。同样，作为网站所有者，这有助于您了解黑客可以(和不可以)对您的系统做什么。

如果您的渗透测试人员没有完成所有这些步骤和/或不能指导您如何执行这些步骤，那么您可能没有得到完整的渗透测试。这并不意味着这项服务没有价值，它只是意味着你需要小心你的花费，以获得你的钱的价值。

何时解决问题

当谈到你需要修复扫描仪发现的问题的速度时，我遇到了各种各样的态度。在一个极端，我的一个安全方面的朋友把 bug 分成两类，一类你可以立即修复，另一类可以等到下一次冲刺。然而，这对于大多数网站来说并不实际。在另一个极端，我遇到过一些开发团队，他们可以毫无问题地无限期地推迟所有的安全补丁，这样他们就可以专注于添加新特性。这只是自找问题(而且要被开除)。如果这两个极端都不是正确的答案，那什么才是呢？

答案在很大程度上取决于您的开发团队的规模、缺陷的严重性、您所保护的数据的价值、您需要满足的即时承诺的价值、您的上层管理对风险的容忍度等等。这里没有放之四海而皆准的答案。不过，我遵循的一些经验法则似乎在大多数环境下都有效:

  • 立即修复明显的项目，如直接的 XSS 或 SQL 注入攻击。

  • 在下一个或下两个版本中修复一些简单的项目，比如添加标题。

  • 部分风险缓解通常适用于复杂的问题。如果一个安全问题的完全修复需要一周的开发时间，但是修复大多数攻击的部分修复可以在几个小时内完成，那么插入部分修复并将完全修复放入您的待办事项中。

  • 对于难以利用的复杂漏洞，将漏洞传达给高级管理层并寻求指导。你的公司可能决定简单地接受这里的风险。

  • 养成在漏洞投入生产之前发现并修复漏洞的习惯。换句话说，运行频繁的扫描，不要让自己养成允许新发现的漏洞投入生产的习惯。你已经很难抵御零日攻击了；不要故意引入新的漏洞。

  • 制定一个计划来修复您的待办事项中的安全漏洞。向高层管理人员传达计划和风险。根据风险、预算和其他因素，他们可能会雇用程序员来帮助尽早减轻风险。

我想强调的是，这些都是指导原则，您的具体需求可能会有所不同。但是我发现这些指导方针在更多的地方起作用。

了解更多信息

如果你想了解更多，我建议你从 Dafydd Stuttard(Portswigger 的首席执行官，Burp Suite 的开发者)和 Marcus Pinto 的《Web 应用黑客手册》开始。这里没有很多专门针对微软 web stack 的信息，但这是我在渗透测试网站上遇到的最好的书。

对于安全相关的新闻，我喜欢每日 Swig， 8 另一款 Portswigger 产品。Troy Hunt ( https://troyhunt.com )是微软的 MVP/区域总监，他定期撰写关于安全的博客，是 haveibeenpwned.com 的所有者，尽管他更倾向于关注哪些公司最近遭到了黑客攻击，而不是我特别关心的。否则，阅读 SecurityWeek 和 Dark Reading 等安全网站可以让您了解最新的安全新闻。

如果你想通过学习获得认证，我建议你学习注册职业黑客 9 (CEH)或注册信息系统安全专家 10 (CISSP)。这两种认证都深入到您作为 web 开发人员可能不感兴趣的其他安全领域，并且在实际获得认证之前都需要几年的经验，但是您可以通过学习这些考试学到很多东西。学习 GIAC Web 应用渗透测试 11 (GWAPT)考试也是一种可能，但是我一直无法找到 CEH 或 CISSP 考试可用的各种学习材料。

最后，我鼓励你尝试闯入你自己的网站(当然是在一个安全的测试环境中)。阅读可以用来侵入网站的各种技术是一回事，但是很少有东西能像经验一样教人。你能打破什么？你能偷什么？你如何阻止其他人做同样的事情？

摘要

了解安全代码是使网站安全的良好开端，但是如果你不能在日常开发中运用这些技术，你的网站就不会安全。为了帮助您找到漏洞，我介绍了各种类型的测试工具，然后讨论了如何将它们集成到您的 CI/CD 流程中。最后，我谈到了如何手动捕获问题，因为工具不能捕获所有问题。

Footnotes [1](#Fn1_source) [T2`www.cnbc.com/2019/11/19/hacked-disney-plus-accounts-said-to-be-on-sale-according-to-reports.html`](http://www.cnbc.com/2019/11/19/hacked-disney-plus-accounts-said-to-be-on-sale-according-to-reports.html)   [2](#Fn2_source) 表 7-5，第 7-12 页   [3](#Fn3_source) [T2`www.sectoolmarket.com/`](http://www.sectoolmarket.com/)   [4](#Fn4_source) [T2`www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project`](http://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project)   [5](#Fn5_source) [T2`https://portswigger.net/burp`](https://portswigger.net/burp)   [6](#Fn6_source) [T2`https://github.com/jeremylong/DependencyCheck`](https://github.com/jeremylong/DependencyCheck)   [7](#Fn7_source) CEH 认证道德黑客考试指南，第三版，马特沃克，第 26 页   [8](#Fn8_source) [T2`https://portswigger.net/daily-swig`](https://portswigger.net/daily-swig)   [9](#Fn9_source) [T2`www.eccouncil.org/programs/certified-ethical-hacker-ceh/`](http://www.eccouncil.org/programs/certified-ethical-hacker-ceh/)   [10](#Fn10_source) [T2`www.isc2.org/Certifications/CISSP`](http://www.isc2.org/Certifications/CISSP)   [11](#Fn11_source) [T2`www.giac.org/certification/web-application-penetration-tester-gwapt`](http://www.giac.org/certification/web-application-penetration-tester-gwapt)  

**

版权属于：月萌API www.moonapi.com，转载请注明出处

本文链接：https://www.moonapi.com/news/36907.html