首先,这跟跨站是两回事。
HTTP Request Smuggling --- HRS
其原理是
client ----------> proxy server -----------> real web server
在这里,client提交HTTP包的时候,如果构造两个 Content-Length
而这两个Content-Length的值是冲突的,比如一个是0,一个是100
而proxy server 和 后面的 real web server 却解析了不同的 Content-Length
那么会造成什么呢?我们就有机会重定向client访问的页面!
ex:
POST http://SITE/foobar.html HTTP/1.1
Host: SITE
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
Content-Length: 44
[CRLF]
GET /poison.html HTTP/1.1
Host: SITE
Bla: [space after the "Bla:", but no CRLF]
GET http://SITE/page_to_poison.html HTTP/1.1
Host: SITE
Connection: Keep-Alive
[CRLF]
比如proxy读到了第2个content-length,丢弃了第一个,那么就正好读到bla后面
接下来的
GET http://SITE/page_to_poison.html HTTP/1.1
Host: SITE
Connection: Keep-Alive
[CRLF]
会被proxy当作是来自client的第二个包
而对于 real web server,如果他只读到了第一个 Content-Length,丢弃了第二个 Content-Length
那么,就会认为
GET /poison.html HTTP/1.1
Host: SITE
Bla: [space after the "Bla:", but no CRLF]
是client发来的第二个包,而
"GET http://SITE/page_to_poison.html HTTP/1.1 " 则会做为Bla的值,而被忽略掉
就是因为这个差异!!
因为两个server对Content-Length 的不同选择造成了HRS!
会发生什么呢?
假设proxy里是cache了poison.html的,在这里,就会把 page_to_poison.html 指向 posion.html的内容
这里是proxy来完成这个动作了
所以当client 通过proxy访问 page_to_poison.html 的时候,得到的却是posion的内容!
我们只发送了两次包,就控制了proxy的cache!
然而可惜的是,这里还有HOST字段,使得劫持与被劫持的页面只能位于同一IP上
具体proxy和webserver选择哪个Content-Length字段,要看具体的 Web Server了
CVE-2005-2088 描述了这一漏洞
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2088
要真正说利用,有几种方式:
1。突破虚拟主机
2。结合跨站,可以跨该机器上的任意一个页面
3。突破WEB防火墙和IPS
所以,HRS的本质和XSS是不一样的。