前端學HTTP之基本認證

前面的話

　　人們用Web進行私人事務處理，訪問私有的數據。經過Web能夠很方便地訪問這些信息，但僅僅是方便訪問仍是不夠的。咱們要保證只有特定的人能看到咱們的敏感信息而且可以執行咱們的特權事務

　　服務器須要經過某種方式來了解用戶身份。一旦服務器知道了用戶身份，就能夠斷定用戶能夠訪問的事務和資源了。認證就意味着要證實你是誰。一般是經過提供用戶名和密碼來進行認證的。HTTP爲認證提供了一種原生工具。儘管咱們能夠在HTTP的認證形式和cookie基礎之上「運行本身的」認證工具，但在不少狀況下，HTTP的原生認證功能就能夠很好地知足要求。本文將詳細介紹HTTP中的基本認證

 

認證

　　認證就是要給出一些身份證實。當出示像護照或駕照那樣有照片的身份證件時，就給出了一些證據，說明你就是你所聲稱的那我的。在自動取款機上輸入PIN碼，或在計算機系統的對話框中輸入密碼時，也是在證實你就是你所聲稱的那我的

　　如今，這些策略都不是絕對有效的。密碼能夠被猜出來或被人偶然聽到，身份證件可能被偷去或被僞造，但每種證據都有助於構建合理的信任，說明你就是你所聲稱的那我的

【HTTP的質詢/響應認證框架】

　　HTTP提供了一個原生的質詢/響應(challenge/response)框架，簡化了對用戶的認證過程。HTTP的認證模型以下圖所示

　　Web應用程序收到一條HTTP請求報文時，服務器沒有按照請求執行動做，而是以一個「認證質詢」進行響應，要求用戶提供一些保密信息來講明他是誰，從而對其進行質詢

　　用戶再次發起請求時，要附上保密證書(用戶名和密碼)。若是證書不匹配，服務器能夠再次質詢客戶端，或產生一條錯誤信息。若是證書匹配，就能夠正常完成請求了

【認證協議與首部】

　　HTTP經過一組可定製的控制首部，爲不一樣的認證協議提供了一個可擴展框架。下表列出的首部格式和內容會隨認證協議的不一樣而發生變化。認證協議也是在HTTP認證首部中指定的

　　HTTP定義了兩個官方的認證協議：基本認證和摘要認證。從此人們能夠隨意設計一些使用HTTP質詢/響應框架的新協議

　　關於基本認證的實例，以下圖所示

　　服務器對用戶進行質詢時，會返回一條401 Unauthorized響應，並在WWW-Authenticate首部說明如何以及在哪裏進行認證

　　當客戶端受權服務器繼續處理時，會從新發送請求，但會在Authorization首部附上加密的密碼和其餘一些認證參數

　　受權請求成功完成時，服務器會返回一個正常的狀態碼(好比，200 OK)，對髙級認證算法來講，可能還會在Authentication-Info首部附加一些額外的信息

【安全域】

　　在對基本認證的細節進行討論以前，須要解釋一下HTTP是怎樣容許服務器爲不一樣的資源使用不一樣的訪問權限的。上圖(b)的WWW-Authenticate質詢中包含了一個realm指令。Web服務器會將受保護的文檔組織成一個安全域(security realm)。每一個安全域均可以有不一樣的受權用戶集

　　好比，假設Web服務器創建了兩個安全域：一個用於公司的財務信息，另外一個用於我的家庭文檔。不一樣的用戶對各個安全域的訪問權限是不一樣的。公司的CEO應該可以訪問銷售額預測資料，但不該該容許他訪問員工和其家人度假的照片

　　下面是一個假想的基本認證質詢，它指定了一個域:

HTTP/1.0 401 Unauthorized
WWW-Authenticate： Basic realm="Corporate Financials"

　　域應該有一個描述性的字符名，好比Corporate Financials(公司財務資料)，以幫助用戶瞭解應該使用哪一個用戶名和密碼。在安全域的名稱中列出服務器主機名也是頗有幫助的——好比，executive-committee@bigcompany.com

 

基本認證

　　基本認證是最流行的HTTP認證協議。幾乎每一個主要的客戶端和服務器都實現了基本認證機制。基本認證最初是在HTTP/1.0規範中提出的，但此後被移到了RFC 2617中，它詳細介紹了HTTP的認證機制

　　在基本認證中，Web服務器能夠拒絕一個事務，質詢客戶端，請用戶提供有效的用戶名和密碼。服務器會返回401狀態碼，而不是200狀態碼來初始化認證質詢，並用WWW-Authenticate響應首部指定要訪問的安全域。瀏覽器收到質詢時，會打開一個對話框，請求用戶輸入這個域的用戶名和密碼。而後將用戶名和密碼稍加擾碼，再用Authorization請求首部回送給服務器

【基本認證明例】

　　下圖是一個詳細的基本認證明例

　　在圖a中，用戶請求了私人家庭相片/family/jeff.jpg

　　在圖b中，服務器回送一條401 Authorization Required，對私人家庭相片進行密碼質詢，同時回送的還有WWW-Authenticate首部。這個首部請求對Family域進行基本認證

　　在圖c中，瀏覽器收到了401質詢，彈出對話框，詢問Family域的用戶名和密碼。用戶輸入用戶名和密碼時，瀏覽器會用一個冒號將其鏈接起來，編碼成「通過擾碼的」Base-64表示形式，而後將其放在Authorization首部中回送

