转 Fortofy扫描漏洞解决方案2

Fortify漏洞之Portability Flaw: File Separator 和 Poor Error Handling: Return Inside Finally

 

　　继续对Fortify的漏洞进行总结，本篇主要针对 Portability Flaw: File Separator 和  Poor Error Handling: Return Inside Finally 漏洞进行总结，如下：

1、Portability Flaw: File Separator（文件分隔符）

1.1、产生原因：

　　不同的操作系统使用不同的字符作为文件分隔符。例如，Microsoft Windows 系统使用“\”，而 UNIX 系统则使用“/”。应用程序需要在不同的平台上运行时，使用硬编码文件分隔符会导致应用程序逻辑执行错误，并有可能导致 denial of service（拒绝服务）。

 

例 1：以下代码使用硬编码文件分隔符来打开文件：
...
File file = new File(directoryName + "\\" + fileName);

 

1.2、修复方案：

　　为编写可移植代码，不应使用硬编码文件分隔符，而应使用语言库提供的独立于平台的 API。

例 2：下列代码执行与例 1 相同的功能，但使用独立于平台的 API 来指定文件分隔符：
...
File file = new File(directoryName + File.separator + fileName);
...    

 

 

2、Poor Error Handling: Return Inside Finally

2.1、产生原因：

　　finally 块中的返回指令会导致从 try 块中抛出的异常丢失。

 

例 1：在下列代码中，调用 doMagic 方法，会导致抛出 Exception 异常，但该异常将不会传递给调用者，因为finally 块中的返回指令会导致异常的丢弃。

 

public static void doMagic() throws Exception {

　　try {

　　　　throw new Exception(“Something error!”);  //1.抛出异常

　　}catch(Exception e){         //2.捕获异常匹配，进入控制块

     　　    throw e;

　　}finally {                                //3.throw前控制转移到finally块，执行完后再返回

　　　　return true;               //4.控制转移，直接return，不再返回catch块，吃掉了异常

　　}

}

 

2.2、修复方案：

　　将返回指令移到 finally 块之外。如果必须要finally 块返回一个值，可以简单地将该返回值赋给一个本地变量，然后在 finally 块执行完毕后返回该变量。
　　1、不要在finally里面写return语句

 

3.1.10 Insecure Randomness

不安全的随机数：电脑是一种具有确定性的机器，因此不可能产生真正的随机性。伪随机数生成器 (PRNG) 近似于随机算法，始于一个能计算后续数值的种子。

PRNG 包括两种类型：统计学的 PRNG 和密码学的 PRNG。统计学的 PRNG 可提供有用的统计资料，但其输出结果很容易预测，因此数据流容易复制。若安全性取决于生成数值的不可预测性，则此类型不适用。密码学的 PRNG 通过可产生较难预测的输出结果来应对这一问题。为了使加密数值更为安全，必须使攻击者根本无法、或极不可能将它与真实的随机数加以区分。通常情况下，如果并未声明 PRNG 算法带有加密保护，那么它有可能就是一个统计学的 PRNG，不应在对安全性要求较高的环境中使用，其中随着它的使用可能会导致严重的漏洞（如易于猜测的密码、可预测的加密密钥、会话劫持攻击和 DNS 欺骗）。

 

解决方法：ESAPI的确是个不错的工具，使用它提供的方法可以规避该漏洞，代码很简单：

 

var random=ESAPI.randomizer().getRandomInteger(0,100);

这里简单解释下，参数0和100可以随意设置，意思是生成0到100之间的随机数，如果你想随机数被预测到概率更低，不妨将两个参数的差值设置足够大。