轉自：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是現實存在的。