摘要

使用基于代码的工具很难分析Web应用程序，因为通过应用程序的数据流和控制流都是通过服务器端代码和客户端页面进行的。客户端页面通常以与主服务器端语言不同的脚本语言指定；此外，页面是从脚本动态生成的。为了解决这些问题，我们提出了一种静态分析方法，可以自动构建给定应用程序中每个页面的“模型”。页面模型是与服务器端代码使用相同语言的代码片段，它忠实地过度逼近页面的可能元素以及由于这些元素导致的控制流和数据流。然后，服务器端代码与页面模型一起成为标准（非Web）程序，因此可以使用基于标准代码的工具进行分析。我们已经在J2EE应用程序的上下文中实现了我们的方法。我们通过在我们的方法中对结果程序应用三个标准分析工具来展示我们方法的多功能性和实用性：基于模型执行的模型检查器（JPF），动态故障定位工具（Zoltar）和静态切片器（Wala） 。

关键词

JSP，网页应用，静态分析

1介绍

属于银行，电子商务，健康管理等领域的Web应用程序具有广泛的用途，并且构成了大部分软件开发社区的关键焦点。然而，由于以下关键原因，基于代码的Web应用程序分析问题仍然是一个挑战：（1）客户端页面和服务器端代码都负责提供应用程序的整体功能，但是通常使用不同的语言和技术来实现。（2）客户端页面是由服务器端代码根据服务器端状态的内容动态生成的，但是负责整个应用程序内的关键控制流数据流链接。换句话说，客户端页面在概念上类似于自修改代码，这很难分析。（3）需要考虑用户交互。

1.1我们的提议：页面模型

我们完成本文所述工作的目的是实现Web应用程序的各种端到端白盒分析。我们启用此功能的关键提议是页面模型的新概念，它是与服务器端代码使用相同语言的代码片段。每个页面规范的页面模型由我们的方法自动生成，并在该页面的所有可能的动态实例中捕获页面的底层计算语义。随后，结合页面模型（替换原始页面规范）的服务器端代码可以被视为标准程序（在服务器端的语言中）以用于分析目的。

图3显示了图2中描述的页面规范SelectAddress.jsp的简化页面模型。将JSP页面转换为包含“root”方法pageModel的Java类，该方法接收并处理请求。链接被建模为对合适目标的方法调用；例如，在图3中，第8行是对“DeliveryOptionsServlet”的“doGet”方法的调用，该方法在点击由于图2中的第4行而生成的链接时接收请求。请注意，可以从部署描述符获取应该接收每个请求的servlet，部署描述符通常是从URL到servlet名称的映射。在网页中，用户可以选择要单击的链接。页面模型使用布尔方法“coinFlip（）”对此选择机制进行编码，该方法非确定性地返回true或false。

会话属性以及请求参数在页面模型中被建模为全局变量。前者在图3中使用打字机字体表示。请求参数使用斜体字体表示——只有一个请求参数从此页面传递给DeliveryOptionsServlet，即地址。设置会话属性状态的图2中的第7行成为图3中第7行中相应全局变量状态的赋值。类似地，EL表达式中对会话属性的引用被建模为对相应全局变量的引用。JSP控制流构造如forEach和choose-when-otherwise忠实地转换为页面模型中的等效Java构造。

值得注意的是，全局变量状态在图3中的第7行更新，这是在第8行的调用之前，即使在图2中的页面规范中，相应的行（即第7行和第4行）出现在相反的顺序。这是为了适当考虑我们在1.4节中讨论过的控制流的反演。

应用程序中页面的页面模型需要与服务器端代码集成，以产生一种标准（单一语言）程序，该程序在行为上忠实于原始Web应用程序。为此，我们的方法还在服务器端代码中应用了某些代码更改。例如，对会话属性的所有引用都替换为对相应全局变量的引用。Java代码中存在的“转发”到页面规范将被相应页面模型中对pageModel方法的调用所取代。

