英语原文共 20 页
用于Web服务的安全中间件体系结构
Lenin Singaravelu, Jinpeng Wei, Calton Pu
佐治亚理工学院计算学院
{lenin, weijp, calton}@cc.gatech.edu
摘要：当前的Web服务平台（WSPs）通常在同一保护域中执行所有与Web服务相关的处理，包括安全敏感信息处理。因此，整个WSP可能会访问信用卡号等安全敏感信息，迫使我们信任大型复杂的软件。为了解决这个问题，我们提出了ISO-WSP，这是一种新的中间件架构，可将当前的WSP分解为在不同保护域中执行的两个部分：（1）用于处理安全敏感数据的小型可信T-WSP（2）一个大型、传统的不受信任的U-WSP，提供正常的WSP功能，但使用T-WSP进行安全敏感的数据处理。通过限制对T-WSP的安全敏感数据访问，ISO-WSP降低了可信代码的软件复杂性，从而提高了ISO-WSP的可测试性。为了实现端到端的安全性，应用程序代码也分解为两部分，将小的可信部分与剩余的不可信代码隔离开来。可信部分通过安全功能接口（SFI）封装对安全敏感数据的所有访问。为了简化遗留应用程序向ISO-WSP的迁移，我们开发了一些工具，用于将不受信任的部分对安全敏感数据的直接操作转换为SFI调用。使用基于Apache Axis2 WSP的原型实现，我们可以看到ISO-WSP将可信组件的软件复杂性降低了五倍，同时每个请求的性能开销仅为几毫秒。我们还展示了，现有的应用程序可以迁移到ISO-WSP上运行，只需很少的工作量：几十行新代码和修改代码。
关键词:Web服务中间件，安全性，TCBs。
1 介绍
面向服务的计算（最近也称为“服务计算”）旨在支持快速创建可跨越多种组织和计算平台的新增值应用程序和业务流程。具体而言，Paypal的Web服务，eBay开发人员计划和Amazon Web Services是用于关键任务，安全敏感和真正大规模应用程序的Web服务的说明性示例。尽管广泛部署了Web服务，但仍然存在重大的研究挑战。本文关注的是在服务计算中保护安全敏感信息。
Web服务平台(WSPs)，例如Apache Axis2，Microsoft .NET和IBM WebSphere，提供了诸如SOAP消息传递等基本功能，并支持发布和发现Web服务。此外，WSP还提供了理想的功能，例如支持web服务组合、原子性和消息可靠性。对如此庞大和多样化的功能的支持增加了当前WSP的规模和复杂性;例如，开源Axis2 WSP及其扩展占了超过11万行代码(LOC)。
当前的WSP通常在同一保护域中执行所有类型的处理，包括安全敏感信息处理。因此，WSP的所有组件都可能直接或间接访问敏感数据，违反了最小权限原则[23]。此外，WSP的庞大规模和复杂性阻碍了它们的可测试性，导致系统具有多个安全漏洞[6,7]。因此，即使安全敏感应用程序采用SSL，TLS和WS-Security等协议，攻击者也可以通过利用大型WSP中的漏洞来破坏敏感信息的流动。
我们提出了ISO-WSP，这是一种用于Web服务的中间件体系结构，用于解决保护安全敏感信息流的问题，以防范大型复杂软件包（如WSP）中固有的潜在漏洞。应用AppCore方法[24]，ISO-WSP将当前的WSP分解为两个部分：一个小型的、功能有限的、可信赖的T-WSP和一个功能丰富、不可信的大型U-WSP。T-WSP由需要访问安全敏感信息的WSP组件组成，U-WSP包含其余的传统WSP。T-WSP和U-WSP在单独的保护域中执行，U-WSP在必须对安全敏感数据进行操作时调用T-WSP。通过限制对小型T-WSP的安全敏感数据访问，ISO-WSP消除了对U-WSP的信任。由于预计T-WSP比U-WSP小得多，因此我们提高了ISO-WSP的可测试性。
为了实现端到端的安全性，AppCore方法还将应用程序代码分为两部分，将一个小的可信部分与剩余的不可信代码隔离开来。通过安全功能接口将所有安全敏感数据重新分配到安全敏感数据的受信任部分。如果应用程序的不受信任部分要对安全敏感数据进行操作，则必须使用此接口。为了简化遗留应用程序向ISO-WSP的迁移，我们开发了将安全敏感数据的直接操作转换为SFI调用的工具，消除了不受信任部分对安全敏感数据的所有访问。
通过实现和评估基于Axis2 WSP的ISO-WSP来证明我们的方法的可行性。我们展示了ISO-WSP使能够访问敏感数据的软件的大小和复杂性减少了5倍，同时每个请求的开销适中，只有几毫秒。我们还展示了现有的应用程序可以通过添加或修改几十行代码移植到ISO-WSP。
本文其余部分的组织如下:第2节首先详细介绍了WSP的设计，然后讨论了当前WSP存在的安全问题。第3节讨论了ISO-WSP的设计，第4节讨论了对ISO-WSP体系结构的应用层支持。第5节描述了基于Axis2 WSP的ISO-WSP体系结构的实现，并对得到的系统进行评估。第六部分对相关工作进行了论述，第七部分对本文进行了总结。
2 动机
我们首先讨论W3C指定的Web服务平台（WSP）框架。具体而言，我们还介绍了Axis2 WSP的设计，这是Web服务框架的一个特定实现。基于这些知识，我们讨论了当前WSP中的安全问题。为清楚起见，我们提供了本文中使用的术语的定义：
机密性：只有授权实体才能访问数据。
完整性：只允许授权实体修改数据，并且可以检测未经授权的实体的任何修改。
安全敏感（或）敏感数据项：最终用户或业务逻辑强加机密性或完整性要求的任何数据项称为安全敏感性，例如支付信息，患者健康信息。敏感数据项还包括可能不通过网络传输的数据项，例如WSP使用的私钥。
2.1 Web服务平台的设计
W3C的Web服务体系结构规范[9]规定了WSP的基本框架。WSP中的Apache Axis2和Microsoft .NET等实现了这个框架。该框架由三个实体组成：服务提供者，客户端和Web服务发现机构。WSP用于调解三个实体之间的交互，这需要支持三种基本功能类：交换消息，描述Web服务以及发布和发现Web服务描述。由于本文论述了服务提供商与客户之间信息交换的安全性，因此我们专注于第一类功能：支持消息交换。
图1给出了Web服务堆栈的一个视图，如W3C的规范[9]所示。所有WSP都必须实现传输协议（通常为HTTP），并为消息打包机制（通常为SOAP）提供支持。WSP还可以选择支持其他邮件打包和传输机制，比如SMTP上的MIME。除基本功能外，WSP还必须支持路由，事务支持，消息可靠性，安全性和服务质量等功能。W3C还以WS- *扩展的形式标准化了许多类型的附加功能，例如WS-Addressing，WS-Security等。表1列出了一些WS- *扩展，并简要描述了每种扩展的功能。WSP还可以拥有扩展架构，以无缝集成新的和即将推出的WS- *规范，或者为日志记录或负载平衡提供自定义扩展支持。
Apache Axis2 WSP[20]是web服务框架的一种实现。我们在分析中使用Axis2 WSP，因为它不仅被广泛使用，而且在开放源码许可下也可用，这使我们能够更清楚地了解其工作原理。Axis2支持开发、部署、管理和调用web服务。此外，在功能上，
图1. Web服务堆栈。来自W3C的Web服务架构规范[9]。
图2. Apache Axis2中的SOAP处理模型。
表1.一些WS- *扩展的列表以及它们各自提供的功能[4]
扩展 功能
WS-Addressing 提供统一的命名方案来解决端点问题。
WS-Security,WS-Tru,
保护消息并在不同域之间建立信任。
WS-SecureConversation, ...
WS-AtomicTransacti,
Web服务的事务支持
WS-Coordination, ...
WS-ReliableMessaging 支持通过不可靠的通信可靠地传递消息
WSDL, WS-Policy, ... 支持客户端之间的元数据描述和交换
WS-Eventing Web服务的事件驱动编程支持
Axis2还支持使用许多WS- *扩展，例如WSSecurity和WS-ReliableMessaging。由于我们主要关注Web服务请求和响应的处理，因此我们关注Axis2的SOAP处理模型[2]。图2说明了Axis2 WSP中Web服务请求或响应的SOAP处理链。Axis2使用两个基本消息处理序列处理所有消息交互：分别在传入和传出消息的管道和输出管道中。由于两个序列的基本结构相似，我们使用In Pipe作为说明性示例。
传输侦听器首先接收传入的Web服务请求。Transport Listener创建一个消息上下文并启动In Pipe，它由一系列处理程序组成。首先，传输处理程序用于验证传输协议头，并使用来自消息的数据填充消息上下文。接下来，处理程序用于处理寻址标头并确定目标服务。在此之后，执行用户指定的处理程序以执行诸如安全处理，事务支持或可靠消息传递支持之类的任务。最后，将消息反序列化为语言级对象，并将其提供给执行业务逻辑的Web服务实现。
Axis2使用处理程序来实现和支持各种类型的可选功能。例如，处理程序用于支持许多WS-*扩展，如WS-Security和WS-Addressing。此外，Axis2允许自定义处理程序执行特定于Web服务的非标准任务，例如准入控制，负载平衡或日志记录。
2.2 Web服务平台中的安全问题
WS-Security规范[5]旨在保护Web服务中信息流的机密性和完整性。但是，可以通过利用端点软件中的漏洞绕过基于WS-Security的保护。在服务器端，攻击者可以通过利用服务器软件中的漏洞来破坏信息流：操作系统，Web服务器，WSP [6,7]或业务逻辑及其支持软件（例如，数据库软件）。同样，在客户端，攻击者可以利用客户端WSP或客户端应用程序（如浏览器）中的漏洞。我们专注于在本文中保护WSP。保护操作系统，支持软件和应用程序（如浏览器）不在本文的讨论范围之内。
从安全角度来看，WSP实现有两个重要问题。首先，在组件级别，WSP违反了最小特权原则（PoLP）。PoLP声明组件应该使用完成作业所需的最少权限集来执行。WSP包含许多不需要访问敏感数据的组件，例如传输协议实现和WS-*扩展（如WS-Addressing）。但是，所有这些组件都在相同的地址空间和相同的保护域中执行。因此，他们可以直接访问安全敏感数据，也可以通过修改安全处理参数和破坏安全敏感数据来修改WS-Security处理。
具体而言，在Axis2 WSP中，所有处理程序都在与WSP的其余部分和应用程序级代码相同的保护域中执行。因此，不需要访问敏感数据的处理程序可以直接访问（读取消息内容）或间接访问。例如，给定服务的所有Axis2处理程序都可以访问包含WS-Security处理参数的服务上下文。因此，行为不当的处理程序，即使是那些对加密数据进行操作的处理程序也可能通过改变WSSecurity处理参数来损害信息流，例如，通过指定使用弱加密密钥。
其次，WSP是一个复杂的软件。如前所述（第2.1节），预计WSP将执行大量任务。不出所料，它们包含大量代码库。此外，由于WSP必须是可配置和可扩展的，因此它们通常还具有配置文件，扩展架构和多个扩展。具体而言，仅Axis2 WSP包含约23.5 KLOC。与多个WS- *规范的实现一起，WSP包含超过110个KLOC。此外，程序员可以编写自定义处理程序来执行其他类型的处理，如负载平衡或准入控制。这些组件增加了系统的复杂性。鉴于代码库较大且这些组件可以通过多种方式相互交互，因此无法详尽地测试WSP的组件，尤其是作为一个完整的系统，并消除所有漏洞。此外，WSP的可配置特性意味着可以在运行时添加，启用和禁用扩展，这进一步使WSP的分析和测试变得复杂。
3 ISO-WSP
为了解决第2.2节中讨论的安全问题，我们提出了一种新的Web服务安全中间件架构。这种称为ISO-WSP的体系结构将WSP分为两部分：一个小的可信任T-WSP和一个遗留的，不可信的U-WSP。T-WSP由需要访问纯文本敏感数据的组件组成。U-WSP包含传统WSP的其余功能，并在需要处理安全敏感数据时调用T-WSP。ISO-WSP管理信息流，使得纯文本格式的敏感信息仅供T-WSP使用。然后，T-WSP和U-WSP在单独的保护域中执行，U-WSP作为较低权限进程执行。
ISO-WSP架构有三个好处：首先，通过将安全敏感信息的访问限制为需要访问的组件，ISO-WSP解决了PoLP问题。其次，只有T-WSP必须经过测试或验证，以确保敏感数据的安全性。由于预计T-WSP小于完整的WSP，因此ISO-WSP减小了可信组件的大小，使得详尽的测试或形式验证更加可行。最后，通过重用U-WSP来操作非敏感或受保护的数据，ISO-WSP还确保保留典型WSP所需的大部
资料编号：[3922]
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
