一、开发安全风险评估
| 序 | 开发安全规范 | 严重性 | 整改代价 | 优先级 | 级别 |
|---|---|---|---|---|---|
| 1 | 不要使用弃用的或过时的类和方法 | 高 | 中等 | 18 | 1 |
| 2 | 不要在clone()中调用可覆写的方法 | 中 | 低等 | 12 | 1 |
| 3 | 验证方法参数 | 高 | 高等 | 9 | 2 |
| 4 | 不要使用断言验证方法参数 | 中 | 中等 | 8 | 2 |
| 5 | 进行安全检测的方法必须声明为private或final | 中 | 中等 | 8 | 2 |
| 6 | 不要增加被覆写方法和被隐藏方法的可访问性 | 中 | 中等 | 8 | 2 |
| 7 | 确保构造函数不会调用可覆写的方法 | 中 | 中等 | 8 | 2 |
| 8 | 不要使用析构函数 | 中 | 中等 | 8 | 2 |
- 级别：L1高危害、可利用性强、整改代价低；
- L2中危害、可能被利用、整改代价中；
- 优先级：数值越高，越优先修复；
- 来源：Java安全编码标准/朗（Long, F.）等著，第七章
二、开发安全规范说明
1、不要使用弃用的或过时的类和方法
被弃用或过时的类和方法，并非在所有常用的操作系统上都可用，可能会导致拒绝服务或其他后果，因此不要在新代码中使用它们。
还有一些类和方法有特殊的使用限制，例如抽象类java.text.Format的所有子类是非线程安全的，必须避免在多线程应用中使用这些类。
JAVA提供了@deprecated注释来表示弃用的成员、方法、类，官方文档还提供了完整的弃用API的列表，链接如下：
2、不要在clone()中调用可覆写的方法
在clone()方法中调用可覆写的方法是不安全的。首先，一个恶意的子类可以对方法进行覆写并改变clone()方法的行为。其次，一个可信任的子类可以观察(并有可能修改)被克隆对象在创建完成之前的某一特定初始化的状态。
因此，clone()方法只能调用final或private的方法。
3、验证方法参数
对方法的参数进行验证，从而确保参数是在方法预计的范围内，保证了基于方法参数的操作能产生有效的结果。不进行参数验证会导致运算错误、异常执行、违反类不变性以及对象状态的不一致。
当方法接受不可信任的参数时，为了安全起见，这些方法必须在被调用方进行参数验证。这适用于所有public的方法和库，还有部分的private方法（参数直接来自public方法的参数）。
建议将验证参数的代码封装在一个地方，可减小代码大小并保证验证规则的一致性。
4、不要使用断言验证方法参数
参数检验通常是方法安全规范的一部分，并且无论断言是有效或无效的，都必须保持参数检验。而使用断言验证方法参数，在禁用断言时，将不会执行参数检验。
错误的参数通常会抛出对应的程序运行异常（例如：IllegalArgumentException，IndexOutOfBoundsException或NullPointerException），而断言检验参数不合法时并不会抛出一个适当的异常，这将不利于异常处理，降低程序健壮性。
5、进行安全检测的方法必须声明为private或final
恶意的子类可以覆写执行安全检测的nonfial类的成员方法，并绕过安全检测，使得安全检测不起作用。因此，安全检测方法必须声明为private或final来避免覆写。
特例：声明为final的类不受这条规则的限制，因为final类的成员方法无法被覆写。
6、不要增加被覆写方法和被隐藏方法的可访问性
如果增加了被覆写方法和被隐藏方法的可访问性，恶意子类将拥有这些受限制的方法比预计中更大的访问权限。下表列出允许增加的可访问性变化：
| 原始权限 | 增加后权限 |
|---|---|
| public | public |
| protected | protected、public |
| 默认 | 默认、protected、public |
| private | 不能增加可访问性 |
例如：基类定义了protected void doLogic()方法，恶意子类Sub可重定义doLogic为public增加了可访问性，导致任何Sub的使用者都能调用doLogic方法。
因此，程序只能在必要的时候对方法进行覆写，并且必须尽可能地将方法声明为final以避免恶意扩展。例如：基类定义protected final void doLogic()，可避免增加可访问性。
7、确保构造函数不会调用可覆写的方法
允许构造函数调用可覆写的方法，会提供给攻击者在对象创建完成前对this引用的访问权，这将导致应用的漏洞。另一方面，在构造函数中调用可覆写的方法可能访问到未初始化的数据，进而导致执行异常或预期外的结果。
因此，构造函数只能调用final或private的方法。
8、不要使用析构函数
不恰当地使用析构函数会造成可回收对象的重新引用，导致拒绝服务漏洞。
析构函数有以下问题：
1、析构函数的执行是没有固定时间的，可能会滞后任意长的时间。因此，在析构函数中调用时效性强的功能（例如关闭文件句柄）会导致程序异常。
2、Java并没有保证析构函数一定会在进程结束时执行，因此，在析构函数中更新持久状态会失败，而且不会有警告。例如：System.runFinalization()、 System.runFinalizersOnExit()、Runtime.runFinalizerOn-Exit()和System.gc()的方法，要么是没有提供一定会在进程结束时执行的保证，要么是缺乏安全性和有死锁的可能而被废弃。
3、析构函数的调用时无序的，不同对象的析构函数可以以不同的次序甚至并发地调用。这对维持预期的程序不变性造成很大困难。
4、当析构函数抛出的异常转递至方法finalize之外时，进程会立即停止，因此无法实现异常处理的意图。而且析构函数的中断可能阻止后续析构函数的执行，造成不可预料的结果。
5、程序员可能会在finalize方法中无意地重新使用了对象的引用。在这种情况下，垃圾回收器必须再次判断是否可以释放对象。并且，因为已经执行了finalize方法，所以垃圾回收器不会再次调用它。
6、垃圾回收器时常依赖于内存的可用性和使用情况，而与其他特定资源的缺乏无关。因此，当有足够内存时，一种不足的资源也可能会被耗尽，即使析构函数的执行可以释放稀少的资源。
7、析构函数增加了垃圾回收的时间并带来了空间上的开销。由于析构函数延长了许多对象的生命期，这干扰了新一代的垃圾回收器的操作。编写错误的析构函数还可能尝试终结可达到的对象，这违背了预期的目标并可能违反程序的常量。
8、析构函数的使用会带来同步化的问题，即使是在余下的程序是单线程的情况下。垃圾回收器会从它所选择的一个或多个线程中调用finalize方法；虽然并不一定，但这些线程通常是和main线程截然不同的。当必须使用析构函数时，必须避免同步访问任何需要清理的数据结构。
9、在析构函数中使用锁和其他基于同步的机制会导致死锁或饥饿。存在这种可能性是因为不能保证或控制析构函数的调用次序和析构函数的运行线程。
正是基于上述这些问题，必须避免在新的类中使用析构函数。
