保护 mashup 中的工件和数据的技术和技巧-1

look_w

Mashup 是指使用来自各种（通常是公共的）来源的 UI 工件（artifacts）和数据构建的应用程序和 Web 页面。一个 mashup 开发模型在引入一个开放开发模型的同时也会带来许多新的安全风险。在开发一个 mashup 应用程序时，这些风险使安全问题浮出了水面。
常用缩略词

• DMZ：隔离区（Demilitarized zone）
• DOM：文档对象模型（Document Object Model）
• HTML：超文本标记语言（Hypertext Markup Language）
• HTTP：超文本传输协议（Hypertext Transfer Protocol）
• SQL：结构化查询语言（Structured Query Language）
• SSL：安全套接字层（Secure Sockets Layer）
• UI：用户界面（User interface）

传统安全措施（比如 DMZ 和防火墙）在处理 mashup UI 工件和数据所需的细粒度访问时往往力不从心。一个 mashup 应用程序或页面必须处理跨站点请求伪造（Cross-Site Request Forgeries，CSRF）、Asynchronous JavaScript™ + XML (Ajax) 漏洞、跨站点脚本编写（XSS）和其他潜在的安全漏洞。
本文将探讨构建 mashup 应用程序和页面时应该解决的安全问题。
mashup 安全的必要性Mashup 应用程序和页面使用来自一个或多个内部和外部站点的数据和 UI 工件共同构建，它们的构建方式往往很特别。这种开发模型会导致安全漏洞成倍增加：每当向一个 mashup 添加一个新的工件或数据源，安全漏洞都会增加。这种开放性集成要求确保这些工件和数据已经针对恶意入侵进行了测试和保护。
Mashup 页面也可以用于其它 mashup 的组件或数据源，这使得准确预测 mashup 工件、页面和数据源未来的使用方式变得很困难。因此，您必须事先解决 mashup 中的组件和流程的安全问题。
用户输入安全如果使用一个综合的输入验证框架，许多输入漏洞，如 SQL 注入、CSRF 和 XSS，都是可以避免的。
一个 mashup 服务器端验证框架和一个 mashup 客户端验证框架应该在处理输入数据的方式上互相补充。由于客户端验证可以很容易地规避，因此，一个综合的、互补的服务器端验证为保护数据和流程提供了另一个关键组件。
一个有效的输入验证框架应当提供以下功能：

• 定义一个限制输入数据的有限值列表；
• 验证输入数据类型、数据长度、数据范围和数据格式；
• 在客户机和服务器上使用正则表达式以维护一个统一的验证模型；
• 审查输入数据中的无效字符。

避免按需脚本攻击许多 mashup 中使用的一种技术是嵌入可以根据需要动态下载和解释的 JavaScript 代码段。按需脚本可能包含打算攻击 XXS 等安全漏洞的恶意代码。通过确保按需脚本被验证并确保从那些脚本生成的内容被适当编码以阻止恶意代码的执行，您可以避免这类漏洞。 提供了一个未编码的标记示例。            
清单 1. 未编码的标记示例

1 2 3

<div> This is example content </div>

上述代码段的编码版本如  所示。
清单 2. 编码后的标记示例

1 2 3

<div> This is example content </div>

如上所示，使用动态生成的脚本的 mashup 页面必须确保一点：那些脚本生成的数据被验证并编码，以免浏览器将该数据解释为 HTML 标记或脚本代码。这种不小心的解释会导致恶意代码的执行和潜在的安全侵犯。
未经验证和编码的数据可能会遇到以下漏洞攻击：

• 数据完整性受损
• 入侵者创建或访问 cookies
• 入侵者截获并访问用户输入
• 恶意代码在一个受信任的域或上下文中执行

应该对每个被解释的上下文进行智能分析，以便可以处理那些会在特定上下文中导致问题的字符。