Web 2.0 工具正使工商界和个人私生活中的在线协作机会不断增加。如果应用程序没有针对漏洞进行有效保护,那么协作工具使用率的提高意味着风险的提高。这种保护有一部分源于良好的可抵御攻击的设计和编码技巧。另一个因素就是用户与服务提供者的合约或者服务水平协议 (SLA)。在本文中,我将分析一些已知漏洞,向您展示一名开发者和用户如何保护自己。

Judith Myerson, 系统工程师兼架构师

Judith M. Myerson 是一位系统工程师兼架构师。她擅长的领域包括中间件技术、企业级系统、数据库技术、应用程序开发、网络管理、安全性和项目管理。


developerWorks 投稿作者

2009 年 10 月 21 日

简介

在本文中,我将向您展示为什么使用 Web 2.0 工具进行在线协作会越来越流行,这种协作会带来哪些可能被黑客利用的漏洞。我将介绍如何通过识别资产、评估漏洞并在可能处实施安全措施,以缓解或消除漏洞。我将重点以 SQL、XML 和 Ajax 注入漏洞为例,说明如何修复它们,使您能够保证达到服务水平协议 (SLA) 中的正常运行时间。

在线协作

基于 Web 的协作在许多组织中都借由 Web 2.0 工具(例如在线会议、社交网络、博客、wiki、书签、论坛、播客等等)得到促进,这些工具彻底改造了人们在 Web 上的互动方式。您能使用 RSS feed 来浏览最近的文档,以便经理、系统工程师、系统架构师和潜在客户进行分组讨论。使用这些工具,就能改进客户服务,而且您能在较短时间内完成更多工作。

简易漏洞评估

如果您已经拥一些可以在复合应用程序中重用的组件,那么在线协作开发项目就可以很简单。这些协作工具中许多都基于开源软件,并且分布广泛。

然而,这些环境的宿主和安全措施可能多种多样。开源就意味着有许多双眼睛盯着代码寻找漏洞,但您必须考虑:您使用的组件是否足够成熟或足够普及,可接受那种程度的详细审查?通过 Internet 利用多种不同组件进行工作,就会有一些信息可能要通过不安全的渠道来传输。这些都是易受黑客及其他入侵者攻击的漏洞。要缓解这种漏洞,您需要执行漏洞评估。在您执行漏洞评估之前,一定要确立一条安全策略。

让我们看看简易评估的要素:

  • 识别关键系统资产
  • 评估漏洞
  • 确定资产更换成本
  • 实施安全措施

第一步表示您需要识别(有形或无形的)关键系统资产,这些资产罪可能受到恶意攻击。

有形资产是您能够看到、感觉到或接触到的对象。它可能是人力资源,例如您的 WebSphere Web 开发系统管理员。可能是一款软件,例如您用于开发在线协作项目的工具。还可能是硬件,例如服务器、网络基础设施等等。

无形的资产是您不能看到、感觉到或者接触到的对象,但它仍然有价值。例如,您通过协作而交换的信息就是无形资产。

识别了所有要评估的资产之后,下一个步骤就是识别并评估每种资产可能被黑客或攻击者利用的漏洞。接下来您确定每种有形资产在特定时期内(通常为一年)的更换成本。威胁的发生可能要利用多于一个漏洞。针对每种威胁,您应当为每种资产指定风险影响评级。

最后,您要确定可能的处理办法和安全措施,例如在线协作的非现场备份。您的目标是将漏洞被利用的风险减轻到可接受的程度。确保获益要超出或等于安全措施的成本。如果成本过高,您的在线协作项目也许最终要残留一些风险。

复杂漏洞评估

如果在线协作开发项目是复杂的(例如从头开始开发),您能够扩充步骤:

首先识别与开发项目相关的(有形和无形)资产,并为之划分优先级。整理资产之后,您可按照常规来识别和评估漏洞。如果任何资产的漏洞在另一次预计评估时间之前发生变化,则重复前两个步骤。

