建议
要防止类被克隆,可以将清单 4 中所示的方法添加到您的类中:
清单 4. 使您的代码不可克隆
Java代码
public final Object clone()
throws java.lang.CloneNotSupportedException{
throw new java.lang.CloneNotSupportedException();
}
如果想让您的类可克隆并且您已经考虑了这一选择的后果,那么您仍然可以保护您的类。要做到这一点,请在您的类中定义一个为 final 的克隆方法,并让它依赖于您的一个超类中的一个非 final 克隆方法,如清单 5 中所示:
清单 5. 以安全的方式使您的代码可克隆
Java代码
public final Object clone()
throws java.lang.CloneNotSupportedException {
super.clone();
}
类中出现 clone() 方法防止攻击者重新定义您的 clone 方法。
使类不可序列化
序列化允许将类实例中的数据保存在外部文件中。闯入代码可以克隆或复制实例,然后对它进行序列化。
影响
序列化是令人担忧的,因为它允许外部源获取对您的对象的内部状态的控制。这一外部源可以将您的对象之一序列化成攻击者随后可以读取的字节数组,这使得攻击者可以完全审查您的对象的内部状态,包括您标记为 private 的任何字段。它也允许攻击者访问您引用的任何对象的内部状态。
建议
要防止类中的对象被序列化,请在类中定义清单 6 中的 writeObject() 方法:
清单 6. 防止对象序列化
Java代码
private final void writeObject(ObjectOutputStream out)
throws java.io.NotSerializableException {
throw new java.io.NotSerializableException("This object cannot be serialized");
}
通过将 writeObject() 方法声明为 final,防止了攻击者覆盖该方法。
使类不可逆序列化
通过使用逆序列化,攻击者可以用外部数据或字节流来实例化类。
影响
不管类是否可以序列化,都可以对它进行逆序列化。外部源可以创建逆序列化成类实例的字节序列。这种可能为您带来了大量风险,因为您不能控制逆序列化对象的状态。请将逆序列化作为您的对象的另一种公共构造器 ― 一种您无法控制的构造器。
建议
要防止对对象的逆序列化,应该在您的类中定义清单 7 中的 readObject() 方法:
清单 7. 防止对象逆序列化
Java代码
private final void readObject(ObjectInputStream in)
throws java.io.NotSerializableException {
throw new java.io.NotSerializableException("This object cannot be deserialized");
}
通过将该方法声明为 final ,防止了攻击者覆盖该方法。
避免硬编码敏感数据
您可能会尝试将诸如加密密钥之类的秘密存放在您的应用程序或库的代码。对于你们开发人员来说,这样做通常会把事情变得更简单。
影响
任何运行您的代码的人都可以完全访问以这种方法存储的秘密。没有什么东西可以防止心怀叵测的程序员或虚拟机窥探您的代码并了解其秘密。
建议
可以以一种只可被您解密的方式将秘密存储在您代码中。在这种情形下,秘密只在于您的代码所使用的算法。这样做没有多大坏处,但不要洋洋得意,认为这样做提供了牢固的保护。您可以遮掩您的源代码或字节码 ― 也就是,以一种为了解密必须知道加密格式的方法对源代码或字节码进行加密 ― 但攻击者极有可能能够推断出加密格式,对遮掩的代码进行逆向工程从而揭露其秘密。
这一问题的一种可能解决方案是:将敏感数据保存在属性文件中,无论什么时候需要这些数据,都可以从该文件读取。如果数据极其敏感,那么在访问属性文件时,您的应用程序应该使用一些加密/解密技术。
查找恶意代码
从事某个项目的某个心怀叵测的开发人员可能故意引入易受攻击的代码,打算日后利用它。这样的代码在初始化时可能会启动一个后台进程,该进程可以为闯入者开后门。它也可以更改一些敏感数据。
这样的恶意代码有三类:
·类中的 main 方法
·定义过且未使用的方法
·注释中的死代码
影响
入口点程序可能很危险而且有恶意。通常,Java 开发人员往往在其类中编写 main() 方法,这有助于测试单个类的功能。当类从测试转移到生产环境时,带有 main() 方法的类就成为了对应用程序的潜在威胁,因为闯入者将它们用作入口点。
请检查代码中是否有未使用的方法出现。这些方法在测试期间将会通过所有的安全检查,因为在代码中不调用它们 ― 但它们可能含有硬编码在它们内部的敏感数据(虽然是测试数据)。引入一小段代码的攻击者随后可能调用这样的方法。
避免最终应用程序中的死代码(注释内的代码)。如果闯入者去掉了对这样的代码的注释,那么代码可能会影响系统的功能性。
可以在清单 8 中看到所有三种类型的恶意代码的示例:
清单 8. 潜在恶意的 Java 代码
Java代码
public void unusedMethod(){
// code written to harm the system
}
public void usedMethod(){
//unusedMethod(); //code in comment put with bad intentions,
//might affect the system if uncommented
// int x = 100;
// x=x+10; //Code in comment, might affect the
//functionality of the system if uncommented
}
建议
应该将(除启动应用程序的 main() 方法之外的) main() 方法、未使用的方法以及死代码从应用程序代码中除去。在软件交付使用之前,主要开发人员应该对敏感应用程序进行一次全面的代码评审。应该使用“Stub” 或“dummy”类代替 main() 方法以测试应用程序的功能。
对付中等严重性暴露的技巧
请遵循下列建议以避免中等严重性静态安全性暴露:
·不要依赖初始化
·不要通过名称来比较类
·不要使用内部类
不要依赖初始化
您可以不运行构造器而分配对象。这些对象使用起来不安全,因为它们不是通过构造器初始化的