OWASP WebGoat---安全测试学习笔记（一）

编者按：

        作为一名黑盒测试人员，我是今年初开始接触安全性测试这个方向的。但是在学习安全性测试时，感觉知识点很碎，或者说缺少纲领性的东西，很难下手或迈出第一步。后来找到了OWASP top 10，

进而开始接触OWASP项目。写WebGoat系列文章的目的，将以WebGoat项目为示例，在完成训练课程的同时，较为全面的掌握Web应用的漏洞利用、原理分析、测试方法、代码级防范，算是自己的目标吧。

当然从时间上考量的话，应该不会很快完成。需要耐心，这是一个漫长的过程。从深度上看，文章应该是先完成、实现，然后深入、完善，也是一个漫长的过程。

一、OWASP(Open Web Application Security Project) 简介

        OWASP是一个开源的、非盈利的全球性安全组织，致力于应用软件的安全研究。文章中有关于安全测试的学习都将从OWASP项目开始。

           OWASP Top 10 为大家提供了学习安全测试的提纲。

        网址：https://www.owasp.org       

                  http://www.owasp.org.cn

二、WebGoat 项目简介

        WebGoat是OWASP组织研制出的用于进行web漏洞实验的应用平台，用来说明web应用中存在的安全漏洞。WebGoat运行在带有JVM的平台上，

当前提供的训练课程有30多个，其中包括：跨站点脚本攻击（XSS）、访问控制、线程安全、操作隐藏字段、操纵参数、弱会话cookie、SQL盲注、

数字型SQL注入、字符串型SQL注入、web服务、Open Authentication失效、危险的HTML注释等等。WebGoat提供了一系列web安全学习的教程，

某些课程也给出了视频演示，指导用户利用这些漏洞进行攻击。

        本文也将以 WebGoat 为提纲来完成安全测试的学习。

        网址（项目介绍）：https://www.owasp.org/index.php/Webgoat

        相关资源： WebGoat-user-beta手册.pdf

                           WebGoatv2.2技术文档.pdf

                           OWASP_Testing_Guide_v3.pdf

三、WebGoat 的安装

        WebGoat是一个javaweb项目，war包部署到Tomcat即可。至于jre、tomcat的安装这里不写，训练课程里面涉及到的工具在用到时再描述。

        项目主页（相关内容下载）：

        http://code.google.com/p/webgoat   (WebGoat5.4)

        http://sourceforge.net/projects/owasp/files/WebGoat/   (WebGoat5.2 )

        http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project

        

        安装方式1：下载 WebGoat-5.4-OWASP_Standard_Win32.zip 文件，解压缩。打开 README.txt 文件，按说明完成安装。

        安装方式2：下载 WebGoat-5.4.war 文件，部署到 tomcat/webapps/下。按照 README.txt 文件提示，修改配置文件完成安装。

        README.txt里面也提供了WebGoat启动及访问的网址，登录使用guest 。具体如下图：

        

        在 "Start WebGoat" 之前，复制粘贴一段话，我觉得挺有意义。这段话来自于 WebGoat userGuide。如下：

       如果你没有完整的手册，你也可以自己去收集一些帮助信息，这都能帮助你完成课程。不要太急于求成，应用测试靠的是 10%的技术和

90%的横向思维。如果你通过自己的努力去战胜课程设置的难题，你会学习并且掌握到更多的东西。当然，这一切要经过大量的尝试，

一次次的失败，终于一个闪念把你引向成功。这个过程中，你可以去责怪 Goat，但是你不能去依赖他人。

四、先修课之Http基础知识

       HTTP(Hypertext transfer protocol)-->超文本传输协议，是一种详细规定了浏览器和万维网服务器(www)之间互相通信的规则，通过因特网传送万维网文档

的数据传送协议。运行于OSI模型的应用层，由请求和响应两部分构成。HTTP协议是无状态的协议。无状态指HTTP协议对于事务处理没有记忆力。缺少事务

状态意味着若后续处理需要前面的信息，则必须重传，可能导致每次连接传送的数据量增大。基于事务处理的需要，出现了cookie和session技术。