由我们的方法得出的最终标准程序适用于任何单语言分析工具。例如，在我们的运行示例中，来自'DeliveryOptionsServlet'中的语句的后向切片读取请求参数地址的值将拉入图3中的第3-6行，并且还可以传递给其他部分中的代码。填充列表地址的服务器。并且（单一语言）属性检查器将能够遍历执行路径通过服务器端代码并​​通过页面模型来确定例如“DeliveryOptionsServlet”必然使用当前登录用户的有效地址。

与以前的方法相比，页面模型具有以下优势：

页面模型通常与分析无关，并且原则上支持任何基于代码的分析，无论是基于静态分析，动态分析，符号执行等。而以前的白盒方法[2,3,8,9,12,22,26,27]分析了页面规范以及服务器端代码，每个都针对特定的分析问题。因此，页面模型可能潜在地构成通用Web应用程序分析基础结构的基础。开发人员可以直接利用标准程序中丰富的现有单一语言工具集，这些工具是将页面模型与服务器端代码集成在一起的。页面模型使静态分析能够通过请求参数和会话属性同时保守地跟踪数据流。以前的静态分析方法[9,12,26]没有解决这种组合问题。

1.2我们的贡献

我们的主要贡献是页面模型的新概念，可以对Web应用程序进行各种端到端的白盒分析。本文的其他贡献如下：

通过详细描述将动态JSP（Java服务器页面）页面规范转换为Java（服务器端代码的语言）中的相应页面模型的转换算法，来实现对J2EE应用程序的内容的实例化。但从概念上讲，我们的核心思想适用于任何使用基于HTML的脚本编写页面规范的技术，例如PHP，Ruby on Rails，Struts等。方法的实现讨论我们应用各种现成的白盒分析工具的经验，例如Wala [29]的静态切片，Java Path Finder [14]的强制执行，以及基于动态分析的故障定位Zoltar [5]。本文的其余部分结构如下。第2节提供了有关J2EE和JSP的背景知识。第3节更深入地介绍了页面模型的概念，而第4节讨论了我们自动翻译方法，该方法根据页面规范生成页面模型。第5节提供了实施细节，而第6节提供了实证结果。我们在第7节讨论相关工作，并在第8节中总结论文。2页面模型

2.1构建一个正确页面模型的挑战

我们在1.5节中介绍了页面模型背后的基本思想。图3中的简化页面模型确实是图2中页面规范的可接受页面模型。但是，在更复杂的页面规范中，具有如图3所示的简单形式的页面模型是不够的。

第一个问题是需要重新排序更新会话属性的语句，以便考虑控制流的反转。图3中的页面模型包含了这种重新排序（如第1.5节所述）。让我们考虑一个更复杂的页面规范，它有一个循环，在循环中包含状态更新和链接规范。现在，在页面模型中，所有状态更新语句都需要在代表链接的所有调用之前出现。这将需要以保持语义的方式将循环分成两个循环，这通常是复杂的变换。如果在页面规范中同时使用排序，循环，条件等，则这种代码复制变得更加复杂。

其次，链接点击的真实语义是不返回的。然而，代表链接的呼叫似乎允许控制返回到页面，然后是另一个链接被点击等。这个问题不能简单地通过在每个呼叫站点之后放置“goto”来修复页面模型的一部分，因为这会使得在页面模型的任何执行中遇到的第一个链接看起来始终是所采用的链接。

2.2一个实用，正确的建模方式

为了说明我们的实际提议，我们在图5中呈现了这种方法为图2中的页面规范生成的页面模型。该页面模型的显着特征如下。第6-18行是页面模型的核心。这部分代码基本上具有与页面规范相同的控制流结构，但具有如下所述的某些局部变换。

在每个链接的位置，而不是对应于链接的呼叫，设置局部变量'whichClicked'来记录链接的URL。例如，图5中的第9行和第16行分别对应于图2中第4行和第10行的链接规范。