接下来,根据您的安全策略,度量与您的资产相关的业务风险级别。在评估漏洞之后,根据业务风险为其划分优先级。始终要验证所实施的安全措施实现了通过跟踪审计的目的。在初始评估中经济有效地实现的安全措施可能需要替换为更佳方案,以节省资金。上一次评估完成以来,出现了更新的技术,许多事物可能产生了改变。

协作漏洞

在线协作漏洞的范围取决于项目复杂程度、与相似项目的相互关系以及是否存在合适的安全策略。在本文中,我将重点介绍这些可利用来影响 SLA 中正常运行时间有效性的漏洞。它们是 SQL、XML 和 Ajax 注入漏洞。我们将着眼于您如何找到包含这些漏洞的代码行,并且消除漏洞,以便维持长久的正常运行时间。

代码中的问题修复后,您还需要考虑中断阈值(interruption thresholds)。中断阈值即为发起信息请求的时间和发送对该请求的回复的时间之间的距离。如果时间间隔较大,则中断阈值可能达到可被黑客利用的程度,于是对正常运行时间有效性造成不利影响。有时这仍然是编码问题。您也许需要调整信息发送方式。也许需要修改格式,或者以较小的字节片来处理信息。有时这些问题很简单,只需升级硬件,或者确认您正在运行的软件安装了最新补丁或版本。

SQL 注入

SQL 注入仍然是最常见的一种注入缺陷。黑客可以使用这种攻击技巧来检索、破坏或删除数据。他能够无预警地关闭在线协作,使会议参与者无人理会。他还能在没有任何一方发现的情况下获得机密信息。

下面是 SQL 注入的工作方式:首先,假设一条 SQL 语句接受用户提供的数据,没有输入确认规则就可在数据库中查找团队成员的联系信息。攻击者将其恶意输入注入到 SQL 语句中,以修改查询语句的逻辑。他使用 SQL 语法连接字符串,并添加自己的数据。

关闭的情况

如下例所示,在此情况下,查询语句获得用户的名称和电子邮件地址。

清单 1. 无输入确认规则的查询字符串
dim strQuery as String
strQuery = "SELECT NAME, EMAIL from users WHERE userid * + Request.QueryString ("userid")"

所示查询语句不包含输入确认规则。当黑客提供数据时,查询语句不会检查 userid 参数是否有效。

例如,如果黑客输入 “42; SHUTDOWN WITH NOWAIT” 作为其 userid,那么他可修改查询字符串如下:

清单 2. 含有恶意代码的查询字符串
SELECT name, email FROM users WHERE userid=42; SHUTDOWN WITH NOWAIT

如您所见,黑客将恶意代码作为其 userid 输入,修改了查询语句的逻辑。查询语句不会检查输入是否有效。

源代码分析

要发现任何 SQL 注入问题,可执行源代码分析。这种方法将帮助您删除存在漏洞的代码行,即使在存储过程中。

要防止黑客利用该漏洞,您不仅必须重构带有输入确认的查询示例,还必须确保黑客不能登录。没有输入确认规则,黑客就很容易操作一条查询字符串,于是能关闭在线协作 Web 页面。

XML 注入

XML 注入是较新的一种攻击。Xpath 和 Xquery 都提供了这种方法用于查询 XML 文档。很容易使用上文 SQL 注入中所示的相同技巧来攻击之;数据存储区刚好是 XML 文件而不是实际的数据库。

和 SQL 注入一样,黑客很可能操作一条 XML 查询语句来删除或破坏数据,或者导致在线协作服务没有等待期就关闭。

随着 Ajax 门户和 Web 服务的使用增多(这两者都严重依赖于处理 XML 数据流),XML 注入日益流行。当这些 Web 服务异步连接到 Ajax 门户,而黑客可能在门户提供恶意代码输出,XML 注入就成为重要问题。

