WebGoat HTTP Splitting攻击实验研究澄清笔记

由于自己在学习HTTP Splitting期间遇到的一些困惑，经过仔细研究得出结论发出来一遍能够帮助和我走在同一条“路上”的人。

WebGoat HTTP Splitting 实验攻击过程是 4步

1、攻击者也就是客户端注入恶意代码（如下）-----》发送到服务器

foobar%0aContent-Length:%200%0a%0aHTTP/1.1%20200%20OK%0aContent-Type:%20text/html%0aContent-Length:%2049%0a%0atwang

2、服务器返回302重定向报文--------》客户端

3、客户端想302中返回的location发送请求--------》服务器

4、服务器发送回应给客户端----》客户端

而注入的恶意代码真正攻击效果即输出下图应该是在4步，但是实际恶意代码是在第3步的服务器端生效还是在第4步的客户端生效，换句话说，是因为服务器受到恶意代码影响返回了以下代码给客户端

HTTP/1.1 200 OK

Content-Type: text/html

Content-Length:17

twang

还是由于服务器返回了 除了http/1.1 200 ok以上代码还返回了一个content-length：0的响应包，客户端只识别了第二个响应了呢，为了求证这个我模拟攻击的过程中在服务器抓包，最终抓到如下的包

到此心中就坚定了自己的想法，其实Splitting不是由于客户端只是别第二个reponse中的http/1.1 200 OK，而是因为服务器被恶意代码欺骗，以至于当服务器收到包含恶意代码的请求即location中的URL及URL参数时引起的，导致服务器只返回指定HTTP/1.1 200及定制body页面给客户端。

其它文章中写道的由于客户端认为接收到两个HTTP response完全是错误的理解。

错误理解想法如下：

其实WebGoat HTTP Splitting在很多的文章中都写到是：

通过注入HTTP request使得Server返回两个HTTP response（最起码是使得接收到Server返回响应的目标自己认为是接收到了两个HTTP response），而不是一个。通过精心构造这第二个HTTP响应，攻击者可以达到任意目的！该攻击是因为server没有检查非法的数据输入就进行了请求的重定向（code 3x x , "setcookie" 或者 "Location"）。

以上错误理解的举例只是希望后来者或者将要学习webgoat的同仁们不要被误导，同时也作为本人的个人笔记，并无恶意。