　　在圖d中，服務器對用戶名和密碼進行解碼，驗證其正確性，而後用一條HTTP 200 0K報文返回所請求的報文

　　下表總結了HTTP基本認證的WWW-Authenticate和Authorization首部

　　[注意]基本認證協議並無使用Authentication-Info首部

【Base-64用戶名/密碼編碼】

　　HTTP基本認證將(由冒號分隔的)用戶名和密碼打包在一塊兒，並用Base-64編碼方式對其進行編碼。簡單來講，Base-64編碼會將一個8位字節序列劃分爲一些6位的塊。用每一個6位的塊在一個特殊的由64個字符組成的字母表中選擇一個字符，這個字母表中包含了大部分字母和數字

　　下圖顯示了使用Base-64編碼的基本認證明例。在這個例子中，用戶名爲brian-totty，密碼爲Ow!。瀏覽器用冒號將用戶名和密碼鏈接起來，生成一個打包字符串brian-totty:Ow!。而後對這個字符串進行Base-64編碼，變成一串亂碼：YnJpYW4tdG90dHk6T3ch

　　Base-64編碼能夠接受二進制字符串、文本、國際字符表示的數據(在某些系統中 會引起一些問題)，將其暫時轉換成一個易移植的字母表以便傳輸。而後，在遠端就能夠解碼出原始字符串，而無需報心傳輸錯誤了

　　有些用戶名和密碼中會包含國際字符或其餘在HTTP首部中非法的字符(好比引號、冒號和回車換行符)，對這些用戶名和密碼來講，Base-64編碼是很是有用的。並且，Base-64編碼擾亂了用戶名和密碼，這樣也能夠防止管理員在管理服務器和網絡時，不當心看到用戶名和密碼

【代理認證】

　　中間的代理服務器也能夠實現認證功能。有些組織會在用戶訪問服務器、LAN或無線網絡以前，用代理服務器對其進行認證。能夠在代理服務器上對訪問策略進行集中管理。所以，經過代理服務器提供對某組織內部資源的統一訪問控制是一種很便捷的方式。這個過程的第一步就是經過代理認證(proxy authentication)來識別身份

　　代理認證的步驟與Web服務器身份驗證的步驟相同。但首部和狀態碼都有所不一樣。 下表列出了Web服務器和代理在認證中使用的狀態碼和首部的差別

 

安全缺陷

　　基本認證簡單便捷，但並不安全。只能用它來防止非惡意用戶無心間進行的訪問，或將其與SSL這樣的加密技術配合使用

　　基本認證會經過網絡發送用戶名和密碼，這些用戶名和密碼都是以一種很容易解碼的形式表示的。實際上，密碼是以明文形式傳輸的，任何人均可以讀取並將其捕獲。雖然Base-64編碼經過隱藏用戶名和密碼，導致友好的用戶不太可能在進行網絡觀測時無心中看到密碼，但Base-64編碼的用戶名和密碼能夠很輕易地經過反向編碼過程進行解碼，甚至能夠用紙筆在幾秒鐘內手工對其進行解碼，因此通過Base-64編碼的密碼實際上就是「明文」傳送的。若是有動機的第三方用戶有可能會去攔截基本認證發送的用戶名和密碼，就要經過SSL加密信道發送全部的HTTP事務，或者使用更安全的認證協議，好比摘要認證

　　即便密碼是以更難解碼的方式加密的，第三方用戶仍然能夠捕獲被修改過的用戶名和密碼，並將修改過的用戶名和密碼一次一次地重放給原始服務器，以得到對服務器的訪問權。沒有什麼措施可用來防止這些重放攻擊

　　即便將基本認證用於一些不過重要的應用程序，好比公司內部網絡的訪問控制或個性化內容的訪問，一些不良習慣也會讓它變得很危險。不少用戶因爲受不了大量密碼保護的服務，會在這些服務間使用相同的用戶名和密碼。好比說，黑客會從免費的因特網郵件網站捕獲明文形式的用戶名和密碼，而後會發現用一樣的用戶名和密碼還能夠訪問重要的在線銀行網站

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

　　假冒服務器很容易騙過基本認證。若是在用戶實際鏈接到一臺惡意服務器或網關的時候，可以讓用戶相信他鏈接的是一個受基本認證保護的合法主機，攻擊者就能夠請求用戶輸入密碼，將其存儲起來以備將來使用，而後捏造一條錯誤信息傳送給用戶

　　這一切說明，在友好的環境，或者說是但願有隱私保護但隱私保護並不十分必要的環境中，能夠經過基本認證來提供便捷的文檔個性化服務或訪問控制保護。經過這種方式，能夠用基本認證來防止一些好奇的用戶無心中或不當心對文檔進行訪問

　　好比，在一個公司內部，產品管理可能要對將來的產品計劃進行密碼保護，以防止信息的過早發佈。對通常用戶而言，基本認證就足以讓他們感到不便而不會再去訪問這些數據了。一樣，可能會用密碼來保護那些並不是高度機密的，或者沒什麼信息價值的私人照片或私有站點，這些信息確實和其餘人也沒什麼關係

　　將基本認證與加密數據傳輸(好比SSL)配合使用，向惡意用戶隱藏用戶名和密碼，會使基本認證變得更加安全。這是一種經常使用的技巧