如何进行验证测试（上）

转自：http://www.51testing.com/html/94/n-202194.html

 

所谓认证，就是建立确信某物或某人是真实的这么一个过程，authentication来自于希腊语 ，即真实的，可信的。认证本身依赖于多个认证因子，在计算机安全领域，认证意味着验证通讯发起者的数字身份，常见的认证过程就是用户登录认证，所谓认证测试就是理解系统中的认证机制并找到方法绕过该认证机制。

　　认证测试需要考虑的点有很多，下面我们逐一来进行解释说明：

　　● 在加密通道上传递密码

　　原则上，用户的认证必须通过加密信道进行传输，我们在这里的目的不是要验证诸如HTTPS是否安全，我们要验证的仅仅是用户的认证信息是否已经被加密了。

　 　在用户登录时，最常见的方式是用户输入用户名和密码后，通过POST方法传输，一般来说，认证信息或者是通过不安全的HTTP传递，或者是通过加密的 HTTPS传递。我们注意到，甚至有些网站在登录页面显示给我们的是HTTPS，但事实上却仍然是用HTTP的，最简单的方法就是用网络监听工具，如 SnifferPro或Ethereal来判断是否是真实加密了。

　　下面，我们用OWASP的WebScrab截取一些信息来做个例子

　　假设，登录页面要求用户输入用户名和密码，然后有一个“提交”按钮，那么在WebScrab中我们得到如下的请求数据：

POSThttp://www.example.com/AuthenticationServlet HTTP/1.1 Host:www.example.com User-Agent: Mozilla/5.0 (Windows ; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404 Accept: text/xml,application/xml,application/xhtml+xml Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer:http://www.example.com/index.jsp Cookie: JSESSIONID=LVrRRQQXgwyWpW7QMnS49vtW1yBdqn98CGlkP4jTvVCGdyPkmn3S! Content-Type: application/x-www-form-urlencoded Content-length: 64   delegated_service=218&User=test&Pass=test&Submit=SUBMIT

　　在上面的数据中，我们可以看到，POST方法通过HTTP协议把数据发送到http://www.example.com/AuthenticationServlet ，那么显然在这时，传送的数据没有进行加密，恶意用户通过监听网络就很容易得到用户名和密码。

 

再看下一个例子，假设是用HTTPS协议，那么请求的头数据如下：

POST https://www.example.com:443/cgi-bin/login.cgi HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404 Accept: text/xml,application/xml,application/xhtml+xml,text/html Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: https://www.example.com/cgi-bin/login.cgi Cookie: language=English; Content-Type: application/x-www-form-urlencoded Content-length: 50   Command=Login&User=test&Pass=test

　　可见，上述例子中的数据经加密后被传送到https://www.example.com:443/cgi-bin/login.cgi ，这就确保了数据是加密的而不被其他人所窃取。

　　再看下面的一个例子，我们在一个可以通过HTTP协议访问到的页面上通过HTTPS协议来发送数据：

POST https://www.example.com:443/login.do HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404 Accept: text/xml,application/xml,application/xhtml+xml,text/html Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://www.example.com/homepage.do Cookie: SERVTIMSESSIONID=s2JyLkvDJ9ZhX3yr5BJ3DFLkdphH0QNSJ3VQB6pLhjkW6F Content-Type: application/x-www-form-urlencoded Content-length: 45   User=test&Pass=test&portal=ExamplePortal

　　如上，我们看到，我们的请求通过HTTPS引向了https://www.example.com:443/login.do ，但如果我们再看Referer的值，就发现我们是从HTTP页http://www.example.com/homepage.do 过来的。在这种情况下，我们的浏览器窗口中并不会告诉我们现在使用的安全连接，而事实上我们却正在使用安全连接。

 

在上面的例子中，如果我们用Get方法，那么所输入的用户名和密码将会以明文的方式显示在URL中，这显然是不可取的。那么，如果我们经由Get方法通过HTTPS来传递数据是否可行呢，看下面的数据：

GET https://www.example.com/success.html?user=test&pass=test HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404 Accept: text/xml,application/xml,application/xhtml+xml,text/html Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: https://www.example.com/form.html If-Modified-Since: Mon, 30 Jun 2008 07:55:11 GMT If-None-Match: "43a01-5b-4868915f"

　 　从上面的例子可以看到，用户名和密码都以明文的方式在URL里存在，而不像上面的几个例子中都在消息体中，但并不是说攻击者就可以很容易看到这些信 息，TLS/SSL毕竟是安全性很高的协议，整个HTTP数据包是加密的，但仍然要注意的是这些用户名和密码在传输过程中会被存储在代理和服务器上，这也 就有可能会泄露用户信息。

　　● 用户列举测试法

　　这种测试，简而言之是通过与应用的认证机制的交互，尝试能否获得一些正确的用户名，这对后面我们会讲到的暴力破解很有效，确认了正确的用户名就能用暴力破解去尝试密码了。

　　通常，WEB应用对于用户名正确的输入会有一些信息反馈，例如，如果我们输错了密码，那么有时会反馈告知我们系统存在该用户，或密码错误。所以，作为测试人员，就要尝试不同的请求来判断系统是否会有不同的返回。

　　对于HTTP的响应消息测试：

　　◇ 输入正确的用户名和密码

　　期望结果：使用WebScrab抓取服务器的返回信息（HTTP 200 Response,消息的长度）

　　◇ 输入正确的用户名/错误的密码

　　期望结果：从浏览器我们往往会得到如下的返回

　　或者是如下返回

　　甚至是如下的返回

　　Login for User foo: invalid password

　　◇ 输入不存在的用户名

　　期望结果：返回可能如下

　　或者是如下的消息

　　Login failed for User foo: invalid Account

　　通常情况下，对于不同的出错信息，服务器往往返回的消息是一样的，但如果不同，测试人员就要去尝试在什么情况下不同，如下：

　　客户请求：正确用户/错误密码——>服务器返回：密码错误

　　客户请求：错误用户/错误密码——>服务器返回：用户不存在。

　　那么显然第一条就告诉我们我们输入的是正确的用户名，通过这种方式我们就可以获得一些正确的用户名信息。

 

还有其他一些尝试列举的方法：

　　◇ 有些应用程序会返回一些特定的出错信息；

　　◇ 分析URL以及重定向URL

　　如下面的URL：

　　http://www.foo.com/err.jsp?User=baduser&Error=0

　　http://www.foo.com/err.jsp?User=gooduser&Error=2

　　上面两个URL都告诉我们到了错误页面，但上一条是Error值为0，下一条Error值为2，那么我们可以猜测我们获得了一个正确的用户名。

　　◇ URI探测

　　有时候，Web服务器在接受一个对目录访问请求时，根据目录是否存在会有不同的返回信息，例如在某些网站会给每个用户设定一个目录，那么我们如果尝试访问某个已存在的目录时，它可能的返回页面如下：

　　403 Forbidden error code

　　404 Not found error code

　　举例：

　　http://www.foo.com/account1 -返回的出错信息: 403 Forbidden

　　http://www.foo.com/account2 -返回的出错信息: 404 file Not Found

　　那么显然，account1是现实存在的。