英语原文共 7 页

基于Java EE Web模型的安全配置分析

摘要:Java EE Web应用程序被广泛应用于向远程客户端提供分布式服务的手段，而在使用中加强了安全性要求，因此这些应用程序管理的资源仍受到保护，不会受到未经授权的操作调用。为此，Java EE框架为开发人员提供了定义访问控制策略的机制。不幸的是，所提供的安全配置机制由于其多样性和复杂性，安全策略的定义和操作变得复杂且容易出错。同时由于网站安全要求不是静态的，因此必须经常更改和审查已实施的安全配置，配置合适的抽象化概念和策略的理解在配置过程中成为关键要求。为了解决这个问题，本文提出了一种基于模型的方法，旨在帮助安全专家可视化此问题， 从而分析和处理Web安全策略。

关键词:安全，访问控制，逆向工程

1 引言

Java EE是动态Web应用程序开发的首选流行技术，也是其他的框架的基础层。 Java EE有助于将分布式信息和服务提供给远程用户。因为构成Web应用程序的Web资源可能会被许多用户通过不受信任的网络访问，在这种情况下，安全性变成了一个主要问题。因此，Java EE框架为开发人员提供了指定访问控制部署的工具，以确保Web应用程序中所公开的资源的保密性和完整性。

遗憾的是，尽管存在这些安全机制，实施安全配置仍然是一项复杂且容易出错的任务，需要深奥专业知识来避免出现不一致和错误配置问题，这可能会造成严重的业务损失。由于Web应用程序管理的资源可以被许多用户使用未受保护的网络访问。无意间的数据披露可能会导致金钱和声誉方面的重大损失。

对于Java EE应用程序中访问控制的具体情况，可以通过使用具有两种基于不同的规则的较低级的语法和相对复杂的执行语义。具体地说，用户可以：

1.在XML Web描述符文件中使用一些预定义的元素来编写约束。

2.在Java Servlet组件上编写注释（语法和结构与XML所标记的元素不同）。

这两种机制都可以在同一Java EE应用程序中使用，因此需要使用相结合的规则来获取最终的安全策略。在这种情况下，发现和理解所给定Web的应用程序是实际执行的安全是布置的一项关键要求。这一发现过程面临的主要挑战是缩小低级的分散的政策表现形式与更高层次更易于理解和操纵的综合表现形式之间的差距。为了解决这个问题，我们为Java EE Web应用程序提供了以下功能：

1.Java EE框架提供的两种声明性约束规范机制的语言必须统一，以便可以通过相同的方法和工具分析这两种机制的贡献。

2.逆向工程过程，提取使用各种Java EE机制中已实现的安全配置，并将它们整合到相对应的Web安全元模型中。

3.使用基于模型的集成来演示应用程序和优点，这使我们能在安全域中使大量的模型驱动技术和工具可视化，从而分析，演化该模型等。

我们的方法补充了跳过现有的安全性方面Java逆向工程。通过原型工具实现证明了我们的方法的可行性，并将其应用于可用的GitHub真实Java EE项目样本中。

本文的文章结构如下：本文总共有八节，第2节介绍了Java EE框架提供的各种访问控制机制；第3节介绍了从中提取集成模型表示的方法；第4节描述了许多相关的应用场景；第5节提供了对该方法的评估；第6节中提供了我们为实现自动化而提供的工具支持的简要说明。 我们在第7节中讨论相关较为具体的工作；并在第8节中提供未来的研究路线和结论。

2 JAVA EE WEB安全

粗略地说，在Java EE框架中，当Web客户端发出HTTP请求时，Web服务器会将请求转换为可以直接应答HTTP Servlet调用的Web组件（如Servlet和Java Server Pages），或者反过来调Enterprise Java Bean（EJB），以执行较为复杂的业务逻辑操作。在此模式中，一个非常重要的要求是确保Web应用程序所管理资源的机密性和完整性。同时，Java EE框架提供了随时可用的访问控制布置。在下文中，我们将简要描述Java EE为Web应用程序实现访问控制部署所提供的机制。

2.1 访问控制

Java EE应用程序通常由JSPs和Servlets构成。现有的访问控制机制负责控制对这些元素以及对任何其他Web存储和可访问的文件的访问（纯HTML页面，多媒体文档等）

可用于规定安全策略的两种模式：辅助文件声明和程序性安全性准则模式，后者适用于需要更为详细的访问控制（需要对用户环境进行评估）的情况。