和 SQL 注入中一样,源代码分析是消除漏洞的唯一真实方法。您又将需要利用有力的输入确认规则来重构查询示例,并确保黑客不能使用恶意 userid 登录。

Ajax 注入

Ajax 注入也是新漏洞的一种。虽然它目前并不常见,但随着 Ajax 门户愈加流行,它也将变得频繁。在客户端,Ajax 包含 JavaScript 和一个 XML 框架。因为 JavaScript 的性质,黑客能轻易在他选择的浏览器中查看源代码。但对黑客而言,要查看服务器端脚本源码依然比较困难。

问题是,为追求性能,开发人员倾向于在客户端存储越来越多的数据(通常是敏感数据)。他们也许没意识到,黑客能访问所有数据和功能,包括将恶意代码注入到客户端 Ajax 脚本中,随之就可与服务器处理请求相交互。

您应该将数据存储到服务器上的数据库中。如果数据必须存储在客户端,那么它应当在服务器上有副本。当服务器获得信号指出客户端数据被破坏或者受到威胁,它可将一份存储数据发送给客户端。这允许客户端和服务器之间的正常运作继续进行。

随着攻击的进化,将会有工具辅助代码分析,代码分析可提供信息以帮助您找到存在漏洞的代码行。您必须当心将数据保存在客户端会将函数暴露给能够获得数据的黑客。您还能使用诸如 HTML Protector 或 HTMLGuardian 等商业工具来混淆客户端应用程序的源码,但这也许只能减慢黑客入侵速度而不能阻止他。 混淆 HTML 也不会被搜索引擎读取。最佳的解决方案是使客户端不包含您不需要的其他信息,并且对去往或来自客户端的信息进行常规验证。

以 SLA 结尾

最后,在您完成了能对资源进行的所有处理之后,您进入最后一级保护 —— SLA。为拥有准确的 SLA,您应当对解决方案进行足够测试。除了响应时间,您还应当测试访问、超时和版本。测试访问将帮助您查明一名未授权用户是否能够成功访问一个只有管理员有权使用的控件。测试超时将帮助您查明在一段特定静止期之后如果协作超时会发生什么。测试版本将有助于查明协作服务的一个新版本是否会破坏现有协作服务的功能。

如果您的角色是 SLA 涉及的服务提供者,代码行中包含 SQL、XML 和 Ajax 注入漏洞的一条或多条语句已从您的软件工具中消除。

如果在一段规定时期之后不再保证正常运行时间有效性,那么将提供信用服务,以下情况除外:

  • 诸如软件监控/测量系统故障等故障,和电信软件
  • 不受服务提供者直接控制的网络问题
  • 计划维护,例如软件更新和定期备份
  • 由于客户疏忽或故意进行不当处理、网络高峰或其他不可抗力而拒绝服务

如果您对协作软件执行了全面的测试,清除了包含漏洞的代码行,并替换为包含有利的输入确认规则的代码,那么您很可能不需要提供信用服务。不论漏洞是在存储过程中或是在客户端源代码中都是如此。尽可能加密您的资源和数据。您使用何种技术无关紧要 —— 无论 Java EE、ASP.Net 或 PHP。

结束语

本文通过展示如何查找并清除代码和基础架构中的缺陷、建议您与可支持您的工作的客户和服务提供者达成牢固协议,从而帮助您作出计划以减少在线协作漏洞。用户要求在 SLA 中保证持续的正常运行时间有效性,这对开发人员、业务分析师、系统管理员和项目团队其他成员提出了挑战。保护您的应用程序这一任务永无终结。新技术和技巧需要您持续重构选项,从而找到新缺陷和改进的解决方案。致力于将漏洞保持在可接受的业务风险级别,这可使您的团队避开麻烦。

参考资料

学习

获得产品和技术

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Web development
ArticleID=438715
ArticleTitle=减少在线协作漏洞
publish-date=10212009