产品

Ostorlab 新增 Web 安全扫描能力

Ostorlab 新增 Web 安全扫描器，以全新的方法开展漏洞发现。

Alaeddine Mesbahi 2021年2月15日

发布公告

Ostorlab 很荣幸地宣布，我们的工具库中新增了一款 Web 安全扫描器。这款新扫描器采用了全新的漏洞发现方法，利用此前已识别的漏洞来发现类似的漏洞。

Ostorlab Web Security Scanner 的诞生，是为了解决大多数组织都面临的一个痛点：同时使用多种互不兼容的工具分别测试移动应用和 Web 应用，对开发人员和安全团队来说实在太过繁琐。

通过提供一款同时覆盖两种平台的工具，我们希望降低采用门槛。与此同时，新的检测方法旨在从根本上改进自动化漏洞发现，并有望超越人工测试的能力。

当前版本仍处于 Alpha 阶段，有兴趣试用的用户可以通过 here 给我们留言。

问题所在

Ostorlab Web Security Scanner 带来了全新的漏洞发现方法，但在深入介绍其工作原理之前，我们先来厘清当前漏洞扫描器存在的问题。

大多数安全专业人员都会认同，SQLMap 可能是目前最好的 SQL 注入检测工具。这在很大程度上得益于其非常丰富的 payload 数据库，以及对海量注入上下文的覆盖，例如带单引号的 WHERE 子句注入、带双引号的 WHERE 子句注入、ORDER BY 上下文、HAVING 上下文、SORT 上下文、 MySQL 上下文、Postgres 上下文、Oracle 上下文，不一而足。每一种注入上下文都需要专门的 payload。

SQLMap 要针对所有这些上下文测试单个参数，需要几分钟才能完成……而这仅仅是一个参数。

单个请求可能包含数十个甚至数百个注入点，来自 URL、路径、参数、请求头、 Cookie 值、请求体参数，而这还没有算上搜寻 debug 或 trace 之类的隐藏参数。

要在每一个页面的每一个输入上测试每一种漏洞、覆盖每一种上下文，需要数百万个请求，需要数周时间才能完成。

大多数扫描器最多只需几个小时……就能完成扫描。它们的做法是让扫描超时，或者限制覆盖范围。在大多数扫描器中，您实际上可以调整这些参数。

这个问题不仅存在于 SQLi、代码注入或模板注入等后端漏洞，也同样适用于跨站脚本（XSS）等客户端漏洞。

XSS 在客户端同样会出现在不同的上下文中：可能出现在 a 标签、div 标签中，可能出现在属性中或其内容中，可能存在长度限制、字符限制，可能由注入特制的 JSON 对象引起，也可能来自不同的输入源。

动态检测 XSS 漏洞需要注入 payload，一旦注入成功就会触发回调。每种上下文都需要定制的 payload 才能执行回调。

与后端漏洞一样，用专门的 payload 测试每一种上下文，会产生大量请求，需要数周的测试时间。

除了这些挑战之外，自动化漏洞发现还面临许多其他障碍，例如对嵌套序列化的支持（Cookie 中的 JSON 里的 base64 里的 JSON）、没有利用此前运行或其他扫描中收集的知识（爬取结果、参数、国际化、暴力破解字典），或者缺乏对重度依赖 JavaScript 的 Web 应用（SPA）的支持。

我们的方法

大多数漏洞扫描器可以分为 2 个部分：一组分析引擎和一个知识库。引擎的定义较为宽泛，可以执行各种不同的操作和转换，从最简单的发送 HTTP 请求，到最复杂的污点分析或混合执行（concolic execution）。

知识库随后用于解读分析引擎收集的数据，并报告存在漏洞的行为。 强大的检测既需要强大的引擎，更重要的是需要丰富的知识库。

在所有漏洞扫描器中，构建知识库都是一个复杂、繁琐且依赖人工的过程。然而，新漏洞被报告的规模，以及新框架（Vue.js、Hotwire、Svelte……）、新编程语言（Julia、Scala、Rust……）、新模板引擎、新后端解决方案和新查询语言的涌现速度，已经让人工方法完全无法扩展。

虽然一些项目尝试通过众包来扩展知识库，但这仍然是一个远未解决的问题。

要让自动化漏洞发现实现规模化，我们需要一种自动构建漏洞知识库的方法。

后端漏洞

我们解决这一问题的方法分为两种。

第一种方法针对影响“智能组件”的后端漏洞，例如 SQL 数据库、模板引擎、Shell 解释器，甚至任意对象反序列化器。

这些组件通常接受字符串或任意字节，从而导致注入，改变应用的预期行为并造成危害。

当安全研究人员测试这类漏洞时，通常会先用一组非常简单的 payload 来检测异常行为，例如添加一个单引号 '，然后添加两个单引号 ''，再除以 0 或除以 (1-1)。其目标是检测任何非预期的行为，例如 500 状态码或空响应。

