将 Active Content Filtering 用于 Project Zero 和 WebSphere sMash 应用程序的安全性

核心提示：ACF 简介作为 ACF 入门的一部分，您必须先理解什么是 Project Zero，将 Active Content Filtering 用于 Project Zero 和 WebSphere sMash 应用程序的安全性，如下内容摘自 Project Zero Web 站点： “Project Zero

ACF 简介

作为 ACF 入门的一部分，您必须先理解什么是 Project Zero。如下内容摘自 Project Zero Web 站点：

“Project Zero 是 IBM® 内部发起的一个孵化器项目，侧重于下一代动态 Web 应用程序的敏捷开发。Project Zero 引入了一种简单的环境，这种环境支持基于流行的 Web 技术创建、组装和执行应用程序。Project Zero 环境包括一个面向 Groovy 和 PHP 的脚本运行时，并且具有应用程序编程接口，这些接口针对 REST 风格服务、集成 mashup 和富 Web 接口的生成进行了优化”。

Project Zero 主要针对的是一下代动态 Web 应用程序（通常归类为 Web 2.0），本文侧重于交互式 Web 应用程序，这些应用程序可能会包含用户提供的内容，比如 mashup、wiki 和 blog。为了支持这些应用程序，Project Zero 提供了 ACF 库，应用程序开发人员可以将其包括在 Zero 应用程序内。ACF 让开发人员能够避开经常在这类应用程序出现的跨站点脚本等问题。

关于示例

作者留言：初次写完本文时，应用程序开发人员必须通过声明方法（在应用程序的 zero.config 中定义显式规则）或编程方法（使用提供的 API）来利用 ACF。根据 Project Zero 社区和本文读者反馈的信息，开发团队为以下场景提供某些默认级的 ACF 保护（要求将 zero.acf 添加为依赖项）：

请求参数：从所有发送到 URI 的入站请求参数中删除活动内容（比如 JavaScript、Applet 和 ActiveX）。这些参数被看作是 HTML 片段。

JSON 内容请求：从发送到 URI 的入站 JSON 对象的所有 String 值中删除活动内容。在这种情况下，已经指定所有内容的类型。

JSON 内容响应：从 URI 发送的出站 JSON 对象的所有 String 值中删除活动内容。在这种情况下，已经指定除 “text/html” 以外的所有内容类型。

要取消默认的 ACF 启用，下面的配置选项包含了示例应用程序的 zero.config"/config/acf/enableByDefault=false"。因为在某些情况下默认启用有可能不能满足应用程序的要求，本文将把焦点集中在通过声明和编程方法利用 ACF。在适当的时候，本文将解释通过默认标志利用启用的各个小节。

本文提供的示例旨在借助由简到难的用例充分展示 ACF 。这些示例均构建在之前的示例之上。如下是这些示例的一个摘要，每个示例会在随后的章节详细加以介绍：

示例 1 是一个很基本的、启用了 Ajax 的页面，它允许用户评论从外部接收的文章。这个示例展示了在用户评论或文章中包含活动内容时（比如 JavaScript）发生的情况。

示例 2 构建在示例 1 的基础上，并包含对 ACF 库的支持。这个示例展示了在文章中包含活动内容（比如 JavaScript）时 ACF 过滤功能如何工作。

示例 3 构建在示例 2 的基础上，但支持使用 ACF 过滤请求参数这个功能。这个示例展示了当用户评论中包含活动内容 — 比如 JavaScript — 时 ACF 过滤功能如何工作。

可以从本文的 下载 部分下载这个示例应用程序，以获得使用 ACF 特性的实际操作经验。此示例应用程序模拟了一种 Web 新闻聚合和 blog 应用程序，它允许向服务器发表对当日新闻的评论，服务器反过来又会向其他查阅者显示这些评论。如 图 1 所示，页面的顶部显示了新闻聚合的结果，从中可以看到被注入的潜在恶意内容（闪动的红色文本）。单击 Original source of the news 标题窗格会显示新闻聚合的原始 HTML 内容。也可以在底部的文本区域 Enter your comments here 发表评论，单击 Post your comment 按钮后，评论就会立即显示在 All comments 区域。

图 1. ACF 示例

图片看不清楚？请点击这里查看原图（大图）。

我们将使用 IBM 最新的 Web 2.0 平台 Project Zero 来构建服务器端的组件。此示例应用程序的前端使用的是新兴的 Dojo 和 Ajax 技术。

Project Zero 通过 zero.acf 库提供 ACF 支持，这个库被配置为 ivy.xml 文件的一个应用程序依赖项。本文提供了一个包含示例应用程序（名为 ACFSampleApp-1.0.0.zip）的 zip 文件。请使用 zip 工具将这个文件解压缩到磁盘。

针对命令行用户：

根据说明在 WebSphere sMash Web 站点上安装 IBM WebSphere sMash 命令行实用程序。

回到解压缩示例应用程序的目录。

通过 zero start 开始应用程序。

针对应用程序构建用户：

根据说明在 WebSphere sMash Web 站点上安装 IBM WebSphere sMash 命令行实用程序。

通过导航到安装 CLI 的 zerodirectory 目录并运行 “startAppBuilder” 脚本开始应用程序构建器。

使用面板左边的 “Browse Applications” 链接从 WebSphere sMash 存储库安装 OpenID 演示应用程序。

单击与 ACFSampleApp（参见 下载）应用程序相关联的播放按钮开始应用程序。

接下来，将浏览器指向 http://localhost:8080 以测试这个示例应用程序。

场景 1：ACF 响应过滤