关于辅助文件声明访问控制策略，可以使用两种备选方案：（1）编写安全约束，使用便携式部署描述符（web.xml）; （2）编写安全注释，作为Servlet Java代码的一部分（注意：并非所有安全配置都可以通过注释指定）。

同时考虑一个关于公司Web应用程序，该应用程序针对员工有限制功能，并且定义了Employee角色。代码1表示了web.xml描述符中对于安全约束的描述。当使用HTTP方法GET时，程序给持有Employee角色的用户对于员工可访问区域限制的权限。

它包含三个主要元素：Web资源集合，指定受安全性约束影响的资源的路径以及用于该访问的HTTP方法（在这种情况下是re-Stricted/employee路径和GET方法）; auth-constraint声明管理角色访问资源和用户数据约束，用于确定用户的数据必须从Web应用程序传输到Web应用程序，示例没有进行限制（即接受任何类型的传输）。

通过注释定义的等效安全性约束如代码2所示。@WebServlet注释标识了Web容器中的Servlets和资源路径。然后，主要的安全注释是@ServletSecurity，它有两个属性：value，对应于嵌套注释@ Http- Constraint，httpMethodConstraint包含嵌套的@HttpMethodConstraint注释列表。 @HttpConstraint用于表示要应用于所有HTTP方法的安全性约束，第二个用于定义每HTTP方法约束。@HttpConstraint和@HttpMethodConstraint都包含允许角色列表（allowedRoles），数据保护要求（相当于web.xml中的user-data-constraint元素）以及允许角色列表时的行为为空。

2.2 政策和规则组合

上述两种声明性替代方案可以同时使用，最终的安全策略是将两种机制指定的安全性约束相结合的结果。但是，如果发生冲突，Web.xml中文件约束优先，而且，如果在Web.xml描述符中建立了约束，则可以完全忽略注释定义的约束，因为metadata-complete参数设置可能会给非专业人员带来困惑。

此外，使用上述机制定义的访问控制策略可能包含不一致性（规则指明同一资源的不同访问操作）。通过使用Java EE Servlets规范中定义的规则优先级，执行语义和组合算法来解决这些不一致性。遗憾的是，虽然此过程消除了策略中的不一致性，但它可能会引入典型的访问控制异常，例如重复、冗余以及特定于Java EE访问控制的其他配置异常。

请注意，如上所述，也可以在更为详细的在Java EE框架中定义上下文信息的访问控制约束。这些约束不能以声明方式定义，并且需要编程。例如，约束检查用户是否拥有两个角色，或者只能在特定时间段接受连接。我们将这些较为详细的程序性约束分析作为未来的工作。另请注意Java EE中尽可能优先使用声明性安全性措施。

3 方法

我们的方法（如图1所示）通过将数据提取到模型中来收集Java EE应用程序中包含的安全性信息。 然后，将它们统一并集成到特定于域的模型中（通过模型转换），以便稍后可以在其上应用模型操作，查询操作，分析和管理安全配置。 域的元模型和提取过程在本节的其余部分中描述。

3.1 元模型

在提取过程之前，需要能够准确表示配置源文件中包含的信息的元模型的定义。图2中描述的Servlet访问控制安全元模型（以下称为Servlet安全元模型）便是用于此目的。注释和XML安全定义共享相似的语义，因此可以映射到这个元模型抽象语法，允许我们直接从他们的低级模型表示（Java模型和XML模型，已经在MoDisco框架[3]中可用）到我们的安全元模型，无需为其代表定义中间特定的安全元模型。

Servlet安全元模型允许在给定的Web应用程序中处理安全角色（SecurityRole类）和安全性约束（SecurityConstraint类）。前者指定安全策略定义的安全角色。后者用于表示访问控制约束，如来自XML Web描述符或Java注释（源属性）。每个Web资源集合都标识为应用安全性约束的资源（urlPattern属性）和HTTP方法（HttpMethod类）。

重要的是要注意，如果HTTP方法被定义省略（省略属性），则安全约束适用于除省略方法之外的所有方法。

参与Web资源集合的安全性约束的角色集合在授权约束（AuthConstraint类）下分组。 约束中缺少AuthConstraint元素表示公共访问，而它的存在表示排除，即没有角色关联。 安全约束也可以与给定的数据保护要求（UserDataConstraint类）相关联。 此数据保护要求定义：NONE表示容器在任何连接上接收时必须接受请求，请求中，INTEGRAL会设置内容完整性和通信机密性要求。

3.2 提取过程

