锁定您的 JavaScript：使用 Page Shield 策略进行主动阻止

Web 开发团队的任务是以闪电般的速度交付功能丰富的应用程序。为了帮助他们，有数千个预先构建的 JavaScript 库，他们可以毫不费力地集成这些库。

然而，这些库并非总是有严密的安全措施支持，以确保它们提供的代码不会被恶意行为者篡改。这最终导致应用程序被入侵的风险增加。

从今天起，企业可以更轻松地应对外部 JavaScript 库的风险。我们将为客户端安全解决方案添加一项新功能：Page Shield 策略。通过使用策略，您现在只需查看核对表，就能确保您的应用程序只执行允许和经过审核的库。

客户端库

截至撰写本文时，cdnjs（一个流行的 JavaScript 存储库）上有超过 4,373 个库可用。这些库提供对构建 Web 应用程序的预构建功能的访问。下面的截图显示了平台上最流行的 React、Vue.js 和 Bootstrap。据 W3Techs 称，仅 Bootstrap 就被超过 20% 的网站所使用。

除了 cdnjs 这样的库，SaaS 平台还直接提供了成千上万的插件，包括来自 Google、Meta、Microsoft 等公司的插件。

根据我们的 Page Shield 数据，任何大型企业应用程序都在加载和连接数十个甚至数百个不同的目的地，以实现分析、支付、真实用户监控、转换跟踪、客户关系管理以及内部团队“必须具备”的许多其他功能。

最终，大多数组织都很难不依赖外部 JavaScript 库。

攻击者的另一个媒介

尽管在应用程序中嵌入外部 JavaScript 有其充分的理由，但客户端库（尤其是 SaaS 提供商提供的客户端库）的激增，让越来越多的恶意行为者试图寻找利用 Web 应用程序的新方法。只要入侵一个提供客户端库的 SaaS 提供商，就能直接访问成千上万的应用程序，大幅提高了“黑客”的投资回报。

客户端安全问题并不新鲜。诸如“Web 浏览”之类的攻击（在支付页面中也称为“Magecart 式”）已经存在很长时间了。然而，核心应用程序安全产品通常专注于保护底层 Web 应用程序，而不是最终用户数据，从而导致产生了大多数安全团队根本看不到的大型攻击面。这种由“供应链”造成的可见性差距促使我们构建了 Cloudflare 的原生客户端安全解决方案 Page Shield。

尽管供应链攻击的风险已广为人知，但它们仍然是一个非常活跃的威胁。该领域的供应商每月都会发布新的研究报告，强调正在进行的攻击活动。支付卡行业安全标准委员会还在 PCI DSS 4.0* 中引入了新要求，强制公司建立适当的系统和流程来应对客户端安全威胁。

Page Shield 本身已经能够有效地警告客户其应用程序正在遭受攻击，例如下面的屏幕截图，突出显示了针对客户电子商务应用程序的 Magecart 式攻击的活动恶意出站连接。

^* PCI DSS 4.0 要求 6.4.3 和 11.6.1 只是侧重于客户端安全的两个例子。

减少攻击面

Page Shield 的目的是检测客户端环境中的恶意活动并在发现恶意活动时发出警报。随着我们进一步提高检测能力，这仍然是一个核心焦点。

我们现在还在考虑扩展功能，先减少攻击者入侵应用程序的机会。换句话说，通过减少可用的攻击面来防止攻击发生。

今天，我们宣布推出这一领域的首个重要功能：Page Shield 策略。看起来像这样：

积极的阻止策略

通过利用我们在网络堆栈中的地位作为反向代理，并使用 Page Shield 策略，您现在可以强制客户端浏览器仅加载和执行来自您预先批准的允许来源列表中的 JavaScript 库，从而实现积极的安全模型。

这确保了能够在页面中注入脚本的攻击者不会成功危害用户，因为浏览器将拒绝加载它。同时，经过审查的工具将毫无问题地运行。

