在上面的例子中，如果我们用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" |
● 用户列举测试法
这种测试，简而言之是通过与应用的认证机制的交互，尝试能否获得一些正确的用户名，这对后面我们会讲到的暴力破解很有效，确认了正确的用户名就能用暴力破解去尝试密码了。
通常，WEB应用对于用户名正确的输入会有一些信息反馈，例如，如果我们输错了密码，那么有时会反馈告知我们系统存在该用户，或密码错误。所以，作为测试人员，就要尝试不同的请求来判断系统是否会有不同的返回。
对于HTTP的响应消息测试：
◇ 输入正确的用户名和密码
期望结果：使用WebScrab抓取服务器的返回信息（HTTP 200 Response,消息的长度）
◇ 输入正确的用户名/错误的密码
期望结果：从浏览器我们往往会得到如下的返回
或者是如下返回
甚至是如下的返回
Login for User foo: invalid password
◇ 输入不存在的用户名
期望结果：返回可能如下
或者是如下的消息
Login failed for User foo: invalid Account
通常情况下，对于不同的出错信息，服务器往往返回的消息是一样的，但如果不同，测试人员就要去尝试在什么情况下不同，如下：
客户请求：正确用户/错误密码——>服务器返回：密码错误
客户请求：错误用户/错误密码——>服务器返回：用户不存在。
那么显然第一条就告诉我们我们输入的是正确的用户名，通过这种方式我们就可以获得一些正确的用户名信息。
