用户列举测试法

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

　　通常，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是现实存在的。