介面測試六（基本認證）__介面測試

轉自：http://www.360doc.com/content/16/0128/15/30056680_531241482.shtml

HTTP協議是無狀態的，就像兩個盲人一樣，彼此不能識別對方。 同一個用戶端的這次請求和上次請求是沒有對應關係，對http伺服器來說，它並不知道這兩個請求來自同一個用戶端

伺服器需要通過某種方式瞭解訪問使用者的身份。一旦伺服器知道了使用者身份，就可以判斷使用者可以訪問的事務和資源了。認證意味著要證明用戶端訪問使用者是誰。通常情況是通過提供使用者名稱和密碼來認證的 一、什麼是HTTP基本認證。

用戶端通過HTTP協議跟Web伺服器互動， 用戶端一般不會使用cookie, 而是把 '使用者名稱+冒號+密碼'用BASE64編碼的字串放在http request 中的header Authorization中發送給服務端， 這種方式叫HTTP基本認證(Basic Authentication)

當瀏覽器訪問使用基本認證的網站（如我們要下載論壇裡面的某個附件http://120.25.145.237/upload/forum.php?mod=viewthread&tid=15）的時候， 瀏覽器會提示你登陸（輸入使用者名稱和密碼），如下圖

當瀏覽器訪問使用基本認證的網站的時候， 瀏覽器會提示你輸入使用者名稱和密碼，如下圖
假如使用者名稱密碼錯誤的話， 伺服器會返回401 如下圖

二，認證原理：
三、HTTP基本認證的過程

第一步: 用戶端發送http request 給伺服器，

第二步: 因為request中沒有包含Authorization header, 伺服器會返回一個401 Unauthozied 給用戶端，並且在Response 的 header 'WWW-Authenticate' 中添加資訊。

第三步：用戶端把使用者名稱和密碼用BASE64編碼後，放在Authorization header中發送給伺服器， 認證成功。

第四步：伺服器將Authorization header中的使用者名稱密碼取出，進行驗證， 如果驗證通過，將根據請求，發送資源給用戶端
使用Fiddler Inspectors 下的Auth 選項卡，可以很方便的看到使用者名稱和密碼:


四、HTTP基本認證和HTTPS

把 '使用者名稱+冒號+密碼' 用BASE64編碼後的string雖然用肉眼看不出來， 但用程式很容易解密，上圖可以看到Fiddler就直接給解密了。 所以這樣的http request 在網路上，如果用HTTP傳輸是很不安全的。 一般都是會用HTTPS傳輸, HTTPS是加密的, 所以比較安全.

五、HTTP OAuth認證

OAuth 對於Http來說，就是放在Authorization header中的不是使用者名稱密碼， 而是一個token.

微軟的Skydrive 就是使用這樣的方式， 如下圖
六、其他認證

除了基本認證(Basic Authentication), 還有摘要認證 digest authentication, WSSE(WS-Security)認證

七、基本認證的安全缺陷

基本認證通過網路發送使用者名稱和密碼，雖然進行base-64編碼可以隱藏使用者名稱和密碼，但是很容易通過反向編碼過程進行解碼。

即使密碼以更加難以解碼的方式加密，第三方使用者仍然可以捕獲被修改過的使用者名稱和密碼，並通過重放攻擊擷取伺服器的存取權限。

很多使用者會將不同的服務使用相同的使用者名稱和密碼，基本認證直接發送使用者名稱和密碼，會對一些重要的服務(比如線上銀行網站)造成威脅。

基本認證沒有提供任何針對代理和中間人節點的防護措施，他們沒有修改認證首部，但卻修改了報文的其餘部分，這樣就嚴重的改變了事務的本質。

假冒伺服器很容易騙過基本認證。如果在使用者實際連結到一台惡意伺服器或者網關的時候，能夠讓使用者相信他連結的是一個受基本認證保護的合法主機，攻擊者就可以請求使用者輸入密碼。

IIS中網站預設開啟匿名驗證，並可以直接存取