为什么脚本审查不足以防止客户端攻击

在最近的几次供应链攻击之后，例如来自 SolarWinds 的攻击，甚至是最近导致Celsius Networks 网络钓鱼攻击的攻击，许多人都在提倡更严格的第三方控制。Celsius 甚至表示，该公司“将提高我们在 ISO 和 SOC 认证方面对第三方的要求。”

但更严格的第三方控制究竟意味着什么？公司如何获得第三方的控制权？在Web 供应链攻击的背景下，脚本是否正在审查最终答案？让我们找出来。

什么是第三方脚本审核？

要掌握第三方审查的概念，我们需要看一下普通网站。如今，随着对更快的产品开发的需求不断增长，开发人员越来越依赖外部源代码片段，尤其是 JavaScript 框架和库。这导致平均 Web 应用程序具有超过 1000 个模块，也称为代码依赖项。由于这些模块中的每一个都可以有自己的依赖项，因此每个应用程序最终都会有数千个第三方代码。

然后，还有大多数网站在运行时使用的所有附加脚本的问题。如今，大多数网站都在使用外部服务，如聊天机器人、分析或广告。

随着第三方的大量使用，攻击面增加，特别是在涉及供应链攻击时。由于这些攻击依赖于公司对其代码对供应链的依赖性缺乏可见性，因此它们通常会在数周内不被注意。我们已经在2018 年Magecart 网络浏览组攻击英国航空公司的案例中看到了这种情况，该事件在两个多月的时间里都没有引起注意。

现在，第三方脚本审查背后的概念是，公司将审查每个第三方脚本和提供它的公司，以确保它们是合法和安全的。允许使用经过审查的脚本，而那些未通过审查程序的脚本将被放弃（至少在它们仍然不安全的情况下）。

审查脚本提供者的过程通常是通过寻找证明公司对安全的承诺的认证 (ISO/SOC) 来完成的。另一方面，脚本审查通常涉及扫描代码以查找任何可能使攻击者更容易破坏脚本的漏洞或安全漏洞。

乍一看，这似乎是问题的最终答案。然而，正如我们接下来将看到的，虽然这种第三方审查方法在帮助公司应对网络供应链攻击方面发挥着重要作用，但它必须与额外的安全措施相结合。

为什么脚本审查不足以防止 Web 供应链攻击？

如果我们在几天内仔细观察任何给定网站的不同部分，我们会看到数百个代码依赖项在不断变化。这些框架和库中的每一个都会收到更新，它们各自的第四方也会收到更新。

当我们将这种动态场景与脚本审查的概念进行对比时，我们很快就会明白为什么仅靠脚本审查不足以保证第三方脚本的安全。脚本审查的最大问题是它只提供了一个时刻的画面。这意味着今天成功通过审查并被视为安全的脚本（因为它来自合法公司并且不包含任何已知漏洞）可能会突然成为安全责任。如果我们只相信审查，我们就会盲目相信这个脚本，完全无视它对我们网站的实际作用。说明这一点的完美例子是Copay 事件一个看似合法的库被攻击者秘密接管，攻击者进行了包含恶意代码的更新，最终进入加密钱包的生产版本并窃取了一些用户的加密货币。

这种方法的另一个关键问题是平均网站包含 35 个不同的第三方组件。鉴于 Web 供应链如何与其最薄弱的环节一样安全，强大的审查策略将需要检查这些脚本中的每一个——这是一项极其复杂的任务。

最后，脚本审查过程本身并非没有缺陷。虽然扫描漏洞是一种很好的安全做法，但它不会分析每一行代码来寻找潜在的恶意行为。一个没有已知漏洞的脚本仍然可能是危险的，例如，如果它试图访问敏感的用户数据。

获得完全的可见性和控制

因此，如果仅仅脚本审查不是网络供应链安全的最终答案，那什么才是呢？这个问题的简短答案是深度安全。

正如我们所见，脚本审查并没有解决合法脚本如何突然改变其行为的问题。因此，深入方法的下一步是实时了解每个脚本在网站上的行为方式。这种可见性使公司能够立即检测到任何可疑行为，例如已知脚本突然开始篡改付款表格（Magecart 网页浏览攻击）或试图将数据发送到未知域（数据泄漏）。

考虑到 Magecart web skimming 攻击在被检测到之前平均保持活跃 22 天，这种实时可见性可以极大地改善事件响应并遏制数据泄漏。

尽管如此，可见性只是深度安全方法所需响应的一半。另一半来自对每个脚本行为的完全控制。有效控制意味着能够实时限制特定的允许或不允许的行为，以便立即阻止任何恶意活动的企图（例如泄露用户数据、在网站顶部显示弹出窗口），从而阻止攻击。

为了达到这种控制水平，公司需要寻找允许建立强大而灵活的规则来阻止客户端所有恶意活动的解决方案。此外，这些解决方案必须确保每个脚本的正常功能都不会受到影响，从而使用户体验不受影响。

毫无疑问，公司要完全控制其网络供应链还有很长的路要走。因此，这是迈出第一步的方法：请求一份免费的网站库存报告，并全面了解您网站的脚本及其特定行为。