Fortify分析翻译4
上一篇 / 下一篇 2008-08-27 15:06:20 / 个人分类：Fortify
Fortify分析翻译4
http://user.qzone.qq.com/281696143/blog/1219395660
10.System Information Leak(Data Flow)：
10.1.BizApplicationApprovalBackingBean.java.
logger.error("BizApplicationApprovaBB 出错:" + e.getMessage());
10.2.Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
展现系统数据或调试信息将帮助攻击者了解系统和制定攻击的计划。
就是系统消息泄露。
10.3.EXPLANATION 解释
An information leak occurs
when system data or debugging information leaves the program
through an output stream or logging function.
当系统数据或者调试数据离开程序进入输出流或者日志函数中的时候，信息漏洞就出现了。
In this case printStackTrace() is called
in bizprocess/loanorigination/bizapplication/starttask/bizservice/BizElementMapping.java
at line 78.
在这个例子中printStackTrace()在BizElementMapping.java的第78行被调用。
Example: The following code prints an exception to the standard error stream:
例如：下面的代码打印异常到标准的错误流中：
try {
...
} catch (Exception e) {
e.printStackTrace();
}
Depending upon the system configuration,
this information can be dumped to a console, written to a log file,
or exposed to a remote user.
In some cases the error message tells the attacker precisely
what sort of an attack the system is vulnerable to.
For example, a database error message can reveal
that the application is vulnerable to a SQL injection attack.
Other error messages can reveal more oblique clues about the system. In the example above,
the search path could imply information about the type of operating system,
the applications installed on the system,
and the amount of care that the administrators have put into configuring the program.
依靠系统配置，这些信息会被倾泻到控制台上，写入日志文件，或者暴露给一个远程的用户。
在一些情况下，错误信息准确的告诉攻击者，系统弱点的类型。
例如，一个数据库错误信息可以暴露出，应用程序容易受到SQL注入的攻击。
其它的错误信息将暴露更多的关于系统的弱点的线索。在上面的例子中，
搜索路径将暗示了如下信息，操作系统的类型，应用程序安装在系统中，
和管理员设置进程序中的重要信息.
10.4.RECOMMENDATIONS 建议
Write error messages with security in mind. In production environments,
turn off detailed error information in favor of brief messages.
Restrict the generation and storage of detailed output
that can help administrators and programmers diagnose problems.
Be careful, debugging traces can sometimes
appear in non-obvious places (embedded in comments in the HTML for an error page, for example).
写错误信息的时候，头脑中应该有安全意识。在生产环境中，
关掉详细错误信息，输出摘要信息。
限制信息的产生和详细输出的存储可以帮助管理员和程序员诊断程序。
小心，调试信息有时候也会显示在确定的地方(嵌在错误html页面中的注释，例如)。
Even brief error messages that do not reveal stack traces or database dumps
can potentially aid an attacker. For example,
an "Access Denied" message can reveal that a file or user exists on the system.
甚至没有暴露堆栈信息或者数据库信息的简短错误信息都可以隐含的帮助攻击者。例如，
一个"存取拒绝"信息可以显示，一个文件或者用户存在系统中。
10.5.TIPS 提示
10.5.1. Do not rely on wrapper scrīpts, corporate IT policy,
or quick-thinking system administrators to prevent system information leaks.
Write software that is secure on its own.
不要依赖包装的脚本，共同的IT政策，或者快速思考的管理员来预防系统信息漏洞。
在软件中考虑它的安全。
10.5.2. This category of vulnerability does not apply to all types of programs.
For example, if your application executes on a client machine
where system information is already available to an attacker,
or if you print system information only to a trusted log file,
you can use AuditGuide to filter out this category.
这个弱点的分类不能应用在所有类型的程序中。
例如，如果你的程序在一个客户端机器上执行，
系统信息总是可以有效的显示给攻击者，
或者如果你仅仅打印系统信息到一个可信任的日志文件，
你可以通过审核过滤掉这些分类。
11.Unreleased resource:Streams(Control Flow):
11.1.ApproveCenterConfig.java.
InputStream s = ApproveCenterConfig.class. getResourceAsStream
("/cn/ccb/clpm/common/rule/ApproveCenterConfigFile.xml");
11.2.The program can potentially fail to release a system resource.
程序有可能不能释放系统资源。
在此处指变量s有可能没有释放资源。
11.3.EXPLANATION 解释
The program can potentially fail to release a system resource.
In this case,
there are program paths on which the resource allocated
in rule/common/ApproveCenterConfig.java at line 28 is not released.
程序有可能不能释放系统资源。
在这个例子中，
有一个程序路径不能释放，这个程序路径在ApproveCenterConfig.java的28行。
Resource leaks have at least two common causes:
资源漏洞至少有两个普通的原因：
- Error conditions and other exceptional circumstances.
错误条件和其它异常情况。
- Confusion over which part of the program is responsible for releasing the resource.
有责任释放资源的程序块是混乱的。
Most unreleased resource issues result in general software reliability problems,
but if an attacker can intentionally trigger a resource leak,
the attacker might be able to launch a denial of service attack by depleting the resource pool.
大多数没有释放资源的问题被归类为常见的软件可靠性问题，
但是如果一个攻击者有意的引发一个资源漏洞，
攻击者可以通过耗尽资源池来使服务停止。
Example 1: The following method never closes the file handle it opens.
The finalize() method for FileInputStream eventually calls close(),
but there is no guarantee as to
how long it will take before the finalize() method will be invoked.
In a busy environment, this can result in the JVM using up all of its file handles.
例子1：下面的方法没有关闭打开的文件。
这个为FileInputStream服务的finalizi()方法最后会调用close(),
但是没有保证，finalize()方法被调用需要多久。
private void processFile(String fName) throws FileNotFoundException, IOException
{
FileInputStream fis = new FileInputStream(fName);
int sz;
byte[] byteArray = new byte[BLOCK_SIZE];
while ((sz = fis.read(byteArray)) != -1) {
processBytes(byteArray, sz);
}
}
Example 2: Under normal conditions, the following code executes a database query,
processes the results returned by the database, and closes the allocated statement object.
But if an exception occurs while executing the SQL or processing the results,
the statement object will not be closed. If this happens often enough,
the database will run out of available cursors and not be able to execute any more SQL queries.
例子2:正常的情况下，下面的代码执行一个数据库查询，
通过数据库处理结果，并且关闭分配的statement对象。
但是如果当执行SQL或者处理结果的时候，出现了异常，
statement对象将无法关闭。如果这种情况经常发生，
数据库将会在没有可用的游标下运行，并且不能去执行更多的SQL查询。
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(CXN_SQL);
harvestResults(rs);
stmt.close();
11.4.RECOMMENDATIONS 建议
11.4.1. Never rely on finalize() to reclaim resources.
In order for an object's finalize() method to be invoked,
the garbage collector must determine that the object is eligible for garbage collection.
Because the garbage collector is not required to run unless the JVM is low on memory,
there is no guarantee that an object's finalize() method will be invoked in an expedient fashion.
When the garbage collector finally does run,
it may cause a large number of resources to be reclaimed in a short period of time,
which can lead to "bursty" performance and lower overall system throughput.
This effect becomes more pronounced as the load on the system increases.
不要依赖于finalize()去收回资源。
为了一个对象的finalize()被调用，垃圾回收器会决定对垃圾回收器来说，对象是合格的。
因为直到JVM是在一个低内存状态的情况下，垃圾回收器才需要运行。
一个对象的finalize()函数将以一种有利的方式运行，这是没有保证的。
当垃圾回收器最后运行的时候，他将会使一大批资源在一个很短的时间内回收，
此时将会导致系统吞吐量变低。
当系统要加载的东西增多的时候，这些影响更加可以断定。
Finally, if it is possible for a resource reclamation operation to hang
(if it requires communicating over a network to a database, for example),
then the thread that is executing the finalize() method will hang.
最后，如果对于一个资源回收操作有可能挂起(如果它需要通过网络和数据库通信，例如)，
于是执行finalize()函数的线程将会挂起。
11.4.2. Release resources in a finally block.
The code for Example 2 should be rewritten as follows:
在最后的语句块中释放资源。
例子2的代码可以像下面一样重写：
public void execCxnSql(Connection conn) {
Statement stmt;
try {
stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(CXN_SQL);
...
}
finally {
if (stmt != null) {
safeClose(stmt);
}
}
}
public static void safeClose(Statement stmt) {
if (stmt != null) {
try {
stmt.close();
} catch (SQLException e) {
log(e);
}
}
}
This solution uses a helper function to log the exceptions that might occur
when trying to close the statement. Presumably this helper function will be reused
whenever a statement needs to be closed.
当尝试关闭statement的时候，这个解决方案使用一个帮助函数记录异常。
当一个statement需要关闭的时候，大概这个帮助函数将被重新使用。
Also, the execCxnSql method does not initialize the stmt object to null.
Instead, it checks to ensure that stmt is not null before calling safeClose().
Without the null check, the Java compiler reports that stmt might not be initialized.
This choice takes advantage of Java's ability to detect uninitialized variables.
If stmt is initialized to null in a more complex method,
cases in which stmt is used without being initialized will not be detected by the compiler.
当然，这个execCxnSql方法不能初始化stmt对象为null.
首先，它将检查并确保，在调用safeClose()之前stmt不是null.
没有null检查，Java编译器报告，stmt没有被初始化。
这种选择，利用了Java编译器的能力，去检测没有初始化的变量。
如果stmt在一个更加复杂的方法中被赋值为null,
stmt没有被初始化就使用的这种情况，将不会被编译器探测到。
12. Poor error handling:Overly broad throws(Structural)：
12.1.ArrangeMeetingBackingBean.java
public String makeMeetingVOFromMeetingId() throws Exception{
12.2.The method throws a generic exception making it harder for callers
to do a good job of error handling and recovery..
这个方法抛出一个一般的异常使得调用者很难做好错误处理和恢复。
12.3.EXPLANATION 解释
Declaring a method to throw Exception
or Throwable makes it difficult for callers to do good error handling and error recovery.
Java's exception mechanism is set up to make it easy for callers
to anticipate what can go wrong
and write code to handle each specific exceptional circumstance.
Declaring that a method throws a generic form of exception defeats this system.
定义一个抛出Exception或者Throwable的方法，对于调用者来说很难进行错误处理和错误恢复。
Java的异常机制是建立在，使调用者更容易预期错误是什么和写代码处理每个特殊异常情况。
定义一个抛出一般异常的方法打败了这个系统。
Example: The following method throws three types of exceptions.
例如：下面的方法抛出三种类型的异常.
public void doExchange()
throws IOException, InvocationTargetException,
SQLException {
...
}
While it might seem tidier to write
它看起来应该是处理异常的方法应该写的代码
public void doExchange()
throws Exception {
...
}
doing so hampers the caller's ability to understand and handle the exceptions that occur.
Further, if a later revision of doExchange() introduces a new type of exception
that should be treated differently than previous exceptions,
there is no easy way to enforce this requirement.
做这些，妨碍调用者理解和处理异常的能力。
更深一层的，如果一个修改的doExchange()引入了一种新类型的异常，
这个异常需要和以前的异常不同的处理方法，将不是那么容易来处理这个需求。
12.4.RECOMMENDATIONS 建议
Do not declare methods to throw Exception or Throwable.
If the exceptions thrown by a method
are not recoverable or should not generally be caught by the caller,
consider throwing unchecked exceptions rather than checked exceptions.
This can be accomplished by implementing exception classes
that extend RuntimeException or Error instead of Exception,
or add a try/catch wrapper in your method to convert checked exceptions to unchecked exceptions.
不要定义方法抛出Exception或者Throwable.
如果通过一个方法抛出的异常是不可恢复的，或者是不可捕捉的，
考虑抛出不可检查异常比抛出可以检查异常好。
这些可以通过实现继承RuntimeException或者Error的异常类来实现，
或者是在你的方法中增加一个try/catch包装，
来将可检查异常转化为不可检查异常。
http://user.qzone.qq.com/281696143/blog/1219395660
10.System Information Leak(Data Flow)：
10.1.BizApplicationApprovalBackingBean.java.
logger.error("BizApplicationApprovaBB 出错:" + e.getMessage());
10.2.Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
展现系统数据或调试信息将帮助攻击者了解系统和制定攻击的计划。
就是系统消息泄露。
10.3.EXPLANATION 解释
An information leak occurs
when system data or debugging information leaves the program
through an output stream or logging function.
当系统数据或者调试数据离开程序进入输出流或者日志函数中的时候，信息漏洞就出现了。
In this case printStackTrace() is called
in bizprocess/loanorigination/bizapplication/starttask/bizservice/BizElementMapping.java
at line 78.
在这个例子中printStackTrace()在BizElementMapping.java的第78行被调用。
Example: The following code prints an exception to the standard error stream:
例如：下面的代码打印异常到标准的错误流中：
try {
...
} catch (Exception e) {
e.printStackTrace();
}
Depending upon the system configuration,
this information can be dumped to a console, written to a log file,
or exposed to a remote user.
In some cases the error message tells the attacker precisely
what sort of an attack the system is vulnerable to.
For example, a database error message can reveal
that the application is vulnerable to a SQL injection attack.
Other error messages can reveal more oblique clues about the system. In the example above,
the search path could imply information about the type of operating system,
the applications installed on the system,
and the amount of care that the administrators have put into configuring the program.
依靠系统配置，这些信息会被倾泻到控制台上，写入日志文件，或者暴露给一个远程的用户。
在一些情况下，错误信息准确的告诉攻击者，系统弱点的类型。
例如，一个数据库错误信息可以暴露出，应用程序容易受到SQL注入的攻击。
其它的错误信息将暴露更多的关于系统的弱点的线索。在上面的例子中，
搜索路径将暗示了如下信息，操作系统的类型，应用程序安装在系统中，
和管理员设置进程序中的重要信息.
10.4.RECOMMENDATIONS 建议
Write error messages with security in mind. In production environments,
turn off detailed error information in favor of brief messages.
Restrict the generation and storage of detailed output
that can help administrators and programmers diagnose problems.
Be careful, debugging traces can sometimes
appear in non-obvious places (embedded in comments in the HTML for an error page, for example).
写错误信息的时候，头脑中应该有安全意识。在生产环境中，
关掉详细错误信息，输出摘要信息。
限制信息的产生和详细输出的存储可以帮助管理员和程序员诊断程序。
小心，调试信息有时候也会显示在确定的地方(嵌在错误html页面中的注释，例如)。
Even brief error messages that do not reveal stack traces or database dumps
can potentially aid an attacker. For example,
an "Access Denied" message can reveal that a file or user exists on the system.
甚至没有暴露堆栈信息或者数据库信息的简短错误信息都可以隐含的帮助攻击者。例如，
一个"存取拒绝"信息可以显示，一个文件或者用户存在系统中。
10.5.TIPS 提示
10.5.1. Do not rely on wrapper scrīpts, corporate IT policy,
or quick-thinking system administrators to prevent system information leaks.
Write software that is secure on its own.
不要依赖包装的脚本，共同的IT政策，或者快速思考的管理员来预防系统信息漏洞。
在软件中考虑它的安全。
10.5.2. This category of vulnerability does not apply to all types of programs.
For example, if your application executes on a client machine
where system information is already available to an attacker,
or if you print system information only to a trusted log file,
you can use AuditGuide to filter out this category.
这个弱点的分类不能应用在所有类型的程序中。
例如，如果你的程序在一个客户端机器上执行，
系统信息总是可以有效的显示给攻击者，
或者如果你仅仅打印系统信息到一个可信任的日志文件，
你可以通过审核过滤掉这些分类。
11.Unreleased resource:Streams(Control Flow):
11.1.ApproveCenterConfig.java.
InputStream s = ApproveCenterConfig.class. getResourceAsStream
("/cn/ccb/clpm/common/rule/ApproveCenterConfigFile.xml");
11.2.The program can potentially fail to release a system resource.
程序有可能不能释放系统资源。
在此处指变量s有可能没有释放资源。
11.3.EXPLANATION 解释
The program can potentially fail to release a system resource.
In this case,
there are program paths on which the resource allocated
in rule/common/ApproveCenterConfig.java at line 28 is not released.
程序有可能不能释放系统资源。
在这个例子中，
有一个程序路径不能释放，这个程序路径在ApproveCenterConfig.java的28行。
Resource leaks have at least two common causes:
资源漏洞至少有两个普通的原因：
- Error conditions and other exceptional circumstances.
错误条件和其它异常情况。
- Confusion over which part of the program is responsible for releasing the resource.
有责任释放资源的程序块是混乱的。
Most unreleased resource issues result in general software reliability problems,
but if an attacker can intentionally trigger a resource leak,
the attacker might be able to launch a denial of service attack by depleting the resource pool.
大多数没有释放资源的问题被归类为常见的软件可靠性问题，
但是如果一个攻击者有意的引发一个资源漏洞，
攻击者可以通过耗尽资源池来使服务停止。
Example 1: The following method never closes the file handle it opens.
The finalize() method for FileInputStream eventually calls close(),
but there is no guarantee as to
how long it will take before the finalize() method will be invoked.
In a busy environment, this can result in the JVM using up all of its file handles.
例子1：下面的方法没有关闭打开的文件。
这个为FileInputStream服务的finalizi()方法最后会调用close(),
但是没有保证，finalize()方法被调用需要多久。
private void processFile(String fName) throws FileNotFoundException, IOException
{
FileInputStream fis = new FileInputStream(fName);
int sz;
byte[] byteArray = new byte[BLOCK_SIZE];
while ((sz = fis.read(byteArray)) != -1) {
processBytes(byteArray, sz);
}
}
Example 2: Under normal conditions, the following code executes a database query,
processes the results returned by the database, and closes the allocated statement object.
But if an exception occurs while executing the SQL or processing the results,
the statement object will not be closed. If this happens often enough,
the database will run out of available cursors and not be able to execute any more SQL queries.
例子2:正常的情况下，下面的代码执行一个数据库查询，
通过数据库处理结果，并且关闭分配的statement对象。
但是如果当执行SQL或者处理结果的时候，出现了异常，
statement对象将无法关闭。如果这种情况经常发生，
数据库将会在没有可用的游标下运行，并且不能去执行更多的SQL查询。
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(CXN_SQL);
harvestResults(rs);
stmt.close();
11.4.RECOMMENDATIONS 建议
11.4.1. Never rely on finalize() to reclaim resources.
In order for an object's finalize() method to be invoked,
the garbage collector must determine that the object is eligible for garbage collection.
Because the garbage collector is not required to run unless the JVM is low on memory,
there is no guarantee that an object's finalize() method will be invoked in an expedient fashion.
When the garbage collector finally does run,
it may cause a large number of resources to be reclaimed in a short period of time,
which can lead to "bursty" performance and lower overall system throughput.
This effect becomes more pronounced as the load on the system increases.
不要依赖于finalize()去收回资源。
为了一个对象的finalize()被调用，垃圾回收器会决定对垃圾回收器来说，对象是合格的。
因为直到JVM是在一个低内存状态的情况下，垃圾回收器才需要运行。
一个对象的finalize()函数将以一种有利的方式运行，这是没有保证的。
当垃圾回收器最后运行的时候，他将会使一大批资源在一个很短的时间内回收，
此时将会导致系统吞吐量变低。
当系统要加载的东西增多的时候，这些影响更加可以断定。
Finally, if it is possible for a resource reclamation operation to hang
(if it requires communicating over a network to a database, for example),
then the thread that is executing the finalize() method will hang.
最后，如果对于一个资源回收操作有可能挂起(如果它需要通过网络和数据库通信，例如)，
于是执行finalize()函数的线程将会挂起。
11.4.2. Release resources in a finally block.
The code for Example 2 should be rewritten as follows:
在最后的语句块中释放资源。
例子2的代码可以像下面一样重写：
public void execCxnSql(Connection conn) {
Statement stmt;
try {
stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(CXN_SQL);
...
}
finally {
if (stmt != null) {
safeClose(stmt);
}
}
}
public static void safeClose(Statement stmt) {
if (stmt != null) {
try {
stmt.close();
} catch (SQLException e) {
log(e);
}
}
}
This solution uses a helper function to log the exceptions that might occur
when trying to close the statement. Presumably this helper function will be reused
whenever a statement needs to be closed.
当尝试关闭statement的时候，这个解决方案使用一个帮助函数记录异常。
当一个statement需要关闭的时候，大概这个帮助函数将被重新使用。
Also, the execCxnSql method does not initialize the stmt object to null.
Instead, it checks to ensure that stmt is not null before calling safeClose().
Without the null check, the Java compiler reports that stmt might not be initialized.
This choice takes advantage of Java's ability to detect uninitialized variables.
If stmt is initialized to null in a more complex method,
cases in which stmt is used without being initialized will not be detected by the compiler.
当然，这个execCxnSql方法不能初始化stmt对象为null.
首先，它将检查并确保，在调用safeClose()之前stmt不是null.
没有null检查，Java编译器报告，stmt没有被初始化。
这种选择，利用了Java编译器的能力，去检测没有初始化的变量。
如果stmt在一个更加复杂的方法中被赋值为null,
stmt没有被初始化就使用的这种情况，将不会被编译器探测到。
12. Poor error handling:Overly broad throws(Structural)：
12.1.ArrangeMeetingBackingBean.java
public String makeMeetingVOFromMeetingId() throws Exception{
12.2.The method throws a generic exception making it harder for callers
to do a good job of error handling and recovery..
这个方法抛出一个一般的异常使得调用者很难做好错误处理和恢复。
12.3.EXPLANATION 解释
Declaring a method to throw Exception
or Throwable makes it difficult for callers to do good error handling and error recovery.
Java's exception mechanism is set up to make it easy for callers
to anticipate what can go wrong
and write code to handle each specific exceptional circumstance.
Declaring that a method throws a generic form of exception defeats this system.
定义一个抛出Exception或者Throwable的方法，对于调用者来说很难进行错误处理和错误恢复。
Java的异常机制是建立在，使调用者更容易预期错误是什么和写代码处理每个特殊异常情况。
定义一个抛出一般异常的方法打败了这个系统。
Example: The following method throws three types of exceptions.
例如：下面的方法抛出三种类型的异常.
public void doExchange()
throws IOException, InvocationTargetException,
SQLException {
...
}
While it might seem tidier to write
它看起来应该是处理异常的方法应该写的代码
public void doExchange()
throws Exception {
...
}
doing so hampers the caller's ability to understand and handle the exceptions that occur.
Further, if a later revision of doExchange() introduces a new type of exception
that should be treated differently than previous exceptions,
there is no easy way to enforce this requirement.
做这些，妨碍调用者理解和处理异常的能力。
更深一层的，如果一个修改的doExchange()引入了一种新类型的异常，
这个异常需要和以前的异常不同的处理方法，将不是那么容易来处理这个需求。
12.4.RECOMMENDATIONS 建议
Do not declare methods to throw Exception or Throwable.
If the exceptions thrown by a method
are not recoverable or should not generally be caught by the caller,
consider throwing unchecked exceptions rather than checked exceptions.
This can be accomplished by implementing exception classes
that extend RuntimeException or Error instead of Exception,
or add a try/catch wrapper in your method to convert checked exceptions to unchecked exceptions.
不要定义方法抛出Exception或者Throwable.
如果通过一个方法抛出的异常是不可恢复的，或者是不可捕捉的，
考虑抛出不可检查异常比抛出可以检查异常好。
这些可以通过实现继承RuntimeException或者Error的异常类来实现，
或者是在你的方法中增加一个try/catch包装，
来将可检查异常转化为不可检查异常。
相关阅读:
- Fortify分析翻译5 (flashtree, 2008-8-27)
- Fortify分析翻译6 (flashtree, 2008-8-27)
- Fortify分析翻译7 (flashtree, 2008-8-27)
TAG: Fortify
