Thinking XML: 管理 XML 数据集的安全性

对安全性的需求教会了我们控制 XML 传输的重要性

大部分熟悉数据库技术的开发人员在使用 XML 时,都必须开始学习一种完全不同的技术。由于 XML 的透明性,当我们在网络上将 XML 公开给应用程序时,需要关注很多问题。这方面的粗心可能会导致安全性缺陷。在本文中我们将学习有关 XML 透明性的安全性问题以及如何避免这些缺陷。

Uche Ogbuji (uche@ogbuji.net), 首席顾问, Fourthought Inc.

Uche Ogbuji 的照片Uche Ogbuji 是 Fourthought Inc. 的顾问兼创始人,这是一家专为企业知识管理提供 XML 解决方案的软件供应商和顾问公司。Fourthought 开发了 4Suite,一种面向 XML、RDF 和知识管理应用程序的开放源码平台。Ogbuji 先生还是 Versa RDF 查询语言的首席开发者。他是一名出生于尼日利亚的计算机工程师和作家,目前生活和工作在美国科罗拉多州的博耳德。我们可以在 Ogbuji 的 Weblog Copia 上找到有关他的更多信息,或者通过 uche@ogbuji.net 与他联系。



2006 年 8 月 07 日

XML 在数据管理领域引进了一个有趣的观点,很多开发人员最初都会觉得它非常新奇。XML 对松耦合、结构化、层次化的数据提供了灵活的支持,但是它同时也带来了不可避免的性能问题。遗憾的是,开发人员通常都没有考虑到这些由于 XML 的透明性而产生的问题。一旦我们将某些内容加入 XML 文档,就很难不让其他人到这些内容(当然是缺少加密),这一点显而易见。它的可用性已经扩展到了所有内容都可用的程度。而显然许多开发人员在设计 XML 驱动的应用程序时未能很好地考虑这个问题,这令人十分担忧。2004 年 Sanctum, Inc. 的研究人员报告 Blind XPath Injection 时(一种缓慢简单但十分危险的攻击)认识到了这种漠视的危险。Blind XPath Injection 使攻击者(给定一个 XPath 引擎用来对 XML 文档进行查询)不需了解应用程序所使用的任何 XPath 查询的特定内容即可检索文档的所有内容。即使在应用程序的查询本身都受限于某个文档子集时,Blind XPath Injection 也可以工作。

很多 XML 应用程序都是在转储自数据库或遗留应用程序的原始 XML 基础上构建的。软件供应商在其指令系统中用单个 XML 转储大量 XML 特性,从而大力促进了这种方法的使用。使用 XSLT 可以将一种 XML 格式转换成另外一种格式的易用性导致了一种绅士哲学的出现:“将所有的东西都导出为 XML 格式,然后从中提取自己需要的东西”。问题在于这样就会对安全性问题(例如 XPath 注入攻击)大开方便之门。XML 并没有提供访问控制,因此威胁 XML 驱动的应用程序安全性的入侵者不仅仅会威胁到应用程序所关心的数据的安全性 —— XML 文档中的所有内容都是可访问的。如果应用程序构建于一个 XML 储存库上,情况就会更加糟糕,不过有些储存库的确提供了访问控制功能,这会降低此类缺陷的危险程度。在本文中,我们讨论了为了避免出现这种缺陷而对管理 XML 部署所采用的一些准则。这些准则都非常简单,但是 XML 专业人员们往往很少讨论这些问题。

彻底的文档透明性

2004 年出现的 Blind XPath Injection 的疯狂攻击强调了第一条准则的重要性:如果一个 XML 文档的任何部分公开给应用程序,我们就假设整个文档也公开给了这个应用程序及其用户,还包括其他所有与这个应用程序交互的程序图 1 阐述了这条准则。

图 1. XML 文档的间接公开
XML 文档的间接公开

箭头说明了数据的可用性。组织结构图应用程序是企业的内部应用程序,受到防火墙的保护。您可以假设所有直接访问的用户都是受信任的(即使对内部应用程序来说,这也是一个天真的假设,但是在本场景中这样假设已经足够了)。这个组织结构图应用程序访问了一个员工信息的 XML 转储。这个 XML 文件包括了诸如员工名、部门和社会保险号码之类的信息。这个应用程序在对源文件进行的 XPath 查询中只使用了员工名和部门信息。联系列表应用程序在防火墙之外,因此受信任的用户和不受信任的用户都可以连接到这个应用程序。它提供了主要员工的联系信息,为了避免静态信息陈旧的问题,它通过防火墙中一个受控的通道动态连接,从而对组织结构图应用程序进行查询。通过 Blind XPath Injection 攻击,攻击者可以访问 XML 所转储的全部内容,包括这个组织结构图应用程序没有直接访问的社会保险号码。在图中,您可沿着箭头的指向从外部用户到达 XML 所转储的内容,这一事实展示了这个问题的确存在。