随后，测试人员会使用更复杂的 payload 来缩小到某一类或某几类漏洞，正是在这个阶段，测试人员的经验对于判断应测试哪些 payload、得出什么结论起着重要作用。

Ostorlab 复现了同样的方法：我们不注入单个复杂的 payload，而是注入一系列小型 payload，再根据这些 payload 的响应来决定接下来应执行哪些测试用例。所有这些 payload 构成一棵非常庞大的树，在每个节点上，我们都会从响应中收集特征，例如状态码、页面大小、 script 标签或 a 标签的数量等。

每次测试的目标都是过滤掉噪声特征；如果应用存在漏洞，一组特征就会呈现出某个漏洞类别上下文所特有的变化。

然而，编写这些测试树比构造一个功能完备的 payload 难得多，因为我们需要结合之前的测试用例进行推理，并预判误报可能如何产生。

不过，这项任务是可以自动化的：我们只需创建大量存在漏洞和不存在漏洞的应用，为存在漏洞的应用标注其漏洞类别，在所有测试用例上运行数十万个 payload，然后使用类似决策树生成算法的算法来构建测试树。

最终得到的是一棵由数千个节点组成的压缩测试树：

这种方法的优势在于，在最简单的情况下（例如静态页面），我们只需发送数十个 payload （而不是数百万个）即可排除某个参数存在漏洞的可能。同时，如果应用存在漏洞，我们也只需要发送数百个 payload 即可确认，因为测试会逐步收窄到树的某个分支。

另一个优势是提高覆盖率：测试树的好坏取决于我们的测试平台，误报和漏报可以通过添加相关测试用例并重新生成测试树来解决，而重新生成仍需数天的计算时间。

这种组合让我们能够在覆盖范围和测试规模两方面实现扩展。

XSS

第 2 种方法针对最常见的漏洞类别：跨站脚本（XSS）。

Ostorlab 的 XSS 检测应对的是同样的挑战，但并没有采用截然不同的方法。它建立在该领域已有工作的基础之上，即多语言 payload（polyglot payload）。

多语言 payload 是手工构造的字符串，力求在单个 payload 中尽可能多地压缩目标上下文。您可以在网上找到关于这一主题的优秀文章，还有相关竞赛以及一系列适合用于测试的优质 payload。

然而问题在于，有些上下文互不兼容，因此必然需要不止一个 payload，而且几乎所有可能引入 XSS 的模板引擎都从未被这些 payload 覆盖。Cordova 和 Ionic 等 JavaScript 移动框架有其自身的一系列上下文，目前也没有能够高效覆盖这些上下文的公开 payload。

为每种上下文手工构造高效的多语言 payload 是一项繁琐、复杂且艰巨的工作。

为了应对这些挑战，Ostorlab 使用遗传算法生成大量高度优化的多语言 payload。生成的每个 payload 覆盖的注入上下文都多于单个手工构造的 payload，同时不影响可扩展性。

遗传算法受自然选择过程启发，属于更大一类的进化算法（EA）。遗传算法通常依靠变异、交叉和选择等受生物学启发的算子，为优化和搜索问题生成高质量的解。

遗传算法易于实现，由一系列可重复的阶段组成，这些阶段在找到解之后或在固定的迭代次数之后停止。针对我们问题的实现如下：

第 1 阶段，种群：每次迭代都从一个种群开始。在我们的场景中，初始种群是一组覆盖测试平台中每种上下文的 payload。我们进行了多次实验，有的使用简单的小型 payload，有的则在其中加入了表现优异的 payload。
第 2 阶段，评估：此阶段在测试平台上测试每个 payload，并列出每个 payload 覆盖的测试用例。
第 3 阶段，选择：找出表现最佳的 payload。可以使用不同的选择标准，例如覆盖的上下文数量、payload 的长度、按长度加权的上下文比率等。
第 4 阶段，变异与交叉：从现有种群生成新的种群。这包括一系列转换，例如令牌注入、字符翻转、截断、部分拼接等。

为了找到表现最佳的 payload，我们进行了多次实验来寻找合适的组合（有人称之为超参数）。例如，在初始种群中使用表现优异的 payload，可以快速收敛到高性能的解，但很快就会停滞在局部最大值。而使用小型 payload 虽然收敛缓慢，却也能产生独特而出人意料的解。

生成的 payload 中包含一些出人意料的模式，它们利用了浏览器渲染引擎中未公开记录的行为，在绕过 XSS 过滤器方面也展现出了可观的效果。

未来展望

Ostorlab Scanner 还解决了其他问题，例如嵌套序列化检测和单页应用（SPA）爬取。其背后的团队正在积极开发新功能，例如 JavaScript 污点分析、postMessage XSS 检测。

Ostorlab 还致力于利用以往扫描和其他扫描中收集的数据来提升未来的扫描结果。Ostorlab 力求在每一次扫描中变得更加智能。