大森孝之 日本立命馆大学计算机科学系 takayuki@fse.cs.ritsumei.ac.jp
IT政治局常委 电子科技大学计算机系
摘要
重构ISA在开发和维护软件中是有益的做法,因为它可以改善既有代码的设计而不改变它的外部行为。因此,现代的集成开发环境往往包括支持源代码自动转换的重构工具。不幸的是,一些流行的重构变换使现有的代码变得脆弱,即使他们提高其可维护性。脆弱代码的存在仍然是许多软件系统的一个严重问题。本文介绍了与有关软件安全性一类新的重构,它被构建为一个Eclipse插件支持的工具。它可以帮助程序员很容易地知道在重构应用程序安全漏洞时代码改变的不利影响,并为他们提供一个机会,以确定他们是否能接受或应取消适用重构。因此,他们去改善既有代码的可维护性并且不会把新的安全漏洞插入到代码中时会感到安全。为了评估这个工具的性能,我们给它做一个实验。实验结果表明了该工具的实用性,也揭示一些遗留问题需要解决。
分类与主题描述
D.2.6[ 软件工程]:编程环境;
D.4.6[安全与防护]:信息流控制
语言,安全性
重构,软件转型,访问控制,信息流
1.引言
对于很多程序员来说,编写代码没有任何安全漏洞是很难,修改现有的代码而不插入任何安全漏洞更是难上加难。一个安全漏洞是他们编写或修改软件程序时犯了一个错误,并可能成为一个弱点。一个漏洞是一个可以被攻击者[9]利用的问题或一个可能导致威胁发生[2]的弱点。不幸的是,有许多脆弱的软件程序给机密数据设置很弱的访问控制或给恶意代码提供不必要的权限。特别的,一个框架 程序采用插件机制是危险的。想想看,这样的框架方案将导入通过网络下载的不受信任的插件模块,并与他们一起运行。如果任何一个模块是恶意的,该框架程序内的数据可访问性的增加(例如,从私有到公共)是一个安全风险(如,密码的泄露可能就会招致)。
在本文中,我们强调支持现有的代码修改时的安全特征。即使程序代码在其首次执行时有正确的安全功能,代码的修改可能恶化这些特征。事实上,通过我们的初步调查,我们发现几个重构的转变显示在福勒的目录中 [6]可能会降低他们的应用程序现有代码的安全特性。例如,倒推法的重构使得一个私有字段非私有,如果搬移函数在修改后的代码中使用此字段。这种重构将给攻击者提供了一个访问该字段机会,因为它的访问权限设置将比以前弱。移动函数,移动字段,上移函数,上移字段,提取类,提取子类,提取超类的重构同样对移动元素(字段或方法)或与之相关的元素有类似的负面影响。然而,这些重构在他们对重构后的代码的安全风险的影响没有兴趣。因此,程序员通过应用这种重构会有可能无意识地将安全漏洞插入到代码中。
为了解决这个问题,程序员应该注意对数据的可访问性应用重构带来的影响,并应该知道它变化的信息。本文提出了一种支持安全意识重构[14]的工具。在应用的重构中,它会检测到基于存储在目标程序中的数据访问设置的直接变化和由于明显的信息流而造成间接的变化带来的任何可能的代码中漏洞,然后发出有关这些漏洞的安全警告。 在使用该工具,我们不采取哪种合适的访问设置能够保护敏感数据来自不同种攻击的立场。
它一般是很难保证能够预防未经授权的披露或修改,在仅通过使用Java[18]提供的有限访问设置就允许任何可插拔模块的代码的数据中。此外,不仅过多的访问权限会产生安全漏洞。由于这些原因,这个工具的目的是尽可能多的提供关于任何增加可访问性而不发出错误警告的安全警告。因此,该工具可以帮助程序员避免那些可能被意外的或故意的用来破坏机密数据的意外的代码缺陷[13]的发生。
本文的主要贡献是提出一个实现了考虑代码漏洞的新一类重构的可行工具,实验结果表明了评估该工具的性能,。这个工具将促进安全关注重构的有效性。这个工具将促进关注安全重构的有用性。
本文的其余部分安排如下。第2节显示了一个简单的刺激的例子。第3节介绍了安全意识的重构,并提出实现这种重构的工具。第4描述了一个实验用的工具。第5节讨论了实验结果和开放性问题。最后,第6节以一个简要的总结和近期工作结束。
2.刺激的例子
图2:目标程序的使用场景
图1显示的是在使用倒推法前后的代码段。这个重构将adjust ()方法从类Statement移动到它的子类AccountingReport,当没有方法直接调用从Statement类产生的实例的adjust ()方法时。其结果是,Statement类中的一个私有字段profit成为保护的字段,因为adjust ()将在修改后的代码使用。profit在原来代码中的值只有从类Statement的内部访问,而profit的值在修改后的代码中却可以从类Statement、与类Statement在同一个包中的类,或类Statement的子类1中访问。换言之,这下倒推法的重构使得存储在profit的值比以前更容易访问了。
1更精确一点,profit的值不能从同一个包的外面访问,因为Statement被声明为受保护的(default)。
在这里,一个成功的攻击是通过使用目标程序包括修改后的代码的场景描述的。这个程序包含在图2所示的三个类Statement, AccountingReport及Shop。它允许不受信任的代码与这三个类运行起来。Owner是使用目标程序的执行者。攻击者可以通过使用恶意的子类MaliciousStatement获取profit的值,正如图3所示。当执行者在一个典型的安全管理器的安装目录下运行源代码连同的恶意代码,这种攻击将失败(异常java.lang.IllegalAccessException将被抛出)。这意味着该profit值是受到了正确的保护。另一方面,当执行者运行包括Statement修改后的代码与恶意代码的程序时,攻击就会很容易的成功。因此,profit的值将显示在屏幕上。这将导致不期望的泄露。
而且,很容易让攻击者取得在开源开发生产中的源代码 。他们已经深深 分析这些源代码,然后知道哪些变量可能 在源代码中存储敏感数据。在这种情况下,为了切实保障数据,我们应该考虑一个存储这种数据,并且可以存储某种类型所有变量上的数据信息(例如,数据的副本)[22]的变量的可访问性 。
例如,在图1中示出的修改后的代码包括一个 通过calcProfit()方法的参数i从变量income到变量profit可能的信息流[2]。 此信息流显示,income值可能会影响 profit的值。基于信息流控制的目标[7],income会干扰profit在这种情况下。如果profit值被公开,income的值也被认为是被公开的。
在这种情况下,程序员应该知道对income的干扰,不仅仅是profit可访问性的变化的更新。不过,他/她往往会遗漏与income相关的保密的降解,因为它的访问修饰符没有明确的被修改。攻击者可以计算出income的值通过知道profit的价值。这是一个相对微不足道,且典型的泄露敏感数据的案例。
图4: Jsart运行的屏幕截图(Java安全意识重构的工具)
3.工具的应用
几个重构工具都包含在现代化的集成开发环境(IDE)中如Eclipse。从这个角度的观点看,工具支持安全意识重构被认为是在现实的软件开发至关重要的应用。本节简要介绍了安全意识重构的概念和它的工具。接着,下部分说明了工具架构和解释演示了该工具检测漏洞入侵。
3.1安全意识的重构
安全意识的重构[14]减轻了可能从现有应用程序中的代码数据被无预期的披露出现的风险 。这中重构的每一个转变,确保在代码中没有可观察到的行为的变化 。它还提供了程序员了修改后的代码的安全特性是如何被降解的安全警告 作为其应用的结果。
在这里,我们要澄清在源代码下的相关安全特性 。本文的重点是预防[8],并假定源代码不泄露敏感数据给未经授权的用户(即,机密性)2。也就是说,漏洞的代码被认为是可能导致允许未经授权的外部代码访问数据的问题,。基于这个假设,数据保密程度是由存储数据的字段或访问该字段的方法的手段相对量度的。这个量度在本文中称为访问级别。如果一个应用重构放宽了对现有代码数据的访问,那么修改后的程序的访问级别就被降低了。换句话说,这个重构使程序变得更脆弱,使攻击者更容易通过代码的弱访问控制获取数据。
2完整性或可用性被认为超出范围虽然他们也涉及到软件的安全性。
我们已经开发Jsart(Java安全意识的重构工具),它支持两种重构变换(上移函数,下移函数)。图4示出的在Eclipse中嵌入Jsart的快照3,当一个程序员使用下移函数的方法应用于在图1所示的源代码中的adjust ()方法。源代码(左)和其修改后的代码(右侧)被显示在预览器的顶部。安全警告被显示在预览器的底部。在这个例子中,它会告知所有的三个字段变量income,outgo和在图1的profit的访问级别下降。在审查安全警告信息后,程序员可以决定他/她是否接受或取消应用重构。如果对所有警告带来的影响是可以接受的,他/她可以按“确定”按钮。在这种情况下,在编辑器中的代码将被替换为修改后的代码。
3.2工具架构
图5示出Jsart的总体架构。它被构建为Eclipse3.4.1插件的形式,并利用Jxplatform[10]4。 Jxplatform是一个工具平台,它提供了将源代码转换成有纹理的XML表示形式的API。它包含为每个方法生成一个控制流程图(CFG)[1]和一个程序的依赖图(PDG)[5]所需的库。在图5中,每个箭头表示在工具中数据元素流。
一个代码转换控制模块去检查每个重构的先决条件,改写从源代码转换为XML文档的内容,并且从重写的XML文档恢复修改后的代码。Jsart的代码转换器的实现主要是从Jrbx[15]的转换来的。它使用的是XML文档源代码,而不是抽象的语法树的,(AST),并操纵这些文件去实现前提条件的检查和改变创造的代码。
4这用Java编写的实现,Jsart 包含4,900 NCNB(非注释,非空)LOC,Jxplatform包含约25,000 NCNB LOC。
一个安全性评器通过使用基于不敏感流分析的CFG/ PDG库去构造一张代表访问级别和目标程序中它们之间的关系的图(ALG后述)。它比较图表中生成的对应于源代码之前和重构后的节点的问级别。如果某个特定字段的访问级别低于应用重构之前的访问级别,评估器创建一条关于这个字段的安全警告消息。
3.3访问级别标准
应用重构的影响是基于在重构中原始代码和修改后的代码访问级别的变化所量度的。Jsart采用由一个点阵表示一对访问修饰符[14]的标准(偏序),如下图所示。
< public,protected > <= < public,public >
在对<C, M>中,C表示含有一个成员(一个字段或者一个方法)的类的访问修饰,M为成员的访问修饰符。private,default(package),protected和 public是Java编程语言[18]四种可能的访问级别。该准则假定一个存储敏感数据的字段变量定义在一个顶级类。接口不处理,因为他们的成员被隐式声明为public。关系<=表示两个访问级别的顺序,这主要基于程序元素的访问范围确定的。就H<= L而言,H的访问范围窄于L的因此,H比L有较高的(强)的访问级别。星号(*)表示通配符,可以替换为public或default。<public, private>和<default, private>这两个访问级别都来源于<*,private >,因此它们有没有顺序关系(<*,default >同上)。
3.4访问级别图
Jsart的安全评估者从它的PDG的代码中提取显性信息流。它还通过使用访问级别图表(ALG)来管理访问级别的传播。ALG由一组对应于代码中的变量(准确地,变量声明不能重复)的节点组成,有向边代表两个节点之间的流量关系。一个变量是一个字段,参数或返回值。无相应的局部变量节点出现在ALG,但是,信息流经局部变量出现在ALG。一个字段或方法持有其明确的访问级别。一个参数或返回值的访问级别是和调用它的方法的访问级别相同的,因为它的值可获得或观察通过方法调用或方法重写。每个节点都继承其对应变量的访问级别。
ALG的边缘被作业中的数据流或方法调用时的参数输入/输出流抓获。在作业中,存储在右手边变量的值被允许流入左手边的变量。安全评估者假设攻击者基于任务的信息流模型[2]5 有机会从左手边获得所有右手边的值。在方法调用中,调用点传递零个或多个参数到被调用的方法,并接收零个或一个返回值。一个ALG采用参数输入/输入出到系统依赖图(SDG)的边缘[26],它代表形式参数和实际参数之间传递。因此,一个字段值可能的暴露可以通过其访问方法检测到。
为了检测从明确的信息流导致访问级别可能的降级,我们定义一个在一个ALG边的反向转变。对于边x→y,则反相转变表示y访问级别可能的降级也会导致x访问级别可能的降级。在ALG图中节点n的潜在的访问级别的定义如下:
PAL( n)= inf( R ( n)) , R ( n)= { m ∈ N | n →∗m }
其中N是一组在ALG的所有节点,并且→*表示ALG边的自反传递闭包。函数INF(S)返回一个节点集合S的每个节点的访问级别的下确界(最大下界)。访问级别是根据第3.3节的标准进行比较的。
5在大多数情况下,左手边的值源自多个右边的值得计算。因此,攻击者并不总是得到每个右边变量的精确值,尽管他/她知道左手边变量的值。
图6示出了两个节点具有潜在的访问级的ALGs为在图1中所示的原来的代码和修改后的代码。每个节点的标签表示变量(如字段变量profit在节点7或参数i在节点3)的名称或一个函数的返回值(例如,$ getOutgo在节点8)。在ALG的顶部,这两个边i→profit和o→profit均来自图1中的顶部代码方法calcProfit()内的赋值语句“profit= i-o”。ALG顶部的两条边,income→i和outgo→o,相当于在图1中顶部的代码record()中的方法调用“calcProfit(income,outgo)”各参数对应的边。
在图6所示的ALG的顶部,R(5)={5,6,7,8} 然后PAL(5)=<default, default > ,因为在节点8的返回值$ getOutgo的访问级别 被传播到节点5的字段outgo。同样,在ALG的底部,R(5)= {5,6,7,8},然后PAL(5)=<default, protected>,因为在节点7的的字段profit的访问级别被传播了。
此外,安全评估者通过使用源代码重构前和重构后生成的两张ALGs图来检查每个字段的访问级别的变化。重构工具一般从他们提供的重构的应用程序中捕获到代码的更改。因此,很容易选择两张ALGs之间同一个程序元素对应的节点。在图1中,例如,Jsart掌握了下移函数重构将adjust()方法从类Statement移到了子类AccountingReport并改变了profit的访问修饰符的事实。Jsart还知道哪些节点对应于这三个字段变量income(节点 2),outgo(节点5),profit(节点7)在这两张ALGs中。通过比较ALGs中每一个节点的两个访问级别,它检测到在这三个字段变量访问级别的降级。
4.实验
为了证明Jsart是否会基于数据访问级别的变化而提供正确的警告基于在3.3节中描述的标准,我们进行了仿真实验。我们检查Eclipse 3.1.4的源码,在其中选择可能因为应用了特定的重构而访问级别被不知不觉的降级的字段变量。在这次检查中,25个名为“password”的变量被选定,这些变量最有可能持有敏感数据6 。接下来,我们在一个类中定义这些字段变量并为每一个字段变添加一个getting方法。所有getting方法声明的默认值。然后,我们应用Jsart的倒推法重构每个added的方法。通过这种重构,目标方法从定义字段变量password的类移动到其子类。如果一个合适的子类没有存在重构之前源代码中,这种类就是新创建的。最后,我们检查显示在Jsart预览器中的安全警告是否与在ALGs内的访问级别的实际变化一致。
表1示出了实验结果。访问级别AL和潜在的访问级别PAL被手动的从中间文件提取存储信息在ALG中。关于AL,下移函数的方法改变了字段变量password的访问修饰符,由要么是private或是defualt改为protected。PAL显示,许多password字段变量(25 个中有17个)的访问级别已经相当于public访问级别在应用重构的之前。
在表1中,列“警告”表示任何警告的发生。 Jsart用符号“√ “提供几个警告在七个重进程中。至于在其余的18重构过程中,不显示警告信息,因为PAL在它们中没有机会。通过手动检查源码和修改后的代码,我们确认Jsart能正常运行在这个实验。也就是说,它能正确地检测到访问级别的降级。
在这里,我们简要描述在实际使用中,如果Jsart在可接受的时间内完成所有检查。表2示出的是表1中一些重构的处理时间的。
该测量在一台 CPU 为 Intel Core 2 Duo 3.06 GHz,系统为Mac OS X 10.5.8和装了一台分配了1,024 MB、800MHz的DDR2 SDRAM 的Java虚拟机的计算机上执行。
6事实上, 28字段变量被发现通过搜索关键字“password” 。其中三个被排除,因为它们存储GUI组件的实例。
在表2中,列“ID”和“LOC”各表示表1中重构的识别编号,以及一个项目中每段代码包含多少条NCNB线是关于重构的。如果同一项目涉及到多个重构,我们提出七个中的一个。列“#N”和“#E”表示每个通过Jxplatform产生的PDG图或每个由Jsart产生的ALG图的节点和的边数。对于每一个重构,对应于源代码和修改后的代码(重构之前和之后的)的两个PDGS图,有相同数量的节点和相同边数,因为只有一个方法被简单移动在应用倒推法的过程中。列“Time”代表两个试验中的平均处理时间。
5.讨论
本节讨论一些Jsart提供的有关安全警告和开放性的问题,我们将解决的一些问题。
5.1安全警告的有效性
在实验中,Jsart成功地减小了可能基于访问基本的变化而产生的无用的警告 ,通过引入基于信息流概念的ALG。例如,通过对表1所示的类Client(其ID为19)的一个方法应用重构,Jsart确实不认为password字段变量访问修饰符的重写诱导其访问级别的降级。因此,它没有提供有关这个重构的警告。要检查 这种行为的有效性,我们手动检查了Client原始的和修改后的代码。在原代码,password值的编码(加密)在其访问级别降级之前。在修改后的代码中,密码的访问级别被保留直至到执行了编码。在两种情况下,编码值被发送到网络上。因此,Jsart被认为是精心设计的。
然而,Jsart有时遗漏了明显的安全警告。例如,一个特定的重构可能产生代码的修改从而诱导Client的password的访问级别的降级,在其值被编码之前。在这种情况下,Jsart应该向程序员发出一个安全警告。然而,Jsart却没有发出。这是因为Jsart决定了password在源代码内访问级别的声明周期,基于其整个生命周期,忽略了生命周期内发生局部的访问级别的降级。
接下来,考虑表1所示的对类PServerConnection(ID为13)的一个方法应用重构。Jsart给出了字段变量password的安全警告,在这次重构中。原码可防止外部包现有代码访问password,而修改后的代码允许这样的外部代码自由访问它。为了检查这种行为的有效性,我们手动检查PServerConnection源代码和修改后的代码。在原代码中,password的值在PServerConnection实例化同一时间被设置。然而,一段时间后它就被加密。换句话说,这里有一段危险时间在设置和加密password的值之间,尽管加密的值被发送到网络上。在这种情况下,password的值应收到保护,防止外部的恶意代码。不幸的是,这个重构使得恶意代码可以访问该值。在应用此重构中,希望Jsart发出安全警告给程序员以检查修改后的代码。出于这个原因, Jsart这种行为是适当的。
然而,Jsart有时会产生虚假的安全警告。例如,考虑PServerConnection修改后的代码禁止多线程执行和保证password的总是被立刻加密当值设置后。在这种的情况下,password的访问级别的降级不是真的问题的。换句话说,不需要任何安全警告。
7Jsart当前的实现分析了同一个项目中每个源文件。因此,同一个项目不同的重构的处理时间几乎是相同的。
5.2 开放性的议题
在此说明三个开放性议题,这主要来自Jsart的局限性。
5.2.1不精确的分析
Jsart的实现假定Jxplatform提供正确PDGS为任何代码。然而,很难为Java程序构造正确PDGS包括对象引用使用别名,多态调用,多线程执行,或反射。 Jxplatform通过使用基于类的分析和给实例取别名来提取数据的依赖关系。因此,它既不区别同一个类生成的多个实例,也不识别同一个实例的不同名字。 Jsart可能无法检测这些程序安全漏洞的正确的影响。
为了构建更准确的PDGS ,几种在[12]介绍的技术可能是可用的。然而,有用的技术目前仍不清楚。特别是,处理时间是明显要关注的。如在表2中示出的, Jsart消耗大量的时间,并且必须付出更多的代价在交互式的重构过程中。如果我们简单地追求高度的精度,处理时间也会增加。这严重阻碍了Jsart的便利。目前,流敏感别名分析[ 19 ,28 ]和/或逃避分析[ 27 ,24 ]的初步介绍正在在考虑中。
5.2.2对信息流的支持不足
Jsart的安全评估应改进,以便提供更适当的安全警告(例如,减少遗漏和虚假的) 。例如,一些实现基于语言安全的信息流分析技术提出了[ 22 ] 。在实际的程序中,被隐式信息流[ 2 ]降级的访问级别不应该忽略不计。此外,一个字段变量的所需访问级别包含该字段变量的程序的执行过程中被频繁的改变。例如,某一字段有public访问权限在其初始化之前,但应该有default访问权限在改变后。
符合这种情况下,我们会考虑Jsart应提供了一种机制,允许程序员特意升级和降级任何字段变量的访问级别在其生命周期中。为了实现这种机制,保密性数据[ 23 ,3 ]的解密和擦除技术将推出。我们亦正研究针对各流的信息量的定量分析[ 4,21 ]。这些技术使在ALG访问级别的传播更成熟。
5.2.3访问级别标准的原方案
相对于在第3.3节中描述的访问级别的标准,我们必须进一步考虑。 Jsart采用了七个级别的标准基于一个定义在嵌套类中的字段变量不存储敏感数据的假设。但是,我们不知道这个标准是否对在重构中的任何形式的安全问题有用。对于一些重构变换,如详细的等级是没有必要的。例如,粗糙的标准只有三个阶段。如private,package和public将更适合这类安全意识的重构。一个基于可访问性约束规则[ 25 ]的访问级别标准是值得考虑的。
Jsart假设Java的访问性设置加强数据的保密性(和完整性) 。然而,这种假设似乎是脆弱的。因此,我们计划推出安全类型语言如Jflow [17]和它的后继Jif [ 11 ] 。 JIF用一种在编译时和运行时强制信息流控制和访问控制的机制扩展了Java。它允许程序员分配表示限制的安全标签在怎么使用数据上。这种基于标签的方法将提高Jsart的能力。
6.结论
虽然重构提升了现有程序的维护能力,有时使他们变得更脆弱。本文提出了一个安全感知重构工具,这是所谓Jsart。它检测修改后的代码的中的字段变量访问级别的降级,并向程序员提供一个关于检测到的降级的的信息。
Jsart的开发仍在继续。除了在5.2节中描述的开放性问题,这两个问题主要停留在优化阶段。首先,Jsart目前只支持两个重构转换。对于其他转换的支持是一个紧迫的问题。幸运的是,Jsart跟着支持多种重构变换,其中一些涉及到安全意识重构的Jrbx,。参照Jrbx的实现,我们很容易扩展Jsart,以支持更多的转换。
接下来,我们发现了几个危险的重构[14]。他们中的一些涉及一种多态的机制。例如,提取子类,提取超类,表单模板方法,和允许多态性与重构变换的子类有条件的替换。也就是说,它们允许攻击者有机会执行一个敌对的子类的代码。新的标准,如子类将被引入用于增强工具的有效性。对于子类,提取方法重构可能是危险的,因为它有时会促进一个局部变量变成参数。如果提取方法接收敏感数据作为参数,并由恶意的方法通过子类重写,攻击者将能够观察到这些数据。
致谢
这项工作部分由日本学术促进会(JSPS)的科学研究费补助金(C)(21500043)赞助。
7.参考文献
[2] M. Bishop. Computer Security. Addison-Wesley, 2003.
[3] S. Chong and A. C. Myers. End-to-end enforcement of erasure and
declassification. In Proc.CSF’08, pages 98–111,June 2008
[4] D. Clark, S. Hunt, and P. Malacaria. Quantitative analysis of the leakage of confidential data. ElectronicNotesTheoretical ComputerScience, 59(3):1–14, 2001.
[5] J. Ferrante, K. J. Ottenstein, and J. D. Warren. The program dependence graph and its use in optimization. ACM TOPLAS , 9(3):319–349, 1987.
[6] M. Fowler.Refactoring: ImprovingtheDesign of Existing Code. Addison-Wesley, 1999.
[7] J. A. Goguen and J. Meseguer. Security policies and security models. InProc.Symposium Security and Privacy, pages 11–20, April 1982.
[8] D. Gollmann. Computer Security, 2nd ed. John Wiley & Sons, 2006.
[9] G. Hoglund and G. McGraw. ExploitingSoftware: Howto BreakCode . Addison-Wesley, 2004.
[10] Java-XML Tools Project. Jxplatform. http://www.jtool.org/.
[11] Jif. Java information fl ow. http://www.cs.cornell.edu/jif/.
[12] U. P. Khedker, A. Sanyal, and B. Karkare. Data Flow Analysis: Theory andPractice. CRC Press, 2009.
[13] C. E. Landwehr, A. R. Bull, J. P. McDermott, and W. S. Choi. A taxonomy of computer program security flaws, with examples. ACMComputingSurveys, 26(3):211–254, 1994.
[14] K. Maruyama and K. Tokoda. Security-aware refactoring alerting its impact on code vulnerabilities. In Proc. APSEC’08, pages 445–452, 2008.
[15] K. Maruyama and S. Yamamoto. Design and implementation of an extensible and modifi able refactoring tool. In Proc. IWPC’05 , pages 195–204, 2005.
[16] T. Mens and T. Tourwé. A survey of software refactoring. IEEETrans. onSoftw. Eng. , 30(2):126–139, 2004.
[17] A. C. Myers. Jfl ow: Practical mostly-static information flow. In Proc.POPL’99, pages 228–241, January 1999.
[18] S. Oaks. Java Security, 2nd ed. Addison-Wesley, 2001.
[19] F. Ohata and K. Inoue. JAAT: Java alias analysis tool for program maintenance activities. In Proc. ISORC2006, pages 232–244, 2006.
[20] W. F. Opdyke. Refactoring object-oriented frameworks. Technical report, Ph.D. thesis, University of Illinois, Urbana-Champaign, 1992.
[21] A. D. Pierro, C. Hankin, and H. Wiklicky. Approximate non-interference. In Proc.CSFW’02, pages 1–15, June 2002.
[22] A. Sabelfeld and A. C. Myers. Language-based information-flow security. IEEEJournal onSelectedAreasin Communications , 21(1):5–19, 2003.
[23] A. Sabelfeld and D. Sands. Dimensions and principles of declassification. In Proc.CSFW’05, pages 255–269, June2005.
[24] A. Shi and G. Naumovich. Field escape analysis for data confidentiality in Java components. InProc.APSEC, pages 143–150, 2007.
[25] F. Steimann and A. Thies. From public to private to absent:Refactoring Java programs under constraine d accessibility.In Proc.ECOOP’09, pages 419–443, 2009.
[26] N. Walkinshaw, M. Roper, and M. Wood. The Java system dependence graph. In Proc.SCAM’03, pages 55–64, 2003.
[27] J. Whaley and M. Rinard. Compositional pointer and escape analysis for Java programs. In Proc.OOPSLA, pages 187–206, 1999.
[28] J. Woo, J. Woo, I. Attali, D. Caromel, J.-L. Gaudiot, and A. L. Wendelborn. Alias analysis for Java with reference-set epresentation. InProc.ICPADS , pages 459–466, 2001.