Fortify分析翻譯9

 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