策略很快还将允许您指定数据目的地（连接端点），不仅强制执行 JavaScript 文件的加载位置，还强制执行浏览器可以发送数据的位置，以大幅降低“Magecart 式”攻击的风险。

CSP 作为核心机制

目前，Page Shield 策略是通过内容安全策略 (CSP) 来实现的，这是所有主要浏览器本身都支持的功能。

CSP 是添加到 HTML 页面加载中的特殊格式 HTTP 响应标头。这些标头可能包含一个或多个指令，指示浏览器如何在给定页面的上下文中执行以及执行什么。

从今天开始，Page Shield 策略支持 script-src 指令。该指令允许应用程序所有者指定允许从“何处”加载 JavaScript 文件。对 connect-src 指令的支持也正在进行最终确定，其行为与 script-src 类似，但指定允许浏览器将数据发送“到”的位置。

让我们看一个示例，假设我们打开以下网页 www.example.com/index.html 并且浏览器收到如下 CSP 标头：

Content-Security-Policy: script-src 'self' *.example.com cdnjs.cloudflare.com https://www.google-analytics.com/analytics.js

标头指示浏览器允许从与页面本身（由 self 定义）相同的主机名以及从任何子域 (*.example.com) 加载脚本（通过使用 script-src 指令定义）。此外，它还允许 cdnjs 下的任何脚本，并且仅允许 Google Analytics 的特定脚本，而不允许 Google 拥有的域下的其他脚本。

这就确保了任何攻击者从不同主机注入的脚本都不会被执行，从而大大减少了可用的攻击面。

如果我们收到的不是 Content-Security-Policy 标头，而是 Content-Security-Policy-Report-Only 标头，则不会强制执行该策略，浏览器只会发送违规报告，让您知道哪些内容超出了策略范围。

这在测试和调查添加到应用程序中的新脚本时非常有用。

Page Shield 还在 script-src 指令中提供并支持其他语句，以阻止内联 JavaScript (unsafe-inline) 或通常不安全的函数调用 (unsafe-eval)。这些指令有助于防止其他攻击类型，例如 Cross-site scripting (XSS) 攻击。

让策略管理变得简单

CSP 是 Page Shield 策略使用的底层系统，虽然很棒，但很难管理。应用程序越大，CSP 就越复杂，同时也会给应用程序开发团队带来瓶颈。随着安全团队扩大允许的主机列表，CSP 变得无效化，其使用目的也开始变得有争议。

使策略管理变得简单并确保其有效是我们设计过程的核心目标。这促使我们建立了建议功能。

部署策略时，第一步是决定将策略应用到“何处”。典型示例可能包括仅结账流程或管理页面。这是使用 wirefilter 语法完成的，该语法与支持 Cloudflare WAF 的语法相同。

指定过滤器后，界面将使用 Page Shield 已收集的数据，提供建议的指令值列表，让您可以轻松地为应用程序构建最简单且最有效的策略。无需担心语法，提交前将显示策略预览。

最后，策略可以部署在“仅报告/日志”和“强制/允许”中，让您根据需要进行控制和测试。

我们目前正在完成警报后端的工作，以便在发现违规报告激增时向您发出警告。这使您可以轻松返回策略构建器，并使用开发团队可能添加的任何新脚本对其进行更新。

积极的阻止策略并不足够

重要的是不要忘记，CSP 在允许端点列表中不提供安全或恶意活动检测。它们旨在通过减少可用的攻击面来降低发生攻击的可能性。因此，无论部署什么策略，Page Shield 的自动恶意活动检测都将继续在后台运行。

立即保护最终用户数据

现在，所有 Cloudflare 付费客户都可以访问一部分 Page Shield 功能。只需点击一个按钮，即可打开 Page Shield。前往“安全”>“Page Shield”并尝试一下！

如果您是 Enterprise 计划客户，并对 Page Shield 策略感兴趣，请联系您的客户团队，获取完整的功能集。