NO.13 生产环境增量更新漏洞

 

 知识库总目录： No.0 Web开发知识库

 

    出于对于更新效率的要求，我们在更新生产环境时，比较多的是采用增量更新的方式：即仅将需要更新的文件打个包，在生产环境解压（一般需要重启服务）即可完成更新。
    而在这个过程中有几种漏洞，不可不察。
   
1.内部类
    对于java文件更新申请人一般提交的是源文件（即java文件）而非编译后文件，然而增量更新打包清单往往仅根据源文件清单生成而来；
    但若某个源文件中存在内部类，其编译后，每个内部类会独自生成一个class文件，更新清单会将其遗漏。
    因此建议由更新申请人应注明本次更新中存在内部类的java文件，由更新执行人手工修改更新清单，将内部类class文件补全
    例：
    A.java

import java.util.TimerTask; public class A{ public class B{ } public void aMethod(){ class C{ } } public void bMethod(){ new TimerTask() { public void run() { } }; } }     

    A.java中有个puclic class A，A中有个成员内部类 B,方法内部类C，还有一个匿名内部类new TimerTask()
    则编译出的class文件有
    A.class
    A$B.class
    A$1C.class
    A$1.class
   
2.特殊配置文件
    特殊配置文件即上篇中提到的生产、测试环境配置内容有差异的配置文件。
    由于无论是开发环境，还是基线测试环境，这些特殊配置文件中内容都是配置的测试环境内容，当这种文件需要提交更新时，提交人一般提交的是测试版(要先发布在基线测试环境上)，而后续又将测试版发布在生产环境，后果相当严重。
    此时，也建议由更新申请人应注明本次更新中存的特殊配置文件，以便执行人做后续处理。

 

   
3.常量
    先看一个例子：

A.java public final static String MESSAGE="我是常量串"; B.java public aMethod(){ String b = A.MESSAGE; }     
    原代码中B跟A有关系，不过编译后就跟A没啥关系了，B编译完后就成了这个样子:
B.class public aMethod(){ String b = "我是常量串"; }      
    所以当常量内容发生变化修改了常量所在的类后，只更新这个类没有用，而是需更新所有调用类。