Fortify分析翻译9

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