第19-27行包含我们称之为finalBlock的内容。这基本上是一个“switch”语句，用于检查'whichClicked'的值，并调度到相应的servlet。这样，表示链接的调用基本上不会返回。

局部变量'anyClicked'用于确保在页面模型的任何路径中最多单击一个链接。

更新会话属性的语句保留在与页面规范相同的相应位置；参见图5中的第12行和第18行，它们对应于图2中的第7行和第11行。这样，所有状态更新都发生在所有调用之前（在finalBlock中）。

最后，在原始链接位置，请求参数的值被捕获到新引入的阴影变量中（参见图5中的第11行）。稍后，就在finalBlock中的“switch”语句之前，这些影子变量被复制到相应的全局变量中，这些变量代表建模程序中的请求参数（参见第19行）。这样，将会正确处理第1.4节中的示例，其中会话属性首先在链接规范中使用然后更新。此外，在finalBlock的开头，表示所有页面的所有请求参数的所有全局变量都设置为null，以确保作为请求参数发送到页面的值不会最终到达某个其他后续页面。

3实现与应用

3.1分析1：使用JPF进行深度属性检查

通过我们的翻译实现的强大分析是检测应用程序中的功能错误，完全考虑动态客户端页面，服务器端逻辑以及这两者之间的交互。对于此分析，我们使用Symbolic PathFinder（SPF）工具[14]，它是广泛使用的工具Java PathFinder（JPF）[4]的复杂执行变体。我们在此草拟了在我们的方法生成的修改后的应用程序上应用SPF时所遵循的步骤。首先，我们在生成的页面模型中执行了三种修改，以确保应用程序的详尽覆盖（而不是仅通过一个随机的页面序列）：（1）页面模型现在使用SPF API来选择所有可能的链接每当访问一个页面时，逐页形成一个页面。（2）同样，下拉列表中的所有值都是逐个尝试的。（3）使用SPF API填充文本框，该API返回新的符号值。到目前为止，我们已手动在生成的页面模型中执行了这些修改；然而，原则上自动化很容易。

我们还在服务器端代码中进行了两种修改：（1）SPF没有现成的精确分析应用程序中的数据库操作。因此，我们手动修改了我们在实验中使用的基准测试应用程序，以使用普通的Java集合而不是数据库。（2）我们将属性检查代码插入基准，以实际检查是否存在所需属性的违规。现在可以使用SPF以系统的方式探索应用程序的痕迹以查找违规行为。

我们检查了各种功能属性的基准测试，例如，“不允许使用相同的电子邮件ID进行多次注册”，“如果购物车为空，则总数应为零”，依此类推。我们从作为官方iTrust文档的一部分提供的需求规范中提取了iTrust的属性。其他基准没有提供文件；因此，我们要求与我们的工作无关的研究生运行基准并确定理想的属性。我们以这种方式共获得了19处房产。表2总结了该实验。如表2所示，具有页面模型（PM）的JPF报告在一些运行中违反了19个属性中的8个。其中六个是可重现的，而两个（IT和MS各一个）是误报。其中一个误报是由于SPF的限制，而另一个是由于页面模型在表单有多个“提交”按钮时没有精确表达语义。

其余11个属性可以被认为是针对长度达到所考虑范围的路径进行验证。这是因为我们的方法是详尽地考虑所有选择，并对所有文本框使用符号值，如第5.2节所述。

我们观察到的运行时间对于19个属性中的每一个都在几秒到7分钟之间。

3.2分析2：使用Zoltar进行错误定位

Zoltar [5]是一种基于动态分析的故障定位工具。给定一组通过和失败的测试用例，该工具根据所有给定的测试用例分析程序中所有语句的执行相对频率。对于程序中的每个语句，它会报告一个怀疑分数，表明该陈述可能是导致测试失败的原因。

