Fortify分析翻译10

                    http://user.qzone.qq.com/281696143/blog/1220335112 Ronger
25.Denial of service(Data Flow)：
25.1.源文件：Metronome.java
代码：sleep(thisTime);
25.2.原文：An attacker could cause the program to crash or otherwise become unavailable to legitimate users.
翻译：攻击者可以使程序崩溃，否则为了让自己变成合法用户而让程序变得不可用。
理解：如果给变量thisTime一个很大的值,就可以让本线程一直sleep下去，所以这种风险类型归纳为服务拒绝。
25.3.EXPLANATION 解释
Attackers may be able to deny service to legitimate users by flooding the application
with requests, but flooding attacks can often be defused at the network layer.
More problematic are bugs
that allow an attacker to overload the application using a small number of requests.
Such bugs allow the attacker to specify the quantity of system resources their requests
will consume or the duration for which they will use them.
攻击者可以通过大量的发送请求给应用程序，对合法用户拒绝服务，
但是淹没式的攻击常常在网络层被拒绝。
许多的问题是程序臭虫，允许攻击者使用少量的请求使应用程序超过负载。
一些臭虫允许攻击者详细列出系统资源的数量，
他们的请求将消耗应用程序的一部分时间。
Example 1: The following code allows a user to specify the amount of time for
which a thread will sleep. By specifying a large number,
an attacker can tie up the thread indefinitely.
With a small number of requests, the attacker can deplete the application's thread pool.
例子：下面的代码将允许一个用户详细列出一个线程将休眠的时间值。
通过指定一个很大的数值，攻击者有可能会约束这个线程。
通过很少数量的请求，攻击者可以耗尽应用程序的线程池。
  int usrSleepTime = Integer.parseInt(usrInput);
  Thread.sleep(usrSleepTime);
Example 2: The following code reads a String from a zip file.
Because it uses the readLine() method, it will read an unbounded amount of input.
An attacker can take advantage of this code to cause an OutOfMemoryException
or to consume a large amount of memory so
that the program spends more time performing garbage collection
or runs out of memory during some subsequent operation.
例子2：下面的代码从一个zip文件中读入字符串。
因为它使用readLine()方法，它将读入一个不可预知的输入。
攻击者可以利用这个代码产生一个内存溢出异常，或者消费一大块内存，
导致程序花费很多时间执行垃圾回收，或者在一些并发操作的过程中内存被完全占满。
  InputStream zipInput = zipFile.getInputStream(zipEntry);
  Reader zipReader = new InputStreamReader(zipInput);
  BufferedReader br = new BufferedReader(zipReader);
  String line = br.readLine();
25.4.RECOMMENDATIONS 建议
Validate user input to ensure that it will not cause inappropriate resource utilization.
验证用户输入去确认,它将不会导致不确当的源使用。
Example 1 Revisited: The following code allows a user to specify the amount of time for
which a thread will sleep, but only if the value is within reasonable bounds.
例子1 重新确认：下面的代码将允许一个用户详细列出一个线程将休眠的时间值，
但是仅仅当这个值是在合理的范围内。
  int usrSleepTime = Integer.parseInt(usrInput);
  if (usrSleepTime >= SLEEP_MIN &&
      usrSleepTime <= SLEEP_MAX) {
    Thread.sleep(usrSleepTime);
  } else {
    throw new Exception("Invalid sleep duration");
  }
}
Example 2 Revisited: The following code reads a String from a zip file.
The maximum string length it will read is MAX_STR_LEN characters.
例子 2 重新确认：下面的代码从一个zip文件中读入字符串。
它将读到的最大的字符串长度是MAX_STR_LEN。
  InputStream zipInput = zipFile.getInputStream(zipEntry);
  Reader zipReader = new InputStreamReader(zipInput);
  BufferedReader br = new BufferedReader(zipReader);
  StringBuffer sb = new StringBuffer();
  int intC;
  while ((intC = br.read()) != -1) {
    char c = (char) intC;
    if (c == '\n') {
      break;
    }
    if (sb.length() >= MAX_STR_LEN) {
      throw new Exception("input too long");
    }
    sb.append(c);
  }
  String line = sb.toString();
