英语原文共 8 页
（外文翻译）
基于模型的Java EE Web安全性配置分析
作者：
1.Salvador Martiacute;nez AtlanMod Team(Inria, Mines Nantes, LINA)Nantes, France salvador.martinez@minesnantes.fr
2.Valerio Cosentino AtlanMod Team(Inria, Mines Nantes, LINA)Nantes, France
valerio.cosentino@minesnantes.fr
3.Jordi Cabot ICREA - UOC Barcelona, Spain jordi.cabot@icrea.cat
摘要：
随着JavaEE Web应用的广泛使用，作为向远程客户端提供分布式服务的手段，它提出了迫切的安全要求，以使得由这些应用程序管理的资源继续受到未经授权的公开和操作的保护。为此，JavaEE框架为开发人员提供了定义访问控制策略的机制。不幸的是，所提供的安全配置机制的多样性和复杂性导致安全策略的定义和操作复杂且容易出错。由于安全需求不是静态的，因此，必须经常更改和审查已实现的策略，在适当的抽象级别发现和表示策略，以使它们能够理解和重新设计，这是一个关键的需求。为了解决这个问题，本文提出了一种（基于模型的）方法，旨在帮助安全专家可视化（自动）分析和操控Web安全策略。
关键词
安全，访问控制，反向工程
- 介绍
JavaEE是一种流行的开发技术。动态Web应用程序，同时也是基础层不太通用的框架。JavaEE促进了向远程用户公开分布式信息和服务。在这种情况下，安全性是一个主要问题[16]，因为Web资源构成Web应用程序的许多用户通过不受信任的网络。因此，Java EE框架为开发人员提供了指定访问控制策略的工具，以确保机密性和完整性。Web应用程序公开的资源的属性。
不幸的是，尽管这些安全机制可用，但是实现安全配置仍然是一个复杂的过程以及容易出错的活动，其中需要高专业知识以避免不一致和错误配置问题，这可能会造成严重后果商业损失。当Web应用程序管理的资源出现时许多用户可以访问操作，并且可以透过不受保护的网络。意外的数据披露可能导致重大损失在金钱和名誉方面。
对于Java EE应用程序中的访问控制的具体情况，Web的声明性基于角色的访问控制（RBAC）[20]策略应用程序是通过使用低级的基于规则的访问控制语言，具有两种不同的文本具体语法和相对复杂的执行语义。具体来说，用户可以：
1.通过使用一组预定义的标记元素。
2.编写注释（语法和组织不同JavaServlet组件上的XML标记元素W.R.T）。
这两种机制都可以用于同一个JavaEE应用程序，因此需要这些组合规则才能获得最终的安全策略。在这种情况下，发现和理解策略实际上是由给定的Web应用程序执行的作为一个关键的要求。这方面的主要挑战发现过程正在弥合低级别、分散的策略表示与更高级别、更易于理解的策略表示之间的差距。为了解决对于JavaEE Web应用程序，我们提供了这个问题：
1.JavaEE框架提供的两种声明性约束规范机制的语言统一，这两种机制的贡献可以通过同样的程序和工具。
2.提取安全控制的逆向工程过程——使用不同的Java EE机制实现的图形，并将它们集成到安全模型一致性中，即一个下面将提议的Web安全元模型。
3.演示了使用基于模型的集成表示的应用程序和好处，这使得在安全领域重用大量可用于可视化的模型驱动技术和工具，分析、发展等模型。
我们的方法补充了现有的Java逆向工程作品。跳过了安全方面的内容[3，5]。我们通过一个prototype工具实现和它在real示例中的应用来证明我们的方法的可行性。JavaEE应用程序可用GITHUB。论文的其余部分组织如下。第2点介绍了JavaEE框架，提供的各种访问控制机制。而第3点介绍了我们提取它们的集成模型表示。第4点描述一些相关的应用场景。评估方法见第5点，第6点简要介绍描述我们为实现自动化而提供的工具支持。我们通过讨论第7点中的相关工作来结束本文。提供第8点中的未来研究路线和结论。
- JAVA EE WEB 安全性
粗略地讲，在JavaEE框架中，当Web客户端发出HTTP请求，Web服务器将请求转换为
HTTP Servlet调用Web组件（servlet和Java服务器）页面可以直接应答，也可以反过来调用企业Javabean（EJB）用于执行更复杂的业务逻辑操作。在这个模式中，一个非常重要的要求是确保有Web应用程序。在这个意义上，JavaEE框架提供了随时可用的访问控制设施。在下面我们将简要描述JavaEE为Web应用程序实现访问控制策略所提供的机制。
-
- 访问控制
JavaEE应用程序通常由JSPs和servlet构成。现有的访问控制机制负责控制访问这些元素以及存储的任何其他Web可访问的工件（纯HTML页面、多媒体文档等）。有两种方式可用于指定此级别的安全策略：声明性和程序性安全，后者规定需要精细的访问控制（需要用户上下文评估）的情况。
关于声明性访问控制策略，有两种选择可用：1）在可移植部署描述符（web.xml）中写入安全约束；2）将安全注释编写为Servlet Java代码的一部分（注意，并非所有的安全性）
配置可以通过注释来指定）。
让我们考虑一个具有限制区域的企业Web应用程序对于员工以及定义了角色的员工。清单显示在web.xml描述符中定义的安全约束，该描述符限制（使用http方法get时）对具有雇员角色的用户访问雇员区域。
它包含三个主要元素：一个Web资源集合，指定受安全约束影响的资源的路径以及用于该访问的http方法（在本例中是/restricted/employee/*路径和get方法）；auth约束声明允许哪些角色（如果有）访问资源（仅示例中的角色employee）和用户数据约束这决定了用户数据必须如何从Web传输到Web应用程序，设置为“无”（即接受任何类型的传输）例子。
清单1:web.xml中的安全约束
通过注释定义的等效安全约束如清单2所示。@webservlet注释标识在Web容器中定义servlet和资源路径。然后，主要的安全注释是@servletsecurity，它有两个属性：value，对应于嵌套的注释@httpconstraint和httpmethodconstraint，其中包含嵌套@httpMethodConstraint注释。使用了@httpconstraint表示要应用于所有HTTP方法的安全约束第二个用于定义每个HTTP方法的约束。@httpconstraint和@httpmethodconstraint都将允许的角色（allowedRoles）列表作为属性包含在数据保护中需求（相当于相当于中的user-data-constraint元素）以及允许角色列表为空时的行为。
2.2策略和规则组合
上述两种声明性备选方案都可用于同时，最终的安全策略是用这两种机制指定的安全约束。然而，如果发生冲突，web.xml文件中指定的约束将优先级，以及使用注释定义的约束如果在web.xml描述符（metadata complete参数设置为true）中建立了，则可以完全忽略它，因为显然会给非专家造成混乱。
此外，使用这些机制定义的访问控制策略上面描述的可能包含不一致性（说明同一资源的不同访问操作的规则）。这些不一致之处是通过使用JavaEE Servlet规范中定义的规则优先级、执行语义和组合算法来解决。不幸的是，虽然这个过程消除了策略，它可能会引入典型的访问控制异常，例如阴影和冗余[8]以及其他错误配置特定于JavaEE访问控制。
注意，如上所述，需要上下文信息的细粒度访问控制约束也可以在JAVA EE框架。这些约束不能声明性地删除。罚款并要求使用程序安全。实例将是约束检查用户是否拥有两个角色，或者一个连接只能在特定的时隙中被接受。我们离开未来对这些细粒度编程约束的分析工作。请注意，JavaEE规范建议尽可能优先使用声明性担保。
图1：Java EE Web应用程序分析方法
- 措施
我们的方法（如图1所示）通过将其提取出来收集Java EE应用程序中包含的安全性信息
模型表示。 然后，它将它们统一并集成在一个特定领域的模型（通过模型转换），因此，模型操作，查询操作等可以在以后进行应用它来分析和管理安全配置。 特定于域的元模型和提取过程在本节的其余部分中描述。
3.1元模型
在提取过程之前，metamodels的定义能够准确地表示code中包含的信息配置源文件是必需的。图2中描述的Servlet访问控制安全元模型（以下称为Servlet安全元模型）将用于该目的。都注释和XML安全定义共享相似的语义因此可以映射到这个元模型抽象语法，让我们直接从他们的低级模型表示（Java模型和XML模型，已在MoDisco中提供框架[3]）我们的安全元模型不需要为他们的代表定义中间特定的安全元模型。
Servlet安全元模型允许处理安全角色（SecurityRole类）和安全约束（SecurityConstraint在给定的Web应用程序中）。前者指定安全策略定义的安全角色。后者习惯了表示来自XML Web描述符或Java注释（源属性）的访问控制约束Web资源（WebResourceCollection类）。每个网络资源collection标识资源（urlPattern属性）和HTTP应用安全性约束的方法（HttpMethod类）。重要的是要注意，如果HTTP方法被定义为省略（省略属性），安全约束适用于所有方法除了省略的方法。
参与用于收集Web资源的安全性约束的角色集合在授权约束（AuthConstraint类）下分组。没有AuthConstraint给定约束中的元素表示公共访问，而数据排除由其存在表示，没有角色关联。安全约束也可以与给定数据相关联保护要求（UserDataConstraint类）。此数据保护要求可以定义为：NONE表示该数据容器必须接受任何连接上的请求，INTEGRAL建立内容完整性和要求机密，建立沟通要求保密。
3.2提取过程
一旦能够描述Java EE访问控制定义的元模型可用，我们就可以提取访问控制信息为Web应用程序定义。提取过程，如图所示图1包括三个步骤，即模型发现，转换和整合，以及分析。
模型发现步骤依赖于解析Java的Modisco源代码和XML Web描述符获取对应的模型表示，即Java模型和XML模型。通过这样做，我们将源代码的技术空间从符号和XML文件转移到模型领域。然后操纵所获得的模型和安全信息包含在转化和整合步骤中混合获得符合所提出的Servlet安全元模型的模型（图中的Web安全模型）。这种转变＆集成步骤依赖于ATL [9]，一种模型转换语言。转换和集成的ATL代码包括19规则和31个助手。10个规则和6个助手处理XML描述符中包含的信息，而剩下的9个规则和25名助手负责处理内部的安全信息
源代码模型。
上述过程使我们能够简化操作分析政策所需的操作w.r.t.直接操作XML和源中单独定义的约束使用更基本的技术（如文本操作或xslt转换）编写代码注释。具体而言，它将允许我们1）使用众所周知的模型驱动工具和框架，以及2）以统一的方式处理安全信息，无论是否是使用XML或注释指定。但请注意这些模型位于原始配置的相同抽象级别，因此，在提取中不会产生信息丢失处理。
清单3显示了一个ATL规则，它是对外部访问控制策略的转换的一部分，它将带注释的Servlet映射到SecurityConstraint实体。请注意，为了使低级用户透明使用MoDisco和ATL所需的技术细节，我们在Eclipse下开发了一个工具，允许用户选择给定的JavaEE项目及其Web描述符通过简单的GUI来派生相应的Servlet安全模型。可以使用这种工具作为对不同类型应用程序的支持。
图2：Servlet安全元模型
清单3：用于将安全注释的servlet映射到的ATL规则安全约束
我们将采用我们方法的最后一步，即对提取的安全配置进行分析和操作在下一节中通过一系列应用程序的描述进行描述。
- 应用
以集成模型的形式收集和表示JavaEE Web应用程序的所有访问控制信息与我们的servlet安全性元模型相对应，可以实现各种已验证的现成模型驱动工具和获取有趣分析应用程序的技术。在下面，我们将讨论其中的一些问题，重点是计算查询和度量，并简要讨论其余内容。
<st
资料编号：[3514]</st
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