对于本实验，我们首先使用我们的方法将基准Web应用程序集转换为修改（标准Java）程序。为了在所有实验中保持一致，我们在此分析中以及在下一次分析（即切片）中使用修改程序的版本，其中数据库操作被集合操作替换（参见第5.2节）。在下一步中，我们手动为每个基准创建了一组测试用例。测试用例只是一系列要访问的页面，以及每个访问过的页面中的输入选择元组。我们所有的测试用例都通过了测试用例。然后我们在（修改的）基准程序中播种错误。为了以无偏见的方式种植bug，我们使用了一种变异测试工具，即PIT [15]。我们从PIT建议的每个基准中随机选择了20个突变，注意选择导致至少一些测试用例失败的突变。因此，我们获得了每个基准测试的20个版本。

然后我们在每个基准测试的每个变异版本上运行Zoltar，使用基准测试用例（其中一些现在失败了）。然后，我们评估了Zoltar在确定每个基准测试的每个错误版本中的变异位置的有效性。

从Zoltar的每次运行（在基准的错误版本上），我们首先计算每种方法的怀疑分数，作为该方法中任何语句的最大怀疑分数。然后，我们将那些分数大于或等于包含种子错误的方法得分的方法入围。

在基准TD的20个错误版本中，每个版本的入围方法的平均数量仅为3.27％。 （在本节中，我们仅使用几何平均值。）也就是说，直观地说，在找到错误之前，只需要检查错误版本中3.27％的方法。其他基准的入围方法的相应平均百分比为：RO为5.3％，MS为4.9％，HD为3.9％，IT为0.2％。这些极低的数字表明我们的页面模型与Zoltar工具结合使用来定位我们的基准程序中的故障。

我们很难获得这些实验的基线。由于应用程序的分层体系结构，以及服务器端框架和库，Zoltar（或者就此而言，大多数动态分析工具）无法直接在Web应用程序上工作。

3.3分析3：使用Wala进行静态切片

对于这个实验，我们对由我们的方法生成的修改程序应用静态反向切片。由于Wala的“完全”切片通常不会扩展到更大的基准，我们使用“对象类型上下文敏感度”选项计算“瘦”切片[23]。我们的目标是了解大切片在实践中的倾向，它们如何经常跨越多个页面的边界，以及切片是否有助于检测错误的原因。我们选择这种分析的另一个动机是切片一直是软件工程界的一个研究课题，甚至特别是针对网络应用的研究人员[12,19,26]。

在我们的第一组切片实验中，我们使用程序中的所有“输出”表达式——即，将值插入数据库或显示页面的表达式——作为标准。表3（a）部分提供了有关所有这些标准的切片的统计数据。表格中前四列的含义如下：（1）基准名称，（2）标准总数（即采取的切片总数），（3）平均页数（即，包含在切片中的不同“pageModel”方法，以及（4）应用程序中包含在切片中的方法的平均百分比。很容易看出切片通常跨越大量页面边界;换句话说，用于Web应用程序的切片工具肯定需要考虑通过页面的数据流。而且，这些切片往往很小，因此有可能对开发人员有用。

表3的（b）部分提供了有关我们根据条件计算的切片的信息，这些条件是某些运行中包含不正确值的表达式。这些标准是从JPF检测到的财产违规行为中确定的（见上文第6.1节）。这样的切片可以帮助识别错误的根本原因。

4总结与未来工作

以前关于Web应用程序分析的研究已经产生了复杂的技术，但每种技术都解决了一种非常特殊的分析问题。也许正因为如此，令人惊讶的是缺乏可扩展，强大的工具和平台，用于Web应用程序的细粒度白盒分析。相比之下，我们使用页面模型的方法可以应用Web应用程序中存在的大量强大的单语言工具。此外，与先前用于Web应用程序的静态分析方法相比，我们的第一个通过请求参数和会话属性以原则方式处理同步数据流。未来工作的想法包括解决cookie，Javascript以及其他平台，如Ruby on Rails和PHP。

致谢

此文由南京大学软件学院2016级本科生虞圣呈翻译转述。