26.System information leak:missing catch block(structural)：
26.1.源文件：FileDownloadServlet.java
代码：public void doGet(HttpServletRequest req, HttpServletResponse rep)throws ServletException,IOException{
26.2.原文：If a Servlet fails to catch all exceptions, it may reveal debugging information that will help an adversary form a plan of attack..
翻译：如果一个Servlet不能捕捉所有异常，它将会显示出可以帮助攻击者制定攻击计划的调试信息，
理解： 该方法的全部程序如下：
public void doGet(HttpServletRequest req, HttpServletResponse rep)throws ServletException,IOException{
try{
doDownload(req, rep);
}catch(BizException ex){
throw new ServletException("File download failure",ex);
}
}
在该方法中只捕捉了BizException，这样如果出现ServletException或IOException的时候，
如果代码中包含一下代码：out.println("hello " + addr.getHostName());，将会存在风险。
26.3.EXPLANATION 解释
When a Servlet throws an exception,
the default error response the Servlet container
sends back to the user typically includes debugging information.
This information is of great value to an attacker.
For example, a stack trace might show the attacker a malformed SQL query string,
the type of database being used, and the version of the application container.
This information enables the attacker to target known vulnerabilities in these components.
当一个Servlet抛出一个异常，
默认错误反应的Servlet容器，发送给用户信息的时候，
通常包含调试信息。
这些信息对于攻击者来说非常有价值。
例如，一个堆栈的痕迹可以将SQL查询语句显示给攻击者，
使用的数据库类型，和应用程序容器的版本。
这些信息允许攻击者了解在这些组件中的漏洞。
Example 1: In the following method a DNS lookup failure
will cause the Servlet to throw an exception.
例子1：下面的方法中，一个DNS查找失败将导致Servlet抛出一个异常。
protected void doPost (HttpServletRequest req,                
                    HttpServletResponse res)
              throws IOException {
    String ip = req.getRemoteAddr();
    InetAddress addr = InetAddress.getByName(ip);
    ...
    out.println("hello " + addr.getHostName());
}
Example 2: The following method will throw a NullPointerException
if the parameter "name" is not part of the request.
例子2：下面的方法将抛出一个NullPointException,
如果参数"name"不是请求的一部分。
protected void doPost (HttpServletRequest req,                
                    HttpServletResponse res)
              throws IOException {
    String name = getParameter("name");
    ...
    out.println("hello " + name.trim());
}
26.4.RECOMMENDATIONS 建议
All top-level Servlet methods should catch Throwable,
thereby minimizing the chance that the Servlet's error response mechanism is invoked.
Example 3: The method from Example 1 should be rewritten as follows:
所有高级别的Servlet方法需要捕捉Throwable,
从而，减少Servlet的错误返回机制被调用的机会。
例子3：从例子1中的方法可以以下面的方式重写。
proteced void doPost (HttpServletRequest req,                
                    HttpServletResponse res) {
      try {
          String ip = req.getRemoteAddr();
          InetAddress addr = InetAddress.getByName(ip);
      ...
          out.println("hello " + addr.getHostName());
      }catch (Throwable t) {
          logger.error("caught throwable at top level", t);
      }
  }
}
27. J2EE bad practices:Leftover debug code(Structural)：   
27.1.源文件：BizElementMapping.java.
代码:  public static void main(String args[]){
27.2.原文：Debug code can create unintended entry points in a deployed web application.
翻译：在一个已经发布的web应用程序中，调试代码会创建一个无意识的入口。
理解：就是从项目的安全方面考虑，攻击者可以在web应用程序中直接调用main方法。
27.3.EXPLANATION 解释
A common development practice is to add "back door" code specifically designed
for debugging or testing purposes that is not intended to be shipped or deployed
with the application. When this sort of debug code is accidentally left in the application,
the application is open to unintended modes of interaction.
These back door entry points create security risks
because they are not considered during design or testing
and fall outside of the expected operating conditions of the application.
一个通常的开发习惯是增加"后门"代码，这些代码是为调试和测试而设计的，
而没有打算去运行或者发布在应用程序中。
当这种类型的调试代码意外的留在应用程序中，
应用程序将会有一些没有预料到的模式开放。
这些后门输入创建安全风险，
因为他们在设计和测试的时候没有考虑到并且变成在应用程序的可预期的操作条件之外。
The most common example of forgotten debug code is a main() method appearing
in a web application. Although this is an acceptable practice during product development,
classes that are part of a production J2EE application should not define a main().
被遗忘的调试代码的最常见的例子是出现在web应用程序中的main()方法。
虽然在产品的开发阶段，这些是可以接受的习惯，
作为一个J2EE应用产品的一部分，类不可以定义一个main().
27.4.RECOMMENDATIONS 建议
Remove debug code before deploying a production version of an application.
Regardless of whether a direct security threat can be articulated,
it is unlikely that there is a legitimate reason for such code
to remain in the application after the early stages of development.
在发布一个生产版本的应用程序之前，移除调试代码。
不管是否一个直接的安全威胁可以很清晰，
在开发阶段之后，在应用程序中保存这些代码，
所有合法的理由，都是不行的。
27.5.TIPS 提示
27.5.1. The presence of a main() method may represent the tip of an iceberg.
When you find a main(), look for other indications
that developers were rushed or otherwise not able to conclude their efforts normally.
一个main()方法的存在可以描绘出冰山一角。
当你发现一个main(),可以发现其它的迹象，
就是开发过程是匆忙的，或者以其它的方式不能正常地结束他们的努力。
27.5.2. If you are auditing a non-J2EE Java application,
the J2EE Bad Practices category might not apply to your environment.
If this is the case, you can use AuditGuide to suppress these issues.
如果你在审计一个非J2EE的Java应用程序，
这个J2EE的坏习惯分类将不能应用到你的环境中。
如果这里是这种情况，你可以使用AuditGuide挂起这些事件。

Fortify分析翻译9

                        http://user.qzone.qq.com/281696143/blog/1220322706  Ronger
24.Http response splitting(Data Flow):
24.1.源文件：WorkPageDispatcher.java.
代码：rep.sendRedirect(url);
24.2.原文：Including unvalidated data in an HTTP response header can enable cache-poisoning, cross-site scrīpting, cross-user defacement or page hijacking attacks.
翻译：在Http响应头中包含没有经过验证的数据将会使缓存中毒，经过的站点和经过的用户信息遭到毁坏，页面受到控制。
理解：在此处指url这个参数有可能会不安全。
24.3.EXPLANATION 解释
HTTP response splitting vulnerabilities occur when:
HTTP响应的漏洞出现在：
24.3.1. Data enters a web application through an untrusted source,
most frequently an HTTP request.
In this case the data enters at getParameterMap()
in web/common/WorkPageDispatcher.java at line 52.
数据通过一个不可信任的源进入web应用程序，
大多数是通过HTTP请求实现的。
在这个例子中，数据通过WorkPageDispatcher.java52行的getParameterMap()进入。
24.3.2. The data is included in an HTTP response header sent to a web user
without being validated for malicious characters.
In this case the data is sent at sendRedirect()
in web/common/WorkPageDispatcher.java at line 58.
没有验证恶意字符，数据被包含在响应头中发送给一个web用户。
在这个例子中，数据通过WorkPageDispatcher.java58行的sendRedirect()发送。
As with many software security vulnerabilities,
HTTP response splitting is a means to an end, not an end in itself.
At its root, the vulnerability is straightforward:
an attacker passes malicious data to a vulnerable application,
and the application includes the data in an HTTP response header.
就像许多软件安全性漏洞一样，
HTTP响应分离意味着结束，而不是自身的结束。
在它的根上，漏洞是直接了当的：
攻击这将恶意数据通过一个有漏洞的应用程序，
并且应用程序将这些数据包含在HTTP响应头中。
To mount a successful exploit, the application must allow input that contains CR
(carriage return, also given by %0d or \r)
and LF (line feed, also given by %0a or \n)characters into the header.
These characters not only give attackers control of the remaining headers
and body of the response the application intends to send,
but also allows them to create additional responses entirely under their control.
作为一个成功的使用，应用程序应该允许包含CR和LF的输入字符进入响应头。
这些字符不仅让攻击者控制存在的头信息和响应的内容，这个内容是应用程序准备发送的，
但是也要允许他们创建完全在控制之下的额外的响应。
Example: The following code segment reads the name of the author of a weblog entry,
author, from an HTTP request and sets it in a cookie header of an HTTP response.
例如：下面的代码片段读入一个weblog输入的作者名字，
作者，从一个HTTP请求，并且设置它在一个HTTP响应的cookie头中。
String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
     cookie.setMaxAge(cookieExpiration);
     response.addCookie(cookie);
Assuming a string consisting of standard alpha-numeric characters,
such as "Jane Smith",
is submitted in the request the HTTP response including this cookie
might take the following form:
假设字符完全是由标准alpha数字字符构成，
例如"Jane Smith",在请求中被提交，包含这个cookie的HTTP响应将采取下面的形式：
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
However, because the value of the cookie is formed of unvalidated user input
the response will only maintain this form
if the value submitted for AUTHOR_PARAM does not contain any CR and LF characters.
If an attacker submits a malicious string, such as "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...",
then the HTTP response would be split into two responses of the following form:
但是，因为cookie的值是和未经验证的用户输入相匹配的,响应将仅仅维持这种模式。
如果从AUTHOR_PARAM提交的值没有包含一些CR和LF字符。
如果攻击者提交一个恶意的字符，例如"Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...",
那么HTTP响应将分离为下面这样的两次响应。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
Clearly, the second response is completely controlled by the attacker
and can be constructed with any header and body content desired.
The ability of attacker to construct arbitrary HTTP responses permits a variety of resulting attacks,
including: cross-user defacement, web and browser cache poisoning,
cross-site scrīpting and page hijacking.
很明显的，第二次响应是完全被攻击者控制的，
并且可以通过一些头信息和渴望得到的内容信息来构造。
攻击者构造任意的HTTP响应的能力决定了结果攻击的多样性，
包括：用户被毁损，web和浏览器缓存中毒，
站点脚本和页面被修改。
Cross-User Defacement:
An attacker can make a single request to a vulnerable server
that will cause the server to create two responses,
the second of which may be misinterpreted as a response to a different request,
possibly one made by another user sharing the same TCP connection with the server.
This can be accomplished by convincing the user to submit the malicious request themselves,
or remotely in situations where the attacker
and the user share a common TCP connection to the server,
such as a shared proxy server. In the best case,
an attacker can leverage this ability to convince users that the application has been hacked,
causing users to lose confidence in the security of the application.
In the worst case,
an attacker may provide specially crafted content designed to mimic the behavīor of the application
but redirect private information, such as account numbers and passwords,
back to the attacker.
用户被毁损：
攻击者可以使用一个单独的请求到一个有漏洞的服务器上，
可以使这个服务器创建两个响应，这两个就可以被曲解为给不同的请求进行响应，
有可能另一个用户和服务器共享同样的TCP连接。
这些可以被实现，通过确信这个用户提交恶意的请求，
或者在远程的情况下，攻击者和用户共享通向服务器的TCP连接，
例如一个共享的代理服务器。在最好的情况下，
攻击者有这样的能力，确信应用程序已经砍掉的用户，
使用户失去对应用程序安全的信心。
在最坏的情况下，
攻击者可以提供特别的内容，这段内容设计为假装应用程序的行为，
但是使私人的信息改变方向，例如帐号和密码，
返回给攻击者。
Cache Poisoning:
The impact of a maliciously constructed response can be magnified
if it is cached either by a web cache used by multiple users
or even the browser cache of a single user.
If a response is cached in a shared web cache,
such as those commonly found in proxy servers,
then all users of that cache will continue receive the malicious content
until the cache entry is purged. Similarly,
if the response is cached in the browser of an individual user,
then that user will continue to receive the malicious content until the cache entry is purged,
although only the user of the local browser instance will be affected.
缓存中毒：
恶意数据构造响应的影响可以被放大的，
不管它是一个被很多用户使用的web缓存，还是一个用户使用的浏览器。
如果一个响应在一个共享的web缓存中被存储，
例如那些普通的在代理服务器上面的，
那么所有缓存中的用户将持续接受恶意内容，直到缓存输入被清除，
尽管仅仅本地的浏览器实例用户将被影响到。
Cross-Site scrīpting:
Once attackers have control of the responses sent by an application,
they have a choice of a variety of malicious content to provide users.
Cross-site scrīpting is common form of attack
where malicious Javascrīpt or other code included in a response
is executed in the user's browser.
The variety of attacks based on XSS is almost limitless,
but they commonly include transmitting private data like cookies
or other session information to the attacker,
redirecting the victim to web content controlled by the attacker,
or performing other malicious operations on the user's machine
under the guise of the vulnerable site.
The most common and dangerous attack vector against users of a vulnerable application
uses Javascrīpt to transmit session
and authentication information back to the attacker
who can then take complete control of the victim's account.
站点脚本：
一旦攻击者已经控制了通过应用程序发送的响应，
他们可以可以选择提供恶意内容给用户。
站点脚本也是一种攻击方式，在响应中的恶意Javascrīpt或者其它的代码在用户的浏览器中被执行。
建立在VSS基础上的攻击总是无限的，
但是他们常常包含传输的私有数据，比如cookies或者其它发给攻击者的session信息，
将发给用户的信息转发给被攻击者控制的web内容，
或者通过有弱点的站点的伪装，在用户的机器上执行其它的恶意操作。
最常用和危险的攻击有弱点的应用程序中的用户，
是使用Javascrīpt将session和安全信息传输给攻击者，
攻击者可以完全控制受害者的帐户。
Page Hijacking: In addition to using a vulnerable application to send malicious content
to a user, the same root vulnerability can also be leveraged
to redirect sensitive content generated by the server
and intended for the user to the attacker instead.
By submitting a request that results in two responses,
the intended response from the server and the response generated by the attacker,
an attacker can cause an intermediate node, such as a shared proxy server,
to misdirect a response generated by the server for the user to the attacker.
Because the request made by the attacker generates two responses,
the first is interpreted as a response to the attacker's request,
while the second remains in limbo.
When the user makes a legitimate request through the same TCP connection,
the attacker's request is already waiting and is interpreted as a response
to the victim's request. The attacker then sends a second request to the server,
to which the proxy server responds with the server generated request intended for the victim,
thereby compromising any sensitive information in the headers
or body of the response intended for the victim.
页面注入：除了使用有漏洞的应用程序发送恶意的内容给用户之外，
同根的弱点也可以产生杠杆作用，发送通过服务器产生的敏感信息，
并且通过用户发送给攻击者来代替。
通过提交一个在两个响应中产生的请求，这两个响应分别是从服务器来的响应和攻击者产生的响应，
攻击者可以使一个中间的代码，比如一个共享的代理服务器，
误导一个服务器产生的响应发送给攻击者。
因为攻击者制造的请求可以产生两个响应，
第一个被解释成一个回复攻击者的响应，当第二个还没有过来的时候。
当用户通过相同的TCP连接产生一个合法的请求时，
攻击者的请求通常正在等待，并且被解释为用户请求的响应。
攻击者马上发送第二个请求给服务器，
到代理服务器所产成的响应用户来的请求，
从而，危及头信息中的敏感信息和发送给用户的响应体。
24.4.RECOMMENDATIONS 建议
The solution to HTTP response splitting is to ensure
that input validation occurs in the correct places and checks for the correct properties.
HTTP响应分离的解决方案是确认，
输入验证存在正确的地方，并且是为关键属性检查使用的。
Since HTTP response splitting vulnerabilities occur
when an application includes malicious data in its output,
one logical approach is to validate data immediately
before it leaves the application. However,
because web applications often have complex
and intricate code for generating responses dynamically,
this method is prone to errors of omission (missing validation).
An effective way to mitigate this risk is to also perform input validation
for HTTP response splitting.
于是当应用程序在它的输出中包含恶意数据的时候，
HTTP响应分离漏洞出现了，一个逻辑上的方法是，在它离开应用程序之前，
马上验证数据。
但是，因为web应用程序常常有为了产生动态响应的复杂和难于理解的代码，
于是方法倾向于冗长的错误(缺少验证)。
减少这个风险的一个有效的方法就是为HTTP响应分离执行输入验证。
Web applications must validate their input to prevent other vulnerabilities,
such as SQL injection, so augmenting an application's existing input validation mechanism
to include checks for HTTP response splitting is generally relatively easy.
Despite its value, input validation for HTTP response splitting
does not take the place of rigorous output validation.
An application may accept input through a shared data store or other trusted source,
and that data store may accept input
from a source that does not perform adequate input validation.
Therefore, the application cannot implicitly rely on the safety of this or any other data.
This means the best way to prevent HTTP response splitting vulnerabilities
is to validate everything that enters the application or leaves the application destined
for the user.
web应用程序必须验证他们的输入，以预防其它漏洞，
比如SQL注入，所以加强应用程序输入验证机制，
包括HTTP响应分离检查一般是比较容易的。
不管如何，对于HTTP响应分离的输入验证不能代替严格的输入验证。
应用程序可以通过一个共享的输入存储或者其它的可信任的源接受输入，
并且数据存储可以接受没有充分的执行输入验证的源的输入。
所以，应用程序不能暗中依赖这些数据的安全。
这个意思就是，预防HTTP响应分离的最好方法就是，验证进入应用程序的任何数据和
离开应用程序发送给用户的数据。
The most secure approach to validation for HTTP response splitting
is to create a whitelist of safe characters
that are allowed to appear in HTTP response headers
and accept input composed exclusively of characters in the approved set.
For example, a valid name might only include alpha-numeric characters or an account number
might only include digits 0-9.
验证HTTP响应最安全的方法是创建一个列入优良名单的安全字符串，
这些字符串允许出现在HTTP响应头信息中，并且在经过核准的设置中接受专有的字符串。
例如，一个合法的名字将仅仅包含阿拉伯字母或者一个帐户仅仅包含数字0～9。
A more flexible, but less secure approach is known as blacklisting,
which selectively rejects or escapes potentially dangerous characters before using the input.
In order to form such a list,
you first need to understand the set of characters
that hold special meaning in HTTP response headers.
Although the CR and LF characters are at the heart of an HTTP response splitting attack,
other characters, such as ':' (colon) and '=' (equal),
have special meaning in response headers as well.
一个稍微灵活点的，但是不是那么安全的方法是建立黑名单，
在使用输入之前，有选择性的拒绝嵌在的危险字符。
未了匹配这样的一个列表，
你首先需要去理解在HTTP响应的头中保存特殊含义字符的设置。
当然CR和LF字符是一个HTTP响应分离攻击的关键字符，
其它字符，比如':'和'='，一样在响应的头中有特殊的含义。
Once you identify the correct points in an application
to perform validation for HTTP response splitting attacks
and what special characters the validation should consider,
the next challenge is to identify how your validation handles special characters.
The application should reject any input destined to be included in HTTP response headers
that contains special characters, particularly CR and LF, as invalid.
一旦你确认了一个应用程序中的正确输入，
为HTTP响应分离攻击执行验证的输入，并且验证需要注意的特殊字符是什么，
下一个挑战就是确认你的验证怎样处理特定的字符。
Many application servers attempt to limit an application's exposure
to HTTP response splitting vulnerabilities by providing implementations
for the functions responsible for setting HTTP headers
and cookies that perform validation for the characters essential
to an HTTP response splitting attack.
Do not rely on the server running your application to make it secure.
When an application is developed there are no guarantees about
what application servers it will run on during its lifetime.
As standards and known exploits evolve, there are no guarantees
that application servers will also stay in sync.
许多应用程序打算去限制应用程序的HTTP响应分离漏洞的暴露，
通过提供设置HTTP头和cookies的函数的实现，
cookies为基本的字符执行验证。
不要依赖服务器运行你的应用程序去确认。
当应用程序还在开发的时候，不能保证在它的生命周期中，
它将会运行在什么样的应用服务器上。
当标准和公认的开发在发展中，不能保证，应用程序的服务器也会同步。
24.5.TIPS 提示
1. Many HttpServletRequest implementations return a URL-encoded string from getHeader(),
will not cause a HTTP response splitting issue
unless it is decoded first because the CR and LF characters
will not carry a meta-meaning in their encoded form. However,
this behavīor is not specified in the J2EE standard and varies by implementation.
Furthermore, even encoded user input returned from getHeader()
can lead to other vulnerabilities, including open redirects and other HTTP header tampering.
许多HttpServletRequest实现从getHeader()中返回一个URL编码的字符串，
将不会出现HTTP响应分离的情况，直到它被第一次解码，
因为CR和LF字符在它们编码的过程中，将不支持一个meta样式的字符。
但是，在J2EE标准和通过实现变化的应用程序中，这些行为不会详细说明的。
此外，从getHeader()中返回的已经经过编码的用户输入可以导致其它的漏洞，
包括打开的重定向路径和其它的HTTP头信息篡改。
24.6.REFERENCES 引用
[1] Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks,
and Related Topics, A. Klein,
http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf
[2] HTTP Response Splitting, D. Crab,
http://www.infosecwriters.com/text_resources/pdf/HTTP_Response.pdf

          Fortify分析翻译8

                       http://user.qzone.qq.com/281696143/blog/1219905860 Ronger

22.Process Control（Data Flow）:
22.1.源文件：AgentServlet.java.
代码：obj = this.getClass().getClassLoader().loadClass(servletName).newInstance();
22.2.原文：Loading libraries from an untrusted source or in an untrusted environment
can cause an application to execute malicious commands on behalf of an attacker.
翻译：从一个不值得信任的库或者环境加载库将使得应用程序去执行一个恶意的攻击命令。
理解：在次不值得信任的库指的就是参数servletName。
22.3.EXPLANATION 解释
Process control vulnerabilities take two forms:
过程控制弱点可以归纳为两种模式：
- An attacker can change the name of the library that the program loads:
the attacker explicitly controls what the name of the library is.
一个攻击者可以改变程序加载的库的名字：
攻击者可以显式的控制库的名字是什么。
- An attacker can change the environment in which the library loads:
the attacker implicitly controls what the library name means.
一个攻击者可以改变库加载的环境：
攻击者可以隐式的控制库名字的用意。
In this case we are primarily concerned with the first scenario,
the possibility that an attacker may be able to control the name of the library that is loaded. Process control vulnerabilities of this type occur when:
在这种情况下，我们首先关注最早的设定，
可能是这样，攻击者能够控制加载的库的名字。
22.3.1. Data enters the application from an untrusted source.
In this case the data enters at getInitParameter()
in web/common/monitor/AgentServlet.java at line 143.
数据从一个不可信任的源进入应用程序。
在这种情况下，在AgentServlet.java的143行数据通过getInitParameter()进入。
22.3.2. The data is used as or as part of a string representing a library
that is loaded by the application.
In this case the library is loaded by loadClass()
in web/common/monitor/AgentServlet.java at line 147.
数据作为一个字符串或者字符串的一部分，这个字符串是用来描述通过应用程序导入的库的。
在这种请款下，库是通过loadClass()来加载，在AgentServlet.java的147行。
22.3.3. By executing code from the library,
the application gives the attacker a privilege or capability
that the attacker would not otherwise have.
通过执行从库中的代码，
应用程序给攻击者一个另外具有的特权或者能力。
Example 1: The following code from a privileged system utility
uses the system property APPHOME to determine the directory in
which it is installed and then loads a native library based on a relative path
from the specified directory.
例子1：下面的代码，使用了系统特性，使用系统属性APPHOME决定
安装的路径，并且基于这个路径的一个相对路径而加载一个临时的库。
...
String home = System.getProperty("APPHOME");
String lib = home + LIBNAME;
java.lang.Runtime.getRuntime().load(lib);
...
This code allows an attacker to load a library
and potentially execute arbitrary code with the elevated privilege of the application
by modifying the system property APPHOME to point
to a different path containing a malicious version of LIBNAME.
Because the program does not validate the value read from the environment,
if an attacker can control the value of the system property APPHOME,
then they can fool the application into running malicious code and take control of the system.
这段代码允许攻击者加载一个库，并且通过修改系统属性APPHOME指向一个不同的
包含恶意版本的LIBNAME，潜在的执行任意的代码。
因为程序没有验证从环境中读入的值，
如果攻击者可以控制系统属性APPHOME的值，
那么他们可以使应用程序执行恶意的代码并且控制系统。
Example 2: The following code uses System.loadLibrary() to load code
from a native library named library.dll,
which is normally found in a standard system directory.
例子2：下面的代码使用System.loadLibrary()，从一个命名为library.dll的临时库
中加载代码，library.dll通常可以在标准系统目录中可以找到。
...
System.loadLibrary("library.dll");
...
The problem here is that System.loadLibrary() accepts a library name,
not a path, for the library to be loaded.
From the Java 1.4.2 API documentation this function behaves as follows [1]:
这儿的程序是这样的，System.loadLibrary()接受一个库的名字，
不是一个路径，通过名字这个库被加载。
从Java1.4.2的API文档中，这个函数行为和下面的[1]一样。
A file containing native code is loaded from the local file system from a place
where library files are conventionally obtained.
The details of this process are implementation-dependent.
The mapping from a library name to a specific filename is done in a system-specific manner.
一个包含本地代码的文件是从本地文件系统加载的，这个本地文件系统是从库文件被包含的地方加载的。
这个过程的细节是由实现决定的。
从一个库名字到一个特定文件名的映射是由系统的样式决定的。
If an attacker is able to place a malicious copy of library.dll higher
in the search order than file the application intends to load,
then the application will load the malicious copy instead of the intended file.
Because of the nature of the application, it runs with elevated privileges,
which means the contents of the attacker's library.dll will now be run with elevated privileges,
possibly giving them complete control of the system.
如果攻击者能够可以对library.dll进行一个恶意的拷贝,
这个拷贝比应用程序加载的文件有更高的搜索顺序，
那么应用程序将加载这个恶意的拷贝代替已经确定的文件。
因为应用程序的本性，它将执行优先级更高的，
这个意味着攻击者的library.dll的内容将拥有更高优先级而被运行，
有可能让他们完全的控制系统。
22.4.RECOMMENDATIONS 建议
Do not allow users to control libraries loaded by the program.
In cases where user input must affect the choice of the library to load,
the application typically expects a particular input to take on only a very small set of values.
Rather than relying on the input to be safe and non-malicious,
the application should use the input only
to make a selection from a predetermined set of safe libraries.
If the input appears to be malicious,
the library to be loaded should either default to some safe selection from this set
or the program should gracefully decline to continue operation.
不要允许用户去控制程序加载的库。
在某种情况下，用户输入可以影响要加载的库的选择，
应用程序期望特别的输入可以进来，这些合法的值仅仅有一个很小的范围。
比依赖于输入更加安全和不会有恶意数据的是，
应用程序可以使用选择输入，从预先定义的安全库中选择。
如果输入显示为恶意的，
加载的库可以使用安全选择的库中的默认库，
或者程序可以拒绝继续执行。
An attacker can indirectly control the libraries
loaded by a program by modifying the environment.
The environment should not be trusted
and precautions should be taken to prevent an attacker
from using some manipulation of the environment to perform an attack.
Whenever possible,library names should be controlled by the application
and loaded using an absolute path passed to System.load().
System.loadLibrary() should be avoided because its behavīor is implementation dependent.
In cases where the path is not known at compile time,
an absolute path should be constructed from trusted values during execution.
Library names and paths read from the environment
should be sanity-checked against a set of invariants that define valid values.
攻击者可以通过修改环境，间接的控制程序加载的库。
环境是不可以信任的，并且要预防攻击者，使用对环境的处理来实施攻击。
当可能的时候，库名字应该被应用程序控制，并且使用一个绝对路径加载给System.load().
System.loadLibrary()最好避免使用，因为它的行为是依赖实现的。
在一些情况下，路径在编译时是不直到的，
在运行时一个绝对的路径可以从一个安全值构造。
库名字和路径从环境中读入，应该理智检查一系列定义好有效值的变量。
Other checks can sometimes be performed to detect
if the environment may have been tampered with. For example,
if a configuration file is world-writable, the program might refuse to run.
In cases where information about the library to be loaded is known in advance,
the program may perform checks to verify the identity of the file.
If a library should always be owned by a particular user
or have a particular set of access permissions assigned to it,
these properties can be verified programmatically before it is loaded.
其它的检查有时候也可以实施探测到，环境信息被篡改的时候。例如，
如果一个配置文件是可以被随便改写的，程序将拒绝执行。
在这种情况中，加载的库的信息是被预先知道的，
程序将实施检查去合适文件的合法性。
如果一个库总是被一个特殊的用户所拥有，或者有一个分配给它的特殊的存取许可，
这些属性在它被加载之前，可以被程序检测到。
In the end it may be impossible for a program to fully protect itself
from an imaginative attacker bent on controlling the libraries it loads.
You should strive to identify
and protect against every conceivable manipulation of input values and the environment.
The goal should be to shutdown as many attack vectors as possible.
最后，对于一个程序来说，不可能完全的保护它，被一个想象的攻击者基于控制加载的库方面的攻击。
你可以努力去核实，并且检查输入数据和环境的每一个可能的处理。
22.5.REFERENCES 引用
[1] Java 1.4.2 API Documentation, Sun Microsystems,
http://java.sun.com/j2se/1.4.2/docs/api/index.html
23．Password management(Data Flow)：
23.1.源文件：WLIContextHolder.java
代码：env.put(Context.SECURITY_CREDENTIALS, passwd);
23.2.原文：Storing a password in plaintext may result in a system compromise.
翻译：基于折衷考虑用一个清晰的文本保存密码。
理解：也是从项目的安全性（密码管理）方面来考虑，在次Fortify将次风险归纳为warning级别。
23.3.EXPLANATION 解释
Password management issues occur
when a password is stored in plaintext in an application's properties or configuration file.
密码管理情况出现在，当一个密码以明码保存在一个程序的属性或者配置文件中。
In this case, the password is read into the program at executeQuery()
in wf/common/WLIContextHolder.java at line 102 and used to access a resource at put()
in wf/common/WLIContextHolder.java at line 206.
在这种情况下，密码在WLIContextHolder.java的102行的executeQuery()被读入程序，
并且在WLIContextHolder.java的206行使用put()方法进行存取。
Example: The following code reads a password from a properties file
and uses the password to connect to a database.
例如：下面的代码使用一个属性文件读取密码，并且使用密码连接数据库。
...
Properties prop = new Properties();
prop.load(new FileInputStream("config.properties"));
String password = prop.getProperty("password");
DriverManager.getConnection(url, usr, password);
...
This code will run successfully,
but anyone who has access to config.properties can read the value of password.
If a devious employee has access to this information,
they can use it to break into the system.
这个代码将运行的很成功，
但是已经存取数据到config.properties的一些人可以读到密码的值。
如果一个雇员获得这些信息，他们可以使用它中断系统。
23.4.RECOMMENDATIONS 建议
A password should never be stored in plaintext. Instead,
the password should be entered by an administrator when the system starts.
If that approach is impractical,
a less secure but often adequate solution is to obfuscate the password
and scatter the de-obfuscation material around the system so that an attacker
has to obtain and correctly combine multiple system resources to decipher the password.
密码不能使用明码来存储。可以这样来操作，
当系统启动的时候，密码可以通过管理员输入。
如果这个方法不可行，
一个安全级别低点但是经常采用的解决方案是使密码模糊，
并且分散令人迷惑的信息围绕系统，于是攻击者要去包含和正确的结合系统的多个资源，
去译解密码。
Some third party products claim the ability to manage passwords in a more secure way.
For example, WebSphere Application Server 4.x uses a simple XOR encryption algorithm for obfuscating values,
but be skeptical about such facilities.
WebSphere and other application servers offer outdated and relatively weak encryption mechanisms
that are insufficient for security-sensitive environments.
For a secure solution,
the only viable option today appears to be a proprietary mechanism that you create.
一些第三方的产品以一些更加安全的方法，强化了管理密码的能力。
例如，WebSphere应用服务器4.x使用一个简单的XOR编码法则，进行模糊数据，
但是让人怀疑它的简易性。
WebSphere和其它的应用服务器提供了过时的和相对的虚弱的编码机制，
对一个安全敏感的环境来说，是不足的。
对一个安全的解决方案来说，
今天仅仅可行的选择是，显示你创建的私人拥有的密码的机制。
23.5.TIPS 提示
23.5.1. Fortify identifies password management issues by looking for functions
that are known to take passwords as arguments.
If a password is read in from outside the program
and does not pass through an identified de-obfuscation routine
before being used, then Fortify flags a password management issue.
Fortify通过扫描函数来确定密码管理事件，这个函数将密码当成参数。
如果一个密码从程序的外部读入，并且在被使用前，没有经过一个确定的模糊处理，
那么Fortify将标示为一个密码管理器事件。
23.5.2.To audit a password management issue,
trace through the program from the point at
which the password enters the system to the point at which it is used.
Look for code that performs de-obfuscation. If no such code is present,
then this issue has not been mitigated.
If the password passes through a de-obfuscation function,
verify that the algorithm used to protect the password is sufficiently robust.
审计一个密码管理器事件，从密码进入系统的这一点，开始追踪程序。
寻找实现了模糊处理的代码。如果没有这样的代码存在，
那么这些事件就没有被减轻。
如果密码通过一个模糊函数处理，
验证表明，这个用来保护密码的规则不够强壮。
23.5.3.Once you are convinced that the password is adequately protected,
write a custom pass-through rule for the de-obfuscation routine
that indicates that the password is protected with obfuscation.
If you include this rule in future analyses of the application,
passwords that pass through the identified de-obfuscation routine
will no longer trigger password management vulnerabilities.
一旦你确信，密码被充分的保护好了，
为密码模糊写一个用户通过规则，表明密码被模糊规则保护。
在未来对应用程序的分析中，如果你包含这个规则，
通过模糊规则确定的密码将不会触发密码管理器漏洞。

               Fortify分析翻译7
                       http://user.qzone.qq.com/281696143/blog/1219735929  Ronger
19.Missing XML validation(Control Flow)：
19.1.源文件：QueryPrivilegeConfig.java.
代码：db = dbf.newDocumentBuilder();
19.2.原文：Failure to enable validation
when parsing XML gives an attacker the opportunity to supply malicious input..
翻译：因为没有去验证，所以当解析XML的时候会给攻击者一个输入恶意数据的机会。
19.3.EXPLANATION 解释
Most successful attacks begin with a violation of the programmer's assumptions.
By accepting an XML document without validating it against a DTD or XML schema,
the programmer leaves a door open for attackers to provide unexpected, unreasonable,
or malicious input.
It is not possible for an XML parser to validate all aspects of a document's content;
a parser cannot understand the complete semantics of the data.
However, a parser can do a complete and thorough job of checking the document's structure
and therefore guarantee to the code that processes the document that the content is well-formed.
大多数成功的攻击开始于程序假设的违背。
接受一个没有通过DTD或者是schema验证的XML文档，
程序员为攻击者打开了一扇门，攻击者可以提供不可预期的，不合理的，或者是恶意的输入。
对一个XML解析器来说不可能验证一个文档内容的所有预期；
解析器不能理解数据的全部语义。
但是，解析器可以为检查一个文档的结构，做一个完整的和彻底的工作，
并且保证有合法结构的文档中的代码。
In this case, validation is not enabled
on the XML parser or parser factory allocated
in common/bizservice/queryprivilege/impl/QueryPrivilegeConfig.java at line 86.
在这个例子中，验证在XML解析器或者解析工厂中是不允许的，
在QueryPrivilegeConfig.java的86行代码。
19.4.RECOMMENDATIONS 建议
Always enable validation when you create an XML parser or parser factory.
If enabling validation causes problems
because the rules for defining a well-formed document
are Byzantine or altogether unknown, chances are good
that there are security errors nearby.
当你创建一个XML解析器或者解析工厂的时候，应该允许验证。
如果有利的验证问题的原因，因为规则的定义以及形成的文件是完全未知的，
有可能有安全性错误在附近。
Below are examples that demonstrate
how to enable validation for the Xerces parsers (both DOM and SAX):
org.apache.xerces.framework.XMLParser: parser.setValidation(true);
org.apache.xerces.framework.XMLParser: parser.setValidationSchema(true);
下面是例子，示范对解析器来说如何去可以验证(DOM和SAX):
The following examples demonstrate how to enable validation for the SAX
and DOM parser factories in the javax library.
下面的例子示范，在javax库中，如何对SAX和DOM解析器工厂进行验证。
javax SAX parser factory:
javax.xml.parsers.SAXParserFactory: factory.setValidating(true);
javax.xml.parsers.SAXParserFactory: factory.setFeature("http://xml.org/sax/features/validation", true);
javax DOM parser factory:
javax.xml.parsers.DocumentBuilderFactory: factory.setValidating(true);
The following examples demonstrate
how to enable validation for individual parsers and XMLReaders in the javax library.
下面的例子示范，在javax库中，如何对个人解析器和XMLReaders进行验证。
Note: Fortify does not recommend enabling validation by this method.
Instead, you should enable validation at the parser factory.
注意：Fortify不推荐通过这个方法来进行验证。
可以这样，你可以在解析工厂中验证。
javax SAX parser and reader:
javax.xml.parsers.SAXParser: parser.setProperty("http://xml.org/sax/features/validation",
new Boolean(true));
org.xml.sax.XMLReader: reader.setFeature("http://xml.org/sax/features/validation", true);
19.5.TIPS 提示
Fortify checks to ensure that javax parser factories enable validation
before they are used to create parsers.
By ensuring that the parser factory always creates validating parsers,
there is less opportunity for error when creating and using a parser.
在他们被用作创建解析器之前，Fortify检查确认javax解析工厂允许验证。
通过确认解析工厂创建有验证功能的解析器，
当创建和使用解析器的时候，很少有机会会发生错误。
19.6.REFERENCES 引用
19.6.1.Xerces parser features, The Apache Foundation,
http://xml.apache.org/xerces2-j/features.html
19.6.2.XML Validation in J2SE 1.5, Sun Microsystems,
http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/validation/package-summary.html
20.Code Correctness():Erroneous class compare(Data Flow)：
20.1.源文件：BizHandledQueryDAO.java
代码：if(dataMap.get("comment_issuing_time").getClass().getName().
equals("oracle.sql.DATE"))
20.2.原文：Determining an object's type based on its class name
can lead to unexpected behavīor or allow an attacker to inject a malicious class..
翻译：根据类名来决定一个对象的类型将会引起不可预料的行为，例如攻击者注入一个恶意的类型。
理解：在此处是从项目的安全性考虑，攻击者可以在dataMap中注入类型为"oracle.sql.DATE"来让这段程序执行。
20.3.EXPLANATION 解释
Attackers may deliberately duplicate class names
in order to cause a program to execute malicious code.
For this reason, class names are not good type identifiers
and should not be used as the basis for granting trust to a given object.
攻击者可以有意的复制类名，为了使程序执行恶意的代码。
因为这个原因，类名不是好的身份标示，并且不能用作一个特定对象的信任依据。
Example 1: The following code opts to trust
or distrust input from an inputReader object based on its class name.
If an attacker is able to supply an implementation of inputReader
that executes malicious commands,
this code will be unable to differentiate the benign and malicious versions of the object.
例子1：下面的代码操作信任或者不信任从一个inputReader对象来的输入，
这个inputReader对象是基于它的类名的。
如果一个攻击这可以提供一个inputReader的实现，这个inputReader可以执行恶意的命令。
这个代码不能区分对象的良好的和恶意的版本。
if (inputReader.getClass().getName().equals("TrustedName"))
{
   input = inputReader.getInput();
   ...
}
20.4.RECOMMENDATIONS 建议
Always use a class-equivalence comparison to identify the type of an object.
Do not rely on class names to convey type information.
一直使用一个类比较器去确定对象的类型。不要依赖类名来传达类型信息。
Example 2: The following code has been rewritten
to use a class-equivalency comparison to determine whether inputReader object
has the expected type.
例子2：下面的代码使用类相等比较来进行重写，决定inputReader对象是否是期望的类型。
if (inputReader.getClass() == TrustedClass)
{
   input = inputReader.getInput();
   ...
}

               Fortify分析翻译6
          http://user.qzone.qq.com/281696143/blog/1219655341  Ronger
16. Code correctness:Erroneous String compare(Structural)：
16.1.源文件：BizApplicationApprovalBackingBean.java
代码:  if ((briefBizTaskVO.getDeptCode() != null) && (briefBizTaskVO.getDeptCode() != "")) {
16.2.原文：Strings should be compared with the equals() method, not == or !=.
翻译：字符串的比较要用equals方法，而不是==或者!=.
16.3.EXPLANATION 解释
This program uses == or != to compare two strings for equality,
which compares two objects for equality, not their values.
Chances are good that the two references will never be equal.
程序使用==或者！＝来比较两个字符串是否相等，
这个是比较两个对象是否相等，而不是他们的值。
这两个引用是不会相等的。
Example 1: The following branch will never be taken.
例子1：下面的分支将不会发生。
  if (args[0] == STRING_CONSTANT) {
      logger.info("miracle");
  }
The == and != operators will only behave as expected
when they are used to compare strings contained in objects that are equal.
The most common way for this to occur is for the strings to be interned,
whereby the strings are added to a pool of objects maintained by the String class.
Once a string is interned,
all uses of that string will use the same object
and equality operators will behave as expected.
All string literals and string-valued constants are interned automatically.
Other strings can be interned manually be calling String.intern(),
which will return a canonical instance of the current string, creating one if necessary.
这个==和!=操作符将有和期望一致的行为，
当他们被使用，就是比较包含在对象中的字符串。
对于这个出现最常见的方式是字符串被留住了，
为何字符串被加到对象池中。
一旦字符串被留住了，这个字符串的所用引用将使用相同的对象，
并且相等操作符将和预想的行为一致。
所有的字符串和字符串常量都被自动的留住。
其它的字符串可以通过调用String.intern()来手工留住，
将返回一个当前字符串的规范实例，如果需要就创建一个。
16.4.RECOMMENDATIONS 建议
Use equals() to compare strings.
Example 2: The code in Example 1 could be rewritten in the following way:
使用equals()比较字符串。
例子2：例子1中的代码可以以下面的方式改写：
  if (STRING_CONSTANT.equals(args[0])) {
      logger.info("could happen");
  }
16.5.TIPS 提示
16.5.1. Developers will sometimes compare strings for reference equality
in order to "avoid the inefficiency" of calling equals() right off the bat:
开发者有时候会通过通过引用来比较字符串，
为了"避免低效的"调用equals():
if (args[0] == STRING_CONSTANT) {
    doWork(args[0]);
} else if (STRING_CONSTANT.equals(args[0])) {
    doWork(args[0]);
}
16.5.2.In many circumstances this small performance gain comes at the cost of duplicated or convoluted code.
Because String.equals() performs a == comparison before doing any deeper evaluation,
the performance benefits of using == instead of String.equals()
are limited to the overhead of performing a method call
and are likely to be negligible in most environments.
Do a performance comparison for your program.
在许多情况下，这个小的性能增益是以成本重复或错综复杂的代码为代价的。
因为String.equals()在做一些深层次的计算之前执行了==比较，
使用==代替String.equals()的好处就是，
在执行一个方法调用的头上是受限制的，并且在大多数的环境下是不受重视的。
为你的程序做一个性能比较。
17.System Information Leak(Semantic)：
17.1.源文件：AgentServlet.java.
代码：catch (NamingException e) {
e.printStackTrace();
}
17.2.原文：Revealing system data or debugging information
helps an adversary learn about the system and form a plan of attack.
翻译：展现系统数据或调试信息将帮助攻击者了解系统和制定攻击的计划。
理解：在次还可以从另外一个角度考虑，就是异常被吃掉了。
17.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 web/common/monitor/AgentServlet.java at line 69.
在这里printStackTrace()在AgentServlet.java的69行被调用。
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注入攻击。
其它的错误信息将暴露更多的关于这个系统的间接信息。
在上面的例子中，搜索路径将暗示关于操作系统类型的信息，
应用程序安装在系统上的信息，和管理员已经设置进程序的一些重要的数量信息.
17.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.
甚至没有显示堆栈信息或者数据库的摘要错误信息会隐含的帮助攻击者。
例如，一个"存取拒绝"消息可以显示一个文件或者用户存在系统中。
17.5.TIPS 提示
17.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政策，
或者管理员的快速思考，来预防系统信息漏洞。
17.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.
这些弱点的归类不是应用在所有类型的程序上面。
例如，如果你的应用程序在一个客户端机器上面执行，
系统信息对攻击者来说总是有效的，
或者如果你仅仅将信息打印到可信任的日志文件上面，
你可以使用AuditGuide去过滤掉这些归类。
18. J2EE bad practices:Leftover threads(Semantic)：   
18.1.源文件：Metronome.java.
代码:  tempCon= new Container(tempClassName,tempTime);
18.2.原文：Thread management in a web application is forbidden in some circumstances and is always highly error prone..
翻译：在wen应用程序中线程管理器在一些情况下会被禁止，并且总是有很高的错误倾向。
18.3.EXPLANATION 解释
Thread management in a web application is forbidden by the J2EE standard in some circumstances and is always highly error prone.
Managing threads is difficult and is likely to interfere in unpredictable ways with the behavīor of the application container.
Even without interfering with the container, thread management usually leads to bugs that are hard to detect and diagnose like deadlock,
race conditions, and other synchronization errors.
在web应用程序中线程管理器在一些情况下会被禁止，并且总是有很高的错误倾向。管理线程是困难的，
并以不可预料的方式去妨碍应用程序容器的行为。即使没有妨碍容器，线程管理器通常也容易导致很难调试的bug
，死锁，程序紊乱，或者其它的线程错误。
18.4.RECOMMENDATIONS 建议
Avoid managing threads directly from within the web application.
Instead use standards such as message driven beans
and the EJB timer service that are provided by the application container.
避免直接使用web应用程序来管理线程。
使用标准的东西来代替，比如消息驱动bean和应用程序容器提供的EJB时间服务。
18.5.TIPS 提示
If you are auditing a non-J2EE Java application,
the J2EE Bad Practices categories may not apply to your environment.
If this is the case, you can use AuditGuide to suppress these issues.
如果你审核一个非J2EE的应用程序，
J2EE的坏习惯分类不可以应用到你的环境中。
如果这儿是这种情况，你可以使用AuditGuide跳过这些情况。
18.6.REFERENCES 引用
[1] Java 2 Platform Enterprise Edition Specification, v1.4,
Sun Microsystems, http://java.sun.com/j2ee/

                              Fortify分析翻译5
                       http://user.qzone.qq.com/281696143/blog/1219648603  Ronger
13. Poor error handling:Overly broad catch(Structural)：
13.1.AcceptApplicationBackingBean.java
catch(Exception e){
13.2.原文：The catch block handles a broad swath of exceptions,
potentially trapping dissimilar issues or problems
that should not be dealt with at this point in the program..
翻译：这个捕捉异常的块可以处理所有的异常，潜在的陷入了在这段程序中不能处理的不同问题。
理解：如果捕捉exception,就不能让处理异常的逻辑细化，
也就是所有的异常都按照同样的逻辑处理是不行的。
13.3.EXPLANATION 解释
Multiple catch blocks can get ugly and repetitive,
but "condensing" catch blocks by catching a high-level class like Exception can obscure exceptions
that deserve special treatment or that should not be caught at this point in the program.
Catching an overly broad exception essentially defeats the purpose of Java's typed exceptions,
and can become particularly dangerous
if the program grows and begins to throw new types of exceptions.
The new exception types will not receive any attention.
多重的异常捕捉块可能会变得丑陋和重复的，
但是通过一个高层异常(比如Exception)"浓缩"的捕捉块将模糊异常，
这个异常应该有不同的处理，并且在程序的这个点上不能捕捉到。
捕捉一个过分广泛的异常将从本质上违背了Java对异常分类的目的，
如果程序修改并且增加一个新类型的异常，会变得特别的危险。
新异常类型将不会接受异常处理。
Example: The following code excerpt handles three types of exceptions in an identical fashion.
例如：下面的代码摘录以同样的方式处理三种异常。
  try {
    doExchange();
  }
  catch (IOException e) {
    logger.error("doExchange failed", e);
  }
  catch (InvocationTargetException e) {
    logger.error("doExchange failed", e);
  }
  catch (SQLException e) {
    logger.error("doExchange failed", e);
  }
At first blush, it may seem preferable to deal with these exceptions in a single catch block,
as follows:
马上，它可以使用一个单独的捕捉异常块更好的处理这些异常，像下面：
  try {
    doExchange();
  }
  catch (Exception e) {
    logger.error("doExchange failed", e);
  }
However, if doExchange() is modified to throw a new type of exception
that should be handled in some different kind of way,
the broad catch block will prevent the compiler from pointing out the situation.
Further, the new catch block
will now also handle exceptions derived from RuntimeException such as ClassCastException,
and NullPointerException, which is not the programmer's intent.
但是，如果doExchange()被修改抛出一个新类型的异常，这个异常需要以一些不同的方式来处理，
宽泛的捕捉块将防止编译器指向这种情况。
更多的，新的捕捉块现在也可以处理起源于RuntimeException的异常，比如ClassCastException,
和NullPointException,这些都不是程序员的意图。   
13.4.RECOMMENDATIONS 建议
Do not catch broad exception classes like Exception, Throwable, Error,
or <RuntimeException> except at the very top level of the program or thread.
除非在程序或者线程的顶部，不要捕捉宽泛的异常类，类似于:Exception,Throwable,Error，
或者RuntimeException。
13.5.TIPS 提示
Fortify will not flag an overly broad catch block
if the catch block in question immediately throws a new exception.
Fortify不能标记一个过分宽泛的捕捉块，
如果这个捕捉块有问题，马上就会抛出一个新异常。
14. Poor logging practice:logger not declared static final(structual):
14.1.CreditRatingApprovalDisplayUCCImpl.java
private Logger logger = Logger.getLogger
(CustomerManagerTeamBSImpl.class);
原文：Declare loggers to be static and final..
翻译：定义日志工具必须是static和final的。
14.2.EXPLANATION 解释
It is good programming practice to share a single logger object
between all of the instances of a particular class
and to use the same logger for the duration of the program.
它是好的编程习惯，在所有特殊类的实例之间共享一个单独的日志对象，
并且在程序的持续时间中使用相同的日志组件。
Example 1: The following statement errantly declares a non-static logger.
例子1：下面的语句定义了一个non-static日志组件。
private final Logger logger =    
            Logger.getLogger(MyClass.class);
14.3.RECOMMENDATIONS 建议
Declare loggers to be static and final.
Example 2: The code in Example 1 could be rewritten in the following way:
定义日志组件为static和final类型。
例子2：在例子1中的代码可以以下面的方式改写：
private final static Logger logger =    
            Logger.getLogger(MyClass.class);
15. Code correctness:null argument to equals(Structual):
SystemCommonParameters.java
   if (obj==null||obj.equals(null)) {
15.1.原文：The expression obj.equals(null) will always be false.
翻译：表达式obj.equals(null)总是为false.
15.2.EXPLANATION 解释
The program uses the equals() method to compare an object with null.
This comparison will always return false, since the object is not null.
(If the object is null, the program will throw a NullPointerException).
程序使用equals()方法来比较对象和null.
这个比较将一直返回false,当然这是这个对象不是null的情况下.
(如果这个对象是null,程序将抛出NullPointException).
15.3.RECOMMENDATIONS 建议
It is possible that the programmer intended to check to see if the object was null.
可能是，程序员打算去检查,object对象是不是null.
Instead of writing 更换下面的写法
obj.equals(null)
they intended 他们打算
obj == null
15.4.REFERENCES 引用
[1] JavaDoc for Object, Sun Microsystems,
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#equals(java.lang.Object)
对象的Java文档地址

                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包装，
来将可检查异常转化为不可检查异常。
 

                 Fortify分析翻译3
                         http://user.qzone.qq.com/281696143/blog/1219389939  Ronger
7. Poor style:Confusing naming(Structural):
7.1.BPCodeConstants.java
    private static  final String RATING_BP_CODE = "WF001";
    public static String RATING_BP_CODE() {}
7.2.The class contains a field and a method with the same name.
该类包含相同名字的属性和方法。
7.3.EXPLANATION 解释
It is confusing to have a member field and a method with the same name.
It makes it easy for a programmer to accidentally call the method
when attempting to access the field or vice versa.
它是让人迷惑的，一个成员属性和一个方法有相同的名字。
当准备检查属性或者缺陷的时候，它可以使程序员调用方法更加容易。
Example 1:
public class Totaller {
  private int total;
  public int total() {
    ...
  }
}
7.4.RECOMMENDATIONS 建议
Rename either the method or the field. If the method returns the field,
consider following the standard getter/setter naming convention.
Example 2: The code in Example 1 could be rewritten in the following way:
不管是重命名方法还是属性，如果方法返回这个属性，
考虑采用标准的getter/setter命名惯例。
例子2：在例子1中的代码在下面将被覆盖：
public class Totaller {
  private int total;
  public int getTotal() {
    ...
  }
}
8. Dead code:unused field(Structural)：   
8.1.BaseWFBO.java  
    BaseWFBO.java   private Map historyInfo;   
8.2.This field is never used.   
    属性没有使用。   
8.3.EXPLANATION 解释
This field is never accessed, except perhaps by dead code.
It is likely that the field is simply vestigial,
but it is also possible that the unused field points out a bug.
这个属性没有入口，应该是一段死代码。
也有可能，这个属性是一个简单的属性，
但是也有可能，这个没有用到的属性是一个缺陷。
Example 1: The field named glue is not used in the following class.
The author of the class has accidentally put quotes around the field name,
transforming it into a string constant.
例子1：这个叫glue的属性在下面的类中没有用到。
类的作者，不小心使用一个引用来定义属性的名称，
应该将它转换成一个字符串常量。
public class Dead {
  String glue;
  public String getGlue() {
    return "glue";
  }
}
Example 2: The field named glue is used in the following class,
but only from a method that is never called.
例子2：在下面的类中，属性glue被使用了，
但是仅仅用来一个从不被调用的类中。
public class Dead {
  String glue;
  private String getGlue() {
    return glue;
  }
}
8.4.RECOMMENDATIONS 建议
In general, you should repair or remove dead code.
It causes additional complexity and maintenance burden
without contributing to the functionality of the program.
通常，你应该修改或者去掉死代码。
它会使程序增加额外的复杂度，
而且在对程序的功能没有任何贡献的情况下增加负担。
9. Dead code:unused method(Structural)：   
9.1.BaseBackingBean.java  
    private static ValueBinding getValueBinding(String el)
9.2.This method is not reachable from any method outside the class.   
    这个方法不能被类外面的方法调用。
9.3.EXPLANATION 解释
This method is never called or is only called from other dead code.
这个方法是不能被调用的，或者只能从其它的死代码中调用。
Example 1: In the following class, the method doWork() can never be called.
例子1：在下面的类中，方法doWork()不能被调用。
public class Dead {
  private void doWork() {
    System.out.println("doing work");
  }
  public static void main(String[] args) {
    System.out.println("running Dead");
  }
}
Example 2: In the following class, two private methods call each other,
but since neither one is ever invoked from anywhere else, they are both dead code.
例子2：在下面的类中，两个私有方法相互调用，
但是没有一个可以从其它的地方来调用，它们都是死代码。
public class DoubleDead {
  private void doTweedledee() {
    doTweedledumb();
  }
  private void doTweedledumb() {
    doTweedledee();
  }
  public static void main(String[] args) {
    System.out.println("running DoubleDead");
  }
}
(In this case it is a good thing that the methods are dead:
invoking either one would cause an infinite loop.)
(在这个例子中，方法是死的：调用任何一个都将导致死循环。)
9.4.RECOMMENDATIONS 建议
A dead method may indicate a bug in dispatch code.
一个死方法暴露一个分支代码中的缺陷。
Example 3: If method is flagged as dead named getWitch() in a class
that also contains the following dispatch method,
it may be because of a copy-and-paste error.
The 'w' case should return getWitch() not getMummy().
例子3：如果一个标记为死代码的方法getWitch()，并且getWitch()
包含下面的调度方法。它可能是因为一个复制粘贴错误。
这个'w'的情况会返回getWitch()而不是getMummy().
public ScaryThing getScaryThing(char st) {
  switch(st) {
    case 'm':
      return getMummy();
    case 'w':
      return getMummy();
    default:
      return getBlob();
  }
}
In general, you should repair or remove dead code.
It causes additional complexity and maintenance burden
without contributing to the functionality of the program.
通常，你应该修改或者去掉死代码。
它会使程序增加额外的复杂度，
而且在对程序的功能没有任何贡献的情况下增加负担。
9.5.TIPS 提示
   This issue may be a false positive if the program uses reflection to access private methods.
(This is a non-standard practice.
Private methods that are only invoked via reflection should be well documented.)
这个问题应该不是值得肯定的，如果程序使用反射来访问私有方法。
(这是一个非标准的习惯。使用反射调用的私有方法可以被很好的记录下来。)

             Fortify分析翻译2
 
                       http://user.qzone.qq.com/281696143/blog  Ronger
4. Poor error handling:Empty ctach block(structual)：
4.1.BizElementMapping.java
    } catch (BizException e) {}
4.2.Ignoring an exception can cause the program
to overlook unexpected states and conditions.
忽视一个异常将会出现不能预料的状态和情况。
4.3.EXPLANATION 解释
Just about every serious attack on a software system
begins with the violation of a programmer's assumptions.
After the attack, the programmer's assumptions seem flimsy and poorly founded,
but before an attack many programmers would defend their assumptions
well past the end of their lunch break.
在一个软件系统中，每一次严重的攻击开始于程序假设的违背。
在攻击之后，程序的假设看起来很浅薄和脆弱，但是在攻击之前，
很多的程序员会为他们的假设辩护。
Two dubious assumptions that are easy to spot in code are
"this method call can never fail" and "it doesn't matter if this call fails".
When a programmer ignores an exception,
they implicitly state that they are operating under one of these assumptions.
在代码中两个容易发现的假设是"函数调用从不会失败"和"如果函数调用失败，它不是个问题"。
当一个程序员忽视一个异常，他们含蓄的声明了，他们操作了下面这些假设中的一个。
Example 1: The following code excerpt ignores a rarely-thrown exception from doExchange().
例子1：下面的代码摘录忽略了一个doExchange()中的很少抛出的异常。
try {
  doExchange();
}
catch (RareException e) {
  // this can never happen 这些不能发生
}
If a RareException were to ever be thrown,
the program would continue to execute as though nothing unusual had occurred.
The program records no evidence indicating the special situation,
potentially frustrating any later attempt to explain the program's behavīor.
如果一个RareException被抛出的时候，
程序将继续执行就像没有任何特别的事情发生过一样。
程序没有记录表明特殊状况发生的证据，隐含的阻止了后面尝试解释程序的行为。
4.4.RECOMMENDATIONS 建议
At a minimum,
log the fact that the exception was thrown
so that it will be possible to come back later
and make sense of the resulting program behavīor.
Better yet, abort the current operation.
If the exception is being ignored
because the caller cannot properly handle it
but the context makes it inconvenient or impossible for the caller to declare
that it throws the exception itself,
consider throwing a RuntimeException or an Error,
both of which are unchecked exceptions. As of JDK 1.4,
RuntimeException has a constructor that makes it easy to wrap another exception.
最低要求，记录异常被抛出的事实，这样它就有可能在后面回来，并且可以记录程序行为。
更好的，中断当前的操作。
如果异常被忽略，因为调用者不能处理它，
但是环境让调用者不方便或者说不可能处理，它抛出的自身的异常。
考虑抛出一个RuntimeException或者一个Error,这两个都是不可检查异常。
在JDK1.4中，RuntimeException有一个构造器，使它可以很容易包装其它的异常。
Example 2: The code in Example 1 could be rewritten in the following way:
例子2：在例子1中的代码在下面的情况下不能被重写：
try {
  doExchange();
}
catch (RareException e) {
  throw RuntimeException("This can never happen", e);
}
4.5.提示
   There are rare types of exceptions that can be discarded in some contexts.
For instance, Thread.sleep() throws InterruptedException,
and in many situations the program should behave the same way
whether or not it was awoken prematurely.
在一些环境中，有很小类型的可以定义的异常。
举例说明，Thread.sleep()抛出InterruptedException,
并且在许多的情况下，程序可以以同样的方式运转，不管它是否被过早的唤醒。
  try {
    Thread.sleep(1000);
  }
  catch (InterruptedException e){
    // The thread has been woken up prematurely, but its
    // behavīor should be the same either way.
    //线程被过早的唤醒，但是它的行为在两种情况下是一样的。
  }
5. Poor logging practice:Use of a system output stream(structural):
5.1.BizElementMapping.java
    System.out.println("----"+s[i]);
5.2.Using System.out or System.err rather than a dedicated logging facility
makes it difficult to monitor the behavīor of the program...
System.out或者System.err和一个专门的日志组件相比，更难监控
程序的行为。
就是要统一使用日志组件。
5.3.EXPLANATION 解释
Example 1: The first Java program that a developer learns to write often looks like this:
最初的Java程序，一个开发者在学习的时候的程序，常常就像这样：
public class MyClass
  public static void main(String[] args) {
    System.out.println("hello world");
  }
}
While most programmers go on to learn many nuances and subtleties about Java,
a surprising number hang on to this first lesson
and never give up on writing messages to standard output using System.out.println().
当大多数的程序员学习Java的细微差别和比较精细的地方的时候，
第一堂课就是学会使用System.out.println()来将信息写到标准输出中去。
The problem is that writing directly to standard output or standard error
is often used as an unstructured form of logging.
问题是，直接的写到标准输出通常用在非结构的日志模式中。
Structured logging facilities provide features like logging levels,
uniform formatting, a logger identifier, timestamps, and, perhaps most critically,
the ability to direct the log messages to the right place.
When the use of system output streams is jumbled together with the code
that uses loggers properly,
the result is often a well-kept log that is missing critical information.
结构化的日志组件提供特性像：日志级别，统一的格式，日志标示，时间戳，并且，也许最多的批评，
将日志信息输出到正确的位置的能力。
系统输出流的使用会搞乱使用日志属性的代码，
结果就是常常保存的很好的日志，总是少了很多临界的信息。
Developers widely accept the need for structured logging,
but many continue to use system output streams in their "pre-production" development.
If the code you are reviewing is past the initial phases of development,
use of System.out or System.err
may indicate an oversight in the move to a structured logging system.
开发者普遍的接受结构日志的概念，但是还有许多在他们的"半成品"开发阶段继续使用系统输出流。
如果你看到的代码是在最初的开发状态之后，使用System.out或者System.err可以表明
在向结构组件系统转换过程中的疏忽。
5.4.RECOMMENDATIONS 建议
Use a Java logging facility rather than System.out or System.err.
宁可使用一个Java日志组件，也不要使用System.out或者System.err。
Example 2: For example, the "hello world" program above can be re-written using log4j like this:
例子2：例如：上面的"hello world"程序可以像这样的使用log4j来重写：
import org.apache.log4j.Logger;
import org.apache.log4j.BasicConfigurator;
public class MyClass {
  private final static Logger logger =    
            Logger.getLogger(MyClass.class);
  public static void main(String[] args) {
    BasicConfigurator.configure();
    logger.info("hello world");
  }
}
6．Poor style:Value never read(Structural):
6.1.AddCLProdMaintainUCCImpl.java
  if(prodList!=null){    int i = prodList.size();  }
6.2.The variable's value is assigned but never used, making it a dead store.
变量被定义了，但是没有使用。
6.3.EXPLANATION 解释
This variable's value is not used. After the assignment,
the variable is either assigned another value or goes out of scope.
这个变量的值没有使用。在定义之后，
变量使用了定义的其它的值或者马上出了它的作用域。
Example: The following code excerpt assigns to the variable r
and then overwrites the value without using it.
例如：下面的代码摘录定义了变量r，并且没有使用它就马上重写了它的值。
  r = getName();
  r = getNewBuffer(buf);
6.4.RECOMMENDATIONS 建议
Remove unnecessary assignments in order to make the code easier to understand and maintain.
为了是代码更加容易理解，并且要能够继续执行，移掉不需要的定义。

                    Fortify分析翻译1

                               http://user.qzone.qq.com/281696143/blog  Ronger
1.Missing check against null(Control Flow)：
1.1.源文件：AgentServlet.java.
    代码：obj = this.getClass().getClassLoader().loadClass(servletName).newInstance();
1.2.The program may dereference a null pointer
because it does not check the return value of a function that can return null..
因为没有检查有可能返回null的函数的返回值，程序会间接引用一个空指针。
1.3.EXPLANATION 解释
Just about every serious attack on a software system
begins with the violation of a programmer's assumptions.
After the attack, the programmer's assumptions seem flimsy and poorly founded,
but before an attack many programmers would defend their assumptions well
past the end of their lunch break.
在一个软件系统中，每一次严重的攻击开始于程序假设的违背。
在攻击之后，程序的假设看起来很浅薄和脆弱，但是在攻击之前，
很多的程序员会为他们的假设辩护。
Two dubious assumptions that are easy to spot in code
are "this function call can never fail" and "it doesn't matter if this function call fails".
When a programmer ignores the return value from a function,
they implicitly state that they are operating under one of these assumptions.
在代码中两个容易发现的假设是"函数调用从不会失败"和"如果函数调用失败，它不是个问题"。
当一个程序员忽视从一个函数来的返回值，他们含蓄的声明了，他们操作了下面这些假设中的一个。
In this case, an earlier return value is used
without being checked in web/common/monitor/AgentServlet.java at line 147.
在这种情况中，没有在web/common/monitor/AgentServlet.java的147行检查，一个最早的返回值被使用。
Example 1:  The following code does not check to see
if the string returned by getParameter() is null，
before calling the member function compareTo(),
potentially causing a null dereference.
例子1：在下面的代码中，没有检查我们将看到，
如果通过getParameter()返回的字符串是null,
在调用成员函数compareTo()之前，隐含的产生一个空引用。
String itemName = request.getParameter(ITEM_NAME);
if (itemName.compareTo(IMPORTANT_ITEM)) {
  ...
}
...
Example 2:. The following code shows a system property
that is set to null and later dereferenced by a programmer
who mistakenly assumes it will always be defined.
例子2：下面的代码表明一个被赋值为空的系统属性，并且稍后被一个
程序员重新引用它，这个程序员错误的假设它总是被定义的。
System.clearProperty("os.name");
...
String ōs = System.getProperty("os.name");
if (os.equalsIgnoreCase("Windows 95") )
System.out.println("Not supported");
The traditional defense of this coding error is:
"I know the requested value will always exist because....
If it does not exist,
the program cannot perform the desired behavīor
so it doesn't matter
whether I handle the error or simply allow the program to die dereferencing a null value."
这个代码错误的传统防御是：
"我知道这个请求值总是存在因为...
如果它不存在，程序不能执行想要的行为，所以不管是我处理这个错误，
还是允许程序重新引用一个空值而无法执行下去，都不是问题。"
But attackers are skilled at finding unexpected paths through programs,
particularly when exceptions are involved.
但是攻击者在发现程序中的没有想到的路径方面是很熟练的，
特别是当程序陷于异常中的时候。
1.4.RECOMMENDATIONS 建议
If a function can return an error code or any other evidence of its success or failure,
always check for the error condition, even if there is no obvious way for it to occur.
In addition to preventing security errors,
many initially mysterious bugs have eventually led back to a failed method call
with an unchecked return value.
如果一个函数返回一个错误的代码或者有一些成功或者失败的迹象，
通常应该检查错误条件，直到对它来说没有任何模糊的路径出现。
Create an easy to use and standard way for dealing with failure in your application.
If error handling is straightforward, programmers will be less inclined to omit it.
One approach to standardized error handling is to write wrappers around commonly-used functions
that check and handle error conditions without additional programmer intervention.
When wrappers are implemented and adopted,
the use of non-wrapped equivalents can be prohibited and enforced by using custom rules.
在你的应用程序中，创建一个可以简单使用并且标准的方法去处理失败的情况。
如果错误处理很直接，程序员将会很少遗漏它。
对于标准错误的处理是围绕常用的函数(这些函数是为了检查和处理错误条件)写一些包装，
而不是传统的让程序员自己写检查函数。
当包装被实现和被采用了，同等的没有包装的使用将被禁止，并且强迫使用用户规则。
Example 3: The following code implements a wrapper around getParameter()
that checks the return value of getParameter() against null
and uses a default value if the requested parameter is not defined.  
例子3：下面的例子围绕getParameter()实现了一个包装,
检查getParameter()的返回值不是null的情况，
并且如果请求参数没有定义返回一个默认值。
String safeGetParameter (HttpRequest request, String name)
{
String value = request.getParameter(name);
if (value == null) {
return getDefaultValue(name)
}
return value;
}
1.5.TIPS 提示
1.5.1. Watch out for programmers who want to explain away this type of issue
by saying "that can never happen because ...".  
Chances are good that they have developed their intuition
about the way the system works by using their development workstation.
看看程序员，他们都会这样解释这种情况,"那种情况不会发生因为...".
运气很好，他们逐渐显示出关于系统工作在工作站上的路径的直觉。
1.5.2.If your software will eventually run under different operating systems,
operating system versions, hardware configurations,
or runtime environments, their intuition may not apply.
如果你的软件最后运行在不同的操作系统，操作系统版本，硬件环境，
或者是运行环境下面。他们的直觉将不再适用。

2.Null dereference (Control Flow):
2.1：ApplicationCheckupBackingBean.java.
   ：configDataMap = checkupTaskVO.getConfigItems();
2.2：The program can potentially dereference a null pointer,
thereby raising a NullPointerException..
程序有可能间接引用一个空指针,由此产生了一个空指针异常。
在此处指的是，变量checkupTaskVO有可能为空。
2.3.EXPLANATION 解释
Null pointer errors are usually the result of one or more programmer assumptions being violated.
空指针错误通常是一个或多个程序员假设出错的结果。
In this case the variable can be null when it is dereferenced at line 333,
thereby raising a NullPointerException.
在这个例子中，变量会产生null,当他在333行被重新引用的时候，由此产生了一个空指针异常。
Most null pointer issues result in general software reliability problems,
but if an attacker can intentionally trigger a null pointer dereference,
the attacker might be able to use the resulting exception to bypass security logic
or to cause the application to reveal debugging information
that will be valuable in planning subsequent attacks.
大多数的空指针异常造成常用软件的可靠性方面的问题，
但是如果一个攻击者有意的引发一个空指针，
攻击者可以使用异常结果绕过安全逻辑，或者使应用程序显示调试信息。
Example: In the following code,
the programmer assumes that the system always has a property named "cmd" defined.
If an attacker can control the program's environment so that "cmd" is not defined,
the program throws a null pointer exception when it attempts to call the trim() method.
例如：在下面的代码中，程序员假设，系统总是有一个定义为"cmd"的属性。
如果攻击者可以控制程序的环境，于是"cmd"变成未定义，当程序尝试去调用trim()方法的时候，
程序会抛出一个空指针异常。
String val = null;
...
cmd = System.getProperty("cmd");
if (cmd)
val = util.translateCommand(cmd);
...
cmd = val.trim();
2.4.RECOMMENDATIONS 建议
Security problems caused by dereferencing null pointers
are almost always related to the way
in which the program handles runtime exceptions.
If the software has a solid and well-executed approach to dealing with runtime exceptions,
the potential for security damage is significantly diminished.
被空指针的重新引用引起的安全问题，
通常和程序处理运行时异常联系在一起。
如果软件是一个立体，并且有可执行的途径来处理运行时异常，
隐藏的对安全的伤害会明显的减少。
3. Poor error handling:Program catchs nullpointexception(Structual)：
3.1：RequestMap。java
     }catch(NullPointerException e){}
3.2.It is generally a bad practice to catch NullPointerException.
   不能捕捉空指针异常。
3.3.EXPLANATION 解释
Programmers typically catch NullPointerException under three circumstances:
程序员在下面的三种情况下捕捉空指针异常。
3.3.1. The program contains a null pointer dereference.
Catching the resulting exception was easier than fixing the underlying problem.
程序包含一个空指针引用。捕捉结果异常比整理下面的程序更容易。
3.3.2. The program explicitly throws a NullPointerException to signal an error condition.
程序明确的抛出一个空指针异常，来标示一个错误的条件。
3.3.3. The code is part of a test harness that supplies unexpected input to the classes under test.
代码是测试的一部分，在测试的情况下提供意料不到的输入到类中。
Of these three circumstances, only the last is acceptable.
在这三种情况中，仅仅最后这种是可接受的。
Example: The following code mistakenly catches a NullPointerException.
例如：下面的代码错误的捕捉一个空指针异常。
  try {
    mysteryMethod();
  }
  catch (NullPointerException npe) {
  }
3.4.RECOMMENDATIONS 建议
The program should not dereference null pointers.
If you cannot eliminate the cause of the null pointer dereference,
you must carefully review the code to make sure
that the exception is handled in such a way
that the program does not enter into an unexpected or illegal state.
程序不能重新引用空指针。
如果你不能消除空指针重引用的原因，你必须小心的检查代码以确信，
异常在程序没有输入非法数据时会被处理。
If the NullPointerException is being thrown explicitly,
change the program to throw an exception derived from RuntimeException or Error instead.
如果空指针异常被明确的抛出了，
改变程序，抛出一个继承RuntimeException或者Error的异常。