第一个场景是使用 ACF 响应过滤阻止恶意内容。ACF 响应过滤能够基于一组过滤规则（在本文稍后部分介绍）从响应消息中剥离活动内容（比如 JavaScript）。在运行示例应用程序时，可以看到在页面顶部的新闻头部已经注入了闪烁显示的恶意文本，这些恶意文本源自第一个新闻提要的某些活动内容（JavaScript 代码）。通过单击 Original source of the news 标题框可以查看此新闻提要的源代码，如 图 2 所示：

图 2. 新闻头部的恶意文本

图片看不清楚？请点击这里查看原图（大图）。

现在，我们来看看如何使用 ACF 响应过滤阻止这些恶意文本对应用程序进行破坏。ACF 响应过滤可由 zero.config 配置文件控制。要启用 ACF 响应过滤，需要如下条目（参见 清单 1）：

清单 1. 配置 ACF 响应过滤

#　ACF　filter　rule　
@include　"${/config/dependencies/zero.acf}/config/acf.config"{　
　"conditions"　:　"/request/path　=~　/resources/newsViewer(.*)"　
}　

这个示例提供了此配置。要启用 ACF，只需在 zero.config 文件中去掉对这部分的注释并重启 Project Zero 服务器即可。如图 3 所示，配置属性中的这两行就可以告知 ACF 引擎使用 ACF 提供的默认预定义规则集过滤掉源自 URI /resources/newsViewer 的任何活动内容。

图 3. 配置 ACF 响应过滤

图片看不清楚？请点击这里查看原图（大图）。

再次运行此应用程序，就不会看到闪烁显示的烦人文本了。

场景 2：ACF 请求过滤

处理以 Web 2.0 为主题的应用程序通常都会允许用户向托管服务器输入或发表内容。当服务器呈现恶意内容（比如 JavaScript）时，就会产生安全性问题。在示例应用程序中，用户可以向服务器发表评论。要展示恶意脚本的破坏性，可以在 Enter comments 区域输入清单 2 所示的文本：

清单 2. 示例恶意脚本

<script>alert("You　are　under　attack!")</script>　

单击 Post your comment 按钮，会看到 All comments 结果区域为空白，这时，烦人的 JavaScript 以弹出的方式显示。

那么，该如何过滤 HTTP 请求和阻止恶意 JavaScript 攻击呢？为实现此目的，ACF 提供了一组功能强大的 API。这些 API 会基于一组过滤规则告诉您是否有活动内容（比如 JavaScript）包含在 HTTP 请求参数中。如果找到了活动内容，就可以抛出一个适当的异常并使用 Project Zero 的另一个库（称为 XMLEncoder，可以对这些活动内容进行编码）以确保它不会在运行时执行。在我们的示例中，处理外来的注释 POST 请求的服务器端组件是 commentHandler.groovy 类。这也是添加 ACF 请求过滤代码的地方。可以通过去掉对本文所提供的代码的注释来启用此特性，如 图 4 所示：

图 4. 启用 ACF 请求过滤

图片看不清楚？请点击这里查看原图（大图）。

这次无需重启 Zero 服务器就可以测试此特性。重新加载应用程序页面并在评论区域张贴相同的 JavaScript。很显然，您将不能再张贴有害的内容，如 图 5 所示：

图 5.ACF 请求过滤的一个示例

图片看不清楚？请点击这里查看原图（大图）。

客户端过滤

作者留言：上面描述的场景是默认 ACF 启用的理想用例。在这一场景，用户将通过用 JSON 编写的消息发布活动内容，这个消息与上面描述的 JSON 内容请求场景相匹配。在这一场景，在为应用程序提供已解码的 JSON 数据之前，将从 JSON 值中删除 JSON 字符串的恶意部分。

到目前为止，您主要是在服务器端看到了 ACF 在阻止恶意攻击方面的有力保护。要进一步提高应用程序的安全性，必须考虑使用一些现代 JavaScript 库引入的客户端编码功能，比如 Dojo 框架。例如，Dojo 的富文本编辑器能够自动地将用户输入的内容编码为 HTML 代码，使用这些代码是相对安全的。注意：虽然客户端编码非常有用，但是它不能够代替在服务器端的进行 ACF 过滤，因为用户能够轻易地避开在客户端执行的操作。

本文中的示例应用程序提供了一种基于 Dojo 的富文本编辑器。要测试此应用程序，需要将浏览器指向 http://localhost:8080/clientfilter.gt。如 图 6 所示，通过 Dojo 编辑器张贴的 JavaScript 在发送给服务器之前就已经编码完毕。因此，所张贴的内容将不会被浏览器解释为活动 JavaScript。

图 6. Dojo 编辑器实现

图片看不清楚？请点击这里查看原图（大图）。

作者留言：上面描述的场景是默认 ACF 启用的理想用例。在这个场景中，用户将通过编码为 url 形式的消息发布活动内容，这个消息与上面描述的请求参数场景相匹配。在这个场景，在应用程序访问请求参数之前，将从请求参数中删除请求参数值中的恶意部分。

结束语

通过本文，您已经看到了 ACF 是如何通过启用过滤活动内容来为应用程序部署提供增强的灵活性的，而且整个过程无需开发人员对应用程序进行任何重大更改。这种增强的灵活性让应用程序能够更好地远离活动内容方面的问题，比如跨站点脚本（XSS），XSS 是很多 Web 2.0 应用程序上常见的攻击。请试用这个示例应用程序并将您的反馈通过 Project Zero 论坛提供给我们。

本文示例源代码或素材下载