(一)  请求和响应：

         基于HTTP协议的客户端/服务器模式的信息交换过程：

         1. 建立连接：连接的建立是通过申请套接字实现的。客户打开一个套接字，并把它约束在一个端口上，

                             若成功，就相当于建立一个虚拟文件。以后就可以通过向该虚拟文件上写数据并通过网络向外传送；

         2. 发送请求：打开一个连接后，客户机把请求消息送到服务器的停留端口上，完成提出请求的动作；

         3. 发送响应：服务器在处理完客户请求之后，要向客户机发送响应消息；

         4. 关闭连接：通过关闭套接字来结束会话。HTTP协议属于应用层协议，其连接、关闭、信息交换在传输层是由TCP协议保证的。

                             而传输层的信息交换是由下层网络层的IP协议来保证。

          HTTP请求由三部分组成：请求的方法、请求头、请求正文。

          HTTP响应包含：协议状态代码描述、响应头、响应正文。

          HTTP响应状态码分析：

                                  1XX：信息响应类。表示接收到请求并继续处理。

                                  2XX：处理成功响应类。

                                  3XX：重定向响应类。

                                  4XX：客户端错误。

                                  5XX：服务器端错误。

(二)  状态保持-->cookie&session技术：

         1.HTTP协议需要保持状态的必要性：想想淘宝的购物车....（ 此处略去一万字，非本文重点）

         2.实现HTTP状态保持的方案：

            a.修改HTTP协议，使其支持状态保持；（不现实）

            b.使用cookie技术，由客户端来保持状态信息；（可行）

            c.使用session技术，由服务器端来保持状态信息；（可行）

          3.cookie技术：

             概念：cookie是服务器发送给客户端的特殊信息，用来记录客户端状态。cookie以文本方式保存在客户端，每次请求时需要。

             特点：cookie在客户端，只能保存字符串，不能保存其它对象类型。且需要客户端浏览器支持。      

             采用cookie技术需要解决的问题：

                    cookie创建：cookie cookie = new cookie("guest","1"); 

                    cookie类：javax.servlet.http.cookie;

                    构造：public cookie (string name,string value);

                    设置cookie的过期时间：cookie.setMaxAge(int lifetime);

                    cookie的修改和删除：cookie不提供修改和删除操作。若要修改某个cookie，只要新建一个同名的cookie，并添加到response中覆盖原来

                                                    的cookie；若要删除某个cookie，只要新建一个同名cookie，并将maxAge设置为0，并添加到 response中覆盖原来

                                                    的cookie即可。

           4.session技术：

               概念：客户端浏览器访问服务器时，服务器把客户信息以某种形式记录到服务器上就是Session。当客户端浏览器再次访问时

                         只需要从该session中根据是否包含SessionID来查找该客户的状态。

               特点：session在用户第一次访问服务器时自动创建。若只访问HTML、IMAGE等静态资源时，不会创建Session。

                         每次客户端发送请求，服务器端都会检查是否含有sessionID。状态信息保存在服务器端，安全性高。可支持任何类型的对象。

                实现：1.在客户端与服务器端传递JSessionID，使用客户端cookie来保存SessionID。

                          2.若客户端禁用cookie。使用URL重写，直接在URL后附加上Session id 信息。

                采用Session技术需要解决的问题：

                        获取 Session：request.getSession();

                        保存信息到Session：Session.SetAttribute(String name,Object  oo);             

                        设置Session有效时间：public void setMaxInactiveInterval(int interval)

                        在web.xml中设置会话超时，单位是分钟：

                          

                                 10

                       

                 Session的创建和删除：

                        httpSession.invalidate()       // 手工销毁Session

                        Request.getSession(true)     // 强制生成Session   

                        HttpSession.getId()              // 获取SessionID

 

(三)  HTTPS原理：

        HTTPS是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即在HTTP下加入SSL层，HTTPS的安全基础是SSL。因此加密的详细内容就需要SSL。

HTTPS使用SSL加密传输协议，使用端口443。采用https的服务器必须从CA （Certificate Authority）申请一个用于证明服务器用途类型的证书。该证书只有

用于对应的服务器的时候，客户端才信任此主机。访问合法的HTTPS网站，在URL地址栏会有一个绿色的标识。提示使用的是HTTPS。

五、HTTP 拆分攻击（HTTP Splitting）

1. 原理分析：

        HTTP 拆分攻击又名CRLF注入攻击。即是发送一个或几个HTTP指令迫使漏洞服务器产生一个攻击者构想好的输出。可以让服务器误把几条HTTP请求

当作一次完整的HTTP请求来解释。攻击者完全控制第二条HTTP请求，在第二条请求中加入请求指令到目标系统。第一部分使服务器接受两个HTTP响应，

第二部分即是在服务器上请求一些非法资源，而服务器将会自动匹配到第二次响应，输出攻击者想要请求的资源，从而达到攻击者的目的。

        攻击者在向Web服务器正常输入的请求中加入恶意代码，若受到攻击的web服务器不检查CR（回车，也可表示为%0d或\r）和LF（换行，也可表示为%0a

