最近项目的代码使用fortify工具扫描了一下,发现了项目中存在的一些问题,在以后代码编写的过程中要注意,避免出现类似的错误。
以下为本次代码分析工具FORTIFY对代码的分析结果。这些问题虽然古老、简单然而经典,也是需要引起重视。
代码问题主要集中在如下类别:存在安全隐患、存在资源泄漏隐患、序列化问题、字符串比较、异常处理问题,以及其它一些BAD PRACTICE和粗心引起的问题。
J2EE Bad Practices: Non-Serializable Object Stored in Session (Time and State, Structural)
把一个不可序列化的对象作为
代码示例
SharerInfo sharerInfo = new SharerInfo();
getServletRequest().getSession().setAttribute( “sharerInfo”, shareInfo);
其中SharerInfo类没有实现序列化(implements java.io.Serializable)
分析
对于不需要将对象序列化到同一jvm以外的应用场景,以上代码没有问题。然而考虑到系统的扩展性,以上问题应该予以避免。
以下是一些常见的会导致问题的场景:
1.
在一些大型应用系统的实现里,会考虑将部分SESSION里的对象钝化到数据库、磁盘里。
2.
在非session-sticky的集群环境里,应用服务器会在集群里广播、复制session数据
修正
Unreleased Resource
程序可能无法成功释放某一项系统资源
代码示例
Connection con = jdbcTemplate.getDataSource().getConnection();
}
Con.close();
分析
Mutable static field
将业务上不可变的静态值作为非final属性直接暴露给调用者
代码示例
public static
static {
}
分析
修正
Dropped or ignored exception
异常不做任何处理直接忽略
代码示例
直接将信息输出到标准输出
这是一种BAD PRACTICE。严重的情况下还会对系统性能造成冲击。
代码示例
e.printStackTrace.
分析
修正
如果想获取异常堆栈信息(e.printStackTrace),可以利用如下helper代码捕获整个异常堆栈信息:
return "thrown exception is null.no more exception information can provide..";
}
Checking String equality using == or !=
通过==而不是equals比较字符串数据。
代码示例
String a=”abc”
String b=”abc”;
System.out.println(a==b)
分析
String是个特殊情况。为了提高效率,JVM 维护了字符串池。以上代码里定义b时,b仍然指向a的指针,而不是重新分配一块内存给b.所以虽然对于a==b来说,比较的是地址指针,但a==b仍然为true.但对于如下场景 a==b将为false:
String a= “abc”;
String b= new String(“abc”);
System.out.println (a==b).
在以上代码里 new String重新为b分配了一块内存,所以结果将是false.
修正
重载方法名写错
代码示例
public int hashcode(Object o){
return this.a.hashCode()+this.b.hashCode();
}
分析
HTTP Response Splitting
对于XSS漏洞,通常情况下通过过滤转换<,>等敏感字符来防御。但对于http response splitting(报头分离)漏洞,还应该针对回车、换行这两个敏感字符进行过滤。
代码示例
response.addHeader("Content-Disposition", "attachment; filename="
修正
其它
其它包括一些粗心造成的代码问题。比如对Nuberm类型的数据进行如下比较:Numbera.equals(“”)等。
系统安全攻击问题
详见:http://download.csdn.net/detail/u011897392/9806386
具体问题请参见:http://blog.sina.com.cn/s/blog_62bcc50c0100g1vi.html