从安全性的观点来看,这个准则的主要推论是我们需要理解 XML 驱动的应用程序彼此是如何连接的,以及它们如何连接到这个链条所涉及的 XML 文件的全部内容。警惕性是我们的第一道防线,每个安全计划都应该包括对这些透明数据可达性的重新审视,并考虑各种可以扩充这种可达性的隐性方法。

“需要了解” 的 XML 文档部署

一种保护在文档透明性基础上构建的敏感数据免受攻击的方法是通过加密部分 XML 文档来降低透明性。在 上一节 所讨论的场景中,您可能具有与该组织结构图应用程序相同的源 XML 文档,但对社会保险号码信息进行了数字加密。这只是一种局部解决方案,因为通常在这种情况中,需要使用这些信息的应用程序都可以访问读取这些信息所使用的证书,这仍然是窃听数据的一个潜在媒介。在进行 XML 部署时,采用 “非全即无” 的方法更加安全。最好的方式不是通过在各个域和应用程序之间共享 XML 数据集来简化问题,而是按照严格的 “需要了解” 准则为每个应用程序都部署一个经过裁减(符合它们要求)的数据集,这就是第二条准则的思想:应用程序可以使用的 XML 源文档应该只包括应用程序自身工作所需要的信息图 2 展示了适用这条准则的一种场景。

图 2. 根据 “需要了解” 的准则对 XML 文档进行裁减
根据 “需要了解” 的准则对 XML 文档进行裁减

在此场景中,我们仍然要使用从数据库中转储的 XML 文档,但是应用程序已经不能再直接访问整个文档了,这一点我们通过表示访问权限和可用性的箭头方向就可以看出。这些应用程序采用了一个单独的自动化过程(应用程序中的 “XML 裁减器”)来为每个应用程序生成一个 XML 子集文件。这些子集文件只包含了应用程序需要知道的信息。理想情况下,每个应用程序都应该可以只注册自己需要的 XPath 查询,裁减器只会参考这个查询清单来指导自己的子集生成过程。在这种情形中,每个应用程序都是与完整的数据集隔离开来的,这会减少意料之外的信息泄漏的范围。从任何意义上来说,这并没有完全解决 XML 透明性所引起的全部安全性问题。首先,我们可能希望进一步将每个用户会话可用的信息都限制在一个应用程序之内。即使我们使用了 “需要了解” 的模式使恶意用户无法访问社会保险号码,但是其他用户可能仍然具有对应用程序使用的信息的不同级别的访问权限。使用这个应用程序的人力资源经理也许有权访问员工的工资信息,而其他用户则不能。为了避免由于文档透明性而产生的信息泄漏问题,您最终可能需要使用按照用户会话来隔离 XML 数据集的 “需要了解” 的系统,而不仅仅是按照应用程序来隔离 XML 数据集的系统。随着这种系统越来越复杂,我们可能会发现整个结构极为困难,如果不够谨慎,就很难维持有效的安全性检查。


以管道架构为基础进行构建

处理复杂数据流的难度导致了第三条准则的出现:围绕 XML 处理管道来设计应用程序,从而让数据流更容易进入安全威胁评估。XML 管道架构是将有效的 XML 数据流当成一系列定义良好、较小的处理阶段(主要是转换)的思想。如果我们着眼于如何合并一系列范围较窄的模块来满足 XML 的数据需求,就可以避免使用功能等同、填满小段代码的大代码块。XML 管道处理的内容很多,这方面的内容极其重要,以至于 W3C(World Wide Web Consortium)已经成立了一个工作组,专门负责标准化 XML 处理管道技术。管道架构在管理 XML 透明性所带来的问题时是一种重要的工具。它归纳出很多小问题,例如从哪里可以访问哪些数据,哪些数据容易受到攻击。同时也简化了诸如 “需要了解” 之类的策略的组织,即使在划分成细粒度的情况(例如保护用户会话间的数据)时也是如此。总之,管道方法不隐藏 XML 数据的透明性,而是试图摆脱安全性问题。为了维护所有数据在 XML 应用程序之间流动的透明性,它反而会全力支持这种透明性。这种透明性让我们可以观察到潜在的安全威胁并对其进行评估,从而确保我们不会天真地依赖于通过隐藏获得的安全性。


结束语

良好设计之于安全性就像是良好设计之于软件质量。组织在一起的东西越多,发现和防止问题就越困难。XML 数据所带来的透明性要求应用程序的处理工作流的透明性也相应增加,从而减少从安全性到状态控制方面的问题。使用大量 XML 数据转储、使用必需这些数据集中的信息的复杂处理的应用程序对于善于利用您的盲点的老练攻击者来说不堪一击。如果我们将应用程序设计为只在便于管理的处理阶段中打包和交换少量 XML 数据,那么就可以减少这些盲点,使应用程序更易于维护。理解透明数据流的牵涉对于基于 XML 的应用程序的安全性来说至关重要。

参考资料

学习

获得产品和技术

  • 在您的下一个开发项目中采用 IBM 试用软件,这些软件可以从 developerWorks 上直接下载得到。

讨论

条评论

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=XML
ArticleID=152985
ArticleTitle=Thinking XML: 管理 XML 数据集的安全性
publish-date=08072006