或\n）。这些字符不仅使攻击者控制应用程序打算发送的响应头和响应体，而且还使他们能够完全在其控制下创造更多的响应。在这些响应中包含了一些指令，

完成攻击者的目的。

        HTTP拆分攻击配合缓存污染一起使用，能使效果达到最大化。缓存污染攻击的目标是使缓存污染，欺骗缓存，使其相信使用HTTP拆分劫持的页面是一个

正常页面，一个服务器副本。攻击发生时，使用HTTP拆分攻击，加上最后修改添加的部分：

        请求头，并设置它为将来的日期。这将迫使浏览器发送If - Modified - Since请求头，这使攻击者有机会拦截服务器的响应，并代之以 “304不修改” 应答。

以下是一个简单的304响应： 

HTTP/1.1 304 Not Modified  
Date: Fri, 30 Dec 2005 17:32:47 GMT

2.漏洞利用：

        正常情况下服务器的响应信息：

HTTP/1.1 302 Moved Temporarily  
Server: Apache-Coyote/1.1  
Location: http://localhost/WebGoat/attack?Screen=3&menu=100&fromRedirect=yes&language=test  
Content-Type: text/html;charset=ISO-8859-1  
Content-length: 0  
Date: Fri, 03 Aug 2012 06:52:48 GMT  

        预期得到的响应信息：

HTTP/1.1 302 Moved Temporarily  
Server: Apache-Coyote/1.1  
Location: http://localhost/WebGoat/attack?Screen=3&menu=100&fromRedirect=yes&language=test  

Content-length: 0  
HTTP/1.1 200 OK  
Content-Type: text/html;  
Content-length: 19  
  
hack 

 
Content-Type: text/html;charset=ISO-8859-1  
Content-length: 0  
Date: Fri, 03 Aug 2012 06:52:48 GMT 

        我们构造的响应，是包含在向服务器发送的请求中的。通过HTTP拆分，服务器将包含攻击者构造的响应的请求 看作是一次完整的请求。

        HTTP响应数据包中“Content‐Length: 0”告诉浏览器第一个响应已经结束。其中第一个响应是302 重定向的响应，第二个响应是我们自己构造的响应。

当客户端收到第一个响应之后会向相应头的Location指向的目标地址发起第二个请求，而这个时候客户端会认为第二个响应正是针对第二个请求的响应，

从而达到了欺骗的目的。当我们在第二个响应中向服务器请求了非法资源，而服务器只能执行，毫无抵抗能力。以此实现了攻击者的目的。

        WebGoat课程中需要将攻击者自己构造的响应用URLencode转换后提交来完成课程。课程要求如下：

        You will notice that the application is redirecting your request to another resource on the server. You should be able to use the CR (%0d) 

and LF (%0a) characters to exploit the attack. Your goal should be to force the server to send a 200 OK. If the screen changed as an effect to

your attack, just go back to the homepage.

         课程第二部分要求完成一次污染缓存的攻击。缓存污染要求篡改HTTP头中的Last‐Modified字段，将该字段修改为当前时间之后的时间。让服务器

误以为缓存中的该页面没有及时更新。

         其实防范CRLF注入的方法也就是将CR、LF过滤或转义。 像是XSS防范中对"<" 、">" 的处理。

3.测试&防范：

        现在的主流Web服务器比如IIS，Apache 以及Tomcat等都有对这个问题作过改进，服务器会对即将发送出去的HTTP响应头里面每一项的值做一定的

编码或者转换，以避免这个问题。比如Tomcat就是将响应头中的每一项的值都做过了URLEncode，从而保证即使Web应用存在HTTP拆分的漏洞，Web服务器

也可从底层平台的角度保证尽可能的避免HTTP拆分漏洞带来的威胁。

        防范：如何修复HRS漏洞，当然是过滤\r 、\n之类的换行符，避免输入的数据污染到其他HTTP头。

        2014年11月12日。终于在WooYun知识库找到了一篇关于CRLF利用＆实战的文章《CRLF Injection漏洞的利用与实例分析》。

虎躯为之一震！说明学这个也是一个循序渐进的过程，呵呵。 文章地址：http://drops.wooyun.org/papers/2466

注：

        本文参考：《WEB安全测试》、《WebGoat v2.2技术文档》、《OWASP Testing Guide v3》.

        在用WebScarab 时设置好了代理，但是没有截获浏览器发送的请求。原因是WebScarab默认使用8008端口，若该端口以被占用，

        则WebScarab无法正常看到浏览器发送的请求，需要修改默认的端口。