一旦能够描述Java EE访问控制定义的元模型可用，我们就可以提取为Web应用程序定义的访问控制信息。提取过程如图1所示，包括三个步骤，即模型发现，模型转换和整合以及模型分析。

模型发现步骤依赖于Modisco，它讲Java源代码和XML Web中描述符进行解析，以获得相应的模型表示，即Java模型和XML模型。通过这样做，我们从源代码编号和XML文件的技术空间转移到模型领域的技术空间。然后操纵获得的模型，并在转换和集成步骤中混合包含的安全信息，以获得符合所提出的Servlet的安全元模型的模型（图中的网络安全模型）。这个转换和集成步骤依赖于ATL，一种模型转换语言。转换和集成的ATL代码包括19个规则和31个帮助程序.其中的10个规则和6个帮助程序用于处理XML描述符中包含的信息，而其余9个规则和25个帮助程序处理源代码模型中的安全信息。

上述过程使我们能够简化分析策略，通过操作WRT而使用更基本的技术（如文本操作或XSLT转换），直接操作XML和源代码注释中单独定义的约束。具体而言，它将允许我们（1）使用广泛使用的模型驱动工具和框架（2）以统一的方式处理安全信息，无论是使用XML或注释来指定，这些模型与原始配置处于相同的抽象级别，因此在提取过程中不会产生信息丢失。

代码3显示了一个ATL规则，它是用于提取访问控制策略转换中的一部分，它将带注释的Servlet映射到SecurityConstraint实体。

请注意，为了向用户显示使用MoDisco和ATL所需的技术细节，我们在Eclipse下开发了一个工具，允许用户通过选择给定的Java EE项目及其Web描述符进行查看。使用简单的GUI来派生相应的Servlet的安全模型，这种工具可以用作不同类型应用的支持。

我们方法中的最后一步，即对提取的安全配置的分析和操作，将在下一节通过对一系列应用场景的描述来进行说明。

4 应用

将Java EE Web应用程序中的所有访问控制信息收集，并以与我们的Servlet安全元模型中相对应的集成模型的形式表示，可以实现广泛重复性使用现成模型进行驱动，从而用于推导有趣分析应用程序的工具和技术。此部分将在在下文中讨论。

4.1 度量标准

我们的元模型最直接的应用之一是使用查询语言（如OCL或IncQuery [2]）来执行有关模型中信息的查询和测试操作。从简单的查询，例如列出给定目标可访问的所有资源，到更复杂的操作，如检测j具有相同功能的操作，我们的模型使用模型化提取和集成方法简化了分析，通过降低执行此类操作的复杂性来实现J2EE应用程序的安全性使用。

作为示例，我们将在此处显示计算可自由访问资源的定义。

计算开放访问资源查询：Java EE应用程序中的资源只对具有某些角色的所有用户可见，但可以由每个人自由访问，无论他们的角色如何。手动检查应用程序以发现开放访问资源可能是一项繁琐的任务，但是利用所提出的Servlet安全元模型，我们可以轻松定义检测和计算此类资源。

代码4显示了一个可以检测开放访问资源的OCL查询。 所有安全约束限制了是否定义授权约束是可选择的，因为它们不对约束内声明的资源强制执行任何访问限制。 然后，收集所选约束中包含的每个资源中的URL并最终计算。

4.2 正确性

可以通过对我们提取的安全模型执行查询来检查安全性定义的正确性属性。因此，这能够检测错误配置（例如，资源可访问性中断使任何角色无法访问资源），从而帮助开发人员轻松验证其安全配置并发现可能的错误。作为示例，在下文中，我们将给出关于检查Java EE安全性配置的一个非常重要的安全属性（例如，完整性属性）的详细信息。

完整性属性和查询：在给定资源上定义访问控制约束时，开发人员必须确保为每种访问资源的方式指定策略，因为如果不这样做可能会使重要信息存在被非法调用的可能性。

如果在安全性约束中命名了HTTP方法，则必须在与同一组请求中匹配相同的或其他安全性约束中指定的标准HTTP方法。否则，未命名的HTTP方法将被视为未覆盖，从而无法访问它们。

代码1中违反此属性的安全性约束的示例。在该示例中，为GET方法定义了约束，声明只允许持有Employee角色的用户。但是，没有进行任何关于任何其他HTTP方法的说法。在没有具有此URL模式的其他约束的情况下，将使用此约束，因此，会将不受约束的访问授予与GET不同的任何HTTP方

资料编号：[4213]