HTTP之基本認(rèn)證

認(rèn)證

　　認(rèn)證就是要給出一些×××明。當(dāng)出示像護(hù)照或駕照那樣有照片的×××件時(shí)，就給出了一些證據(jù)，說明你就是你所聲稱的那個(gè)人。在自動(dòng)取款機(jī)上輸入PIN碼，或在計(jì)算機(jī)系統(tǒng)的對話框中輸入密碼時(shí)，也是在證明你就是你所聲稱的那個(gè)人

　　現(xiàn)在，這些策略都不是絕對有效的。密碼可以被猜出來或被人偶然聽到，×××件可能被偷去或被偽造，但每種證據(jù)都有助于構(gòu)建合理的信任，說明你就是你所聲稱的那個(gè)人

【HTTP的質(zhì)詢/響應(yīng)認(rèn)證框架】

　　HTTP提供了一個(gè)原生的質(zhì)詢/響應(yīng)(challenge/response)框架，簡化了對用戶的認(rèn)證過程。HTTP的認(rèn)證模型如下圖所示

　　Web應(yīng)用程序收到一條HTTP請求報(bào)文時(shí)，服務(wù)器沒有按照請求執(zhí)行動(dòng)作，而是以一個(gè)“認(rèn)證質(zhì)詢”進(jìn)行響應(yīng)，要求用戶提供一些保密信息來說明他是誰，從而對其進(jìn)行質(zhì)詢

　　用戶再次發(fā)起請求時(shí)，要附上保密證書(用戶名和密碼)。如果證書不匹配，服務(wù)器可以再次質(zhì)詢客戶端，或產(chǎn)生一條錯(cuò)誤信息。如果證書匹配，就可以正常完成請求了

【認(rèn)證協(xié)議與首部】

　　HTTP通過一組可定制的控制首部，為不同的認(rèn)證協(xié)議提供了一個(gè)可擴(kuò)展框架。下表列出的首部格式和內(nèi)容會(huì)隨認(rèn)證協(xié)議的不同而發(fā)生變化。認(rèn)證協(xié)議也是在HTTP認(rèn)證首部中指定的

　　HTTP定義了兩個(gè)官方的認(rèn)證協(xié)議：基本認(rèn)證和摘要認(rèn)證。今后人們可以隨意設(shè)計(jì)一些使用HTTP質(zhì)詢/響應(yīng)框架的新協(xié)議

　　關(guān)于基本認(rèn)證的實(shí)例，如下圖所示

　　服務(wù)器對用戶進(jìn)行質(zhì)詢時(shí)，會(huì)返回一條401 Unauthorized響應(yīng)，并在WWW-Authenticate首部說明如何以及在哪里進(jìn)行認(rèn)證

　　當(dāng)客戶端授權(quán)服務(wù)器繼續(xù)處理時(shí)，會(huì)重新發(fā)送請求，但會(huì)在Authorization首部附上加密的密碼和其他一些認(rèn)證參數(shù)

　　授權(quán)請求成功完成時(shí)，服務(wù)器會(huì)返回一個(gè)正常的狀態(tài)碼(比如，200 OK)，對髙級認(rèn)證算法來說，可能還會(huì)在Authentication-Info首部附加一些額外的信息

【安全域】

　　在對基本認(rèn)證的細(xì)節(jié)進(jìn)行討論之前，需要解釋一下HTTP是怎樣允許服務(wù)器為不同的資源使用不同的訪問權(quán)限的。上圖(b)的WWW-Authenticate質(zhì)詢中包含了一個(gè)realm指令。Web服務(wù)器會(huì)將受保護(hù)的文檔組織成一個(gè)安全域(security realm)。每個(gè)安全域都可以有不同的授權(quán)用戶集

　　比如，假設(shè)Web服務(wù)器建立了兩個(gè)安全域：一個(gè)用于公司的財(cái)務(wù)信息，另一個(gè)用于個(gè)人家庭文檔。不同的用戶對各個(gè)安全域的訪問權(quán)限是不同的。公司的CEO應(yīng)該能夠訪問銷售額預(yù)測資料，但不應(yīng)該允許他訪問員工和其家人度假的照片

　　下面是一個(gè)假想的基本認(rèn)證質(zhì)詢，它指定了一個(gè)域:

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

　　域應(yīng)該有一個(gè)描述性的字符名，比如Corporate Financials(公司財(cái)務(wù)資料)，以幫助用戶了解應(yīng)該使用哪個(gè)用戶名和密碼。在安全域的名稱中列出服務(wù)器主機(jī)名也是很有幫助的——比如，executive-committee@bigcompany.com

基本認(rèn)證

　　基本認(rèn)證是最流行的HTTP認(rèn)證協(xié)議。幾乎每個(gè)主要的客戶端和服務(wù)器都實(shí)現(xiàn)了基本認(rèn)證機(jī)制?；菊J(rèn)證最初是在HTTP/1.0規(guī)范中提出的，但此后被移到了RFC 2617中，它詳細(xì)介紹了HTTP的認(rèn)證機(jī)制

　　在基本認(rèn)證中，Web服務(wù)器可以拒絕一個(gè)事務(wù)，質(zhì)詢客戶端，請用戶提供有效的用戶名和密碼。服務(wù)器會(huì)返回401狀態(tài)碼，而不是200狀態(tài)碼來初始化認(rèn)證質(zhì)詢，并用WWW-Authenticate響應(yīng)首部指定要訪問的安全域。瀏覽器收到質(zhì)詢時(shí)，會(huì)打開一個(gè)對話框，請求用戶輸入這個(gè)域的用戶名和密碼。然后將用戶名和密碼稍加擾碼，再用Authorization請求首部回送給服務(wù)器

【基本認(rèn)證實(shí)例】

　　下圖是一個(gè)詳細(xì)的基本認(rèn)證實(shí)例

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

　　在圖b中，服務(wù)器回送一條401 Authorization Required，對私人家庭相片進(jìn)行密碼質(zhì)詢，同時(shí)回送的還有WWW-Authenticate首部。這個(gè)首部請求對Family域進(jìn)行基本認(rèn)證

　　在圖c中，瀏覽器收到了401質(zhì)詢，彈出對話框，詢問Family域的用戶名和密碼。用戶輸入用戶名和密碼時(shí)，瀏覽器會(huì)用一個(gè)冒號將其連接起來，編碼成“經(jīng)過擾碼的”Base-64表示形式，然后將其放在Authorization首部中回送

　　在圖d中，服務(wù)器對用戶名和密碼進(jìn)行解碼，驗(yàn)證其正確性，然后用一條HTTP 200 0K報(bào)文返回所請求的報(bào)文

　　下表總結(jié)了HTTP基本認(rèn)證的WWW-Authenticate和Authorization首部

　　[注意]基本認(rèn)證協(xié)議并沒有使用Authentication-Info首部

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

　　HTTP基本認(rèn)證將(由冒號分隔的)用戶名和密碼打包在一起，并用Base-64編碼方式對其進(jìn)行編碼。簡單來說，Base-64編碼會(huì)將一個(gè)8位字節(jié)序列劃分為一些6位的塊。用每個(gè)6位的塊在一個(gè)特殊的由64個(gè)字符組成的字母表中選擇一個(gè)字符，這個(gè)字母表中包含了大部分字母和數(shù)字

　　下圖顯示了使用Base-64編碼的基本認(rèn)證實(shí)例。在這個(gè)例子中，用戶名為brian-totty，密碼為Ow!。瀏覽器用冒號將用戶名和密碼連接起來，生成一個(gè)打包字符串brian-totty:Ow!。然后對這個(gè)字符串進(jìn)行Base-64編碼，變成一串亂碼：YnJpYW4tdG90dHk6T3ch

　　Base-64編碼可以接受二進(jìn)制字符串、文本、國際字符表示的數(shù)據(jù)(在某些系統(tǒng)中 會(huì)引發(fā)一些問題)，將其暫時(shí)轉(zhuǎn)換成一個(gè)易移植的字母表以便傳輸。然后，在遠(yuǎn)端就可以解碼出原始字符串，而無需報(bào)心傳輸錯(cuò)誤了

　　有些用戶名和密碼中會(huì)包含國際字符或其他在HTTP首部中非法的字符(比如引號、冒號和回車換行符)，對這些用戶名和密碼來說，Base-64編碼是非常有用的。而且，Base-64編碼擾亂了用戶名和密碼，這樣也可以防止管理員在管理服務(wù)器和網(wǎng)絡(luò)時(shí)，不小心看到用戶名和密碼

【代理認(rèn)證】

　　中間的代理服務(wù)器也可以實(shí)現(xiàn)認(rèn)證功能。有些組織會(huì)在用戶訪問服務(wù)器、LAN或無線網(wǎng)絡(luò)之前，用代理服務(wù)器對其進(jìn)行認(rèn)證?？梢栽诖矸?wù)器上對訪問策略進(jìn)行集中管理。因此，通過代理服務(wù)器提供對某組織內(nèi)部資源的統(tǒng)一訪問控制是一種很便捷的方式。這個(gè)過程的第一步就是通過代理認(rèn)證(proxy authentication)來識別身份

　　代理認(rèn)證的步驟與Web服務(wù)器身份驗(yàn)證的步驟相同。但首部和狀態(tài)碼都有所不同。 下表列出了Web服務(wù)器和代理在認(rèn)證中使用的狀態(tài)碼和首部的差異

安全缺陷

　　基本認(rèn)證簡單便捷，但并不安全。只能用它來防止非惡意用戶無意間進(jìn)行的訪問，或?qū)⑵渑cSSL這樣的加密技術(shù)配合使用

　　基本認(rèn)證會(huì)通過網(wǎng)絡(luò)發(fā)送用戶名和密碼，這些用戶名和密碼都是以一種很容易解碼的形式表示的。實(shí)際上，密碼是以明文形式傳輸?shù)?，任何人都可以讀取并將其捕獲。雖然Base-64編碼通過隱藏用戶名和密碼，致使友好的用戶不太可能在進(jìn)行網(wǎng)絡(luò)觀測時(shí)無意中看到密碼，但Base-64編碼的用戶名和密碼可以很輕易地通過反向編碼過程進(jìn)行解碼，甚至可以用紙筆在幾秒鐘內(nèi)手工對其進(jìn)行解碼，所以經(jīng)過Base-64編碼的密碼實(shí)際上就是“明文”傳送的。如果有動(dòng)機(jī)的第三方用戶有可能會(huì)去攔截基本認(rèn)證發(fā)送的用戶名和密碼，就要通過SSL加密信道發(fā)送所有的HTTP事務(wù)，或者使用更安全的認(rèn)證協(xié)議，比如摘要認(rèn)證

　　即使密碼是以更難解碼的方式加密的，第三方用戶仍然可以捕獲被修改過的用戶名和密碼，并將修改過的用戶名和密碼一次一次地重放給原始服務(wù)器，以獲得對服務(wù)器的訪問權(quán)。沒有什么措施可用來防止這些重放***

　　即使將基本認(rèn)證用于一些不太重要的應(yīng)用程序，比如公司內(nèi)部網(wǎng)絡(luò)的訪問控制或個(gè)性化內(nèi)容的訪問，一些不良習(xí)慣也會(huì)讓它變得很危險(xiǎn)。很多用戶由于受不了大量密碼保護(hù)的服務(wù)，會(huì)在這些服務(wù)間使用相同的用戶名和密碼。比如說，***會(huì)從免費(fèi)的因特網(wǎng)郵件網(wǎng)站捕獲明文形式的用戶名和密碼，然后會(huì)發(fā)現(xiàn)用同樣的用戶名和密碼還可以訪問重要的在線銀行網(wǎng)站

　　基本認(rèn)證沒有提供任何針對代理和作為中間人的中間節(jié)點(diǎn)的防護(hù)措施，它們沒有修改認(rèn)證首部，但卻修改了報(bào)文的其余部分，這樣就嚴(yán)重地改變了事務(wù)的本質(zhì)

　　假冒服務(wù)器很容易騙過基本認(rèn)證。如果在用戶實(shí)際連接到一臺惡意服務(wù)器或網(wǎng)關(guān)的時(shí)候，能夠讓用戶相信他連接的是一個(gè)受基本認(rèn)證保護(hù)的合法主機(jī)，***者就可以請求用戶輸入密碼，將其存儲(chǔ)起來以備未來使用，然后捏造一條錯(cuò)誤信息傳送給用戶

　　這一切說明，在友好的環(huán)境，或者說是希望有隱私保護(hù)但隱私保護(hù)并不十分必要的環(huán)境中，可以通過基本認(rèn)證來提供便捷的文檔個(gè)性化服務(wù)或訪問控制保護(hù)。通過這種方式，可以用基本認(rèn)證來防止一些好奇的用戶無意中或不小心對文檔進(jìn)行訪問

　　比如，在一個(gè)公司內(nèi)部，產(chǎn)品管理可能要對未來的產(chǎn)品計(jì)劃進(jìn)行密碼保護(hù)，以防止信息的過早發(fā)布。對一般用戶而言，基本認(rèn)證就足以讓他們感到不便而不會(huì)再去訪問這些數(shù)據(jù)了。同樣，可能會(huì)用密碼來保護(hù)那些并非高度機(jī)密的，或者沒什么信息價(jià)值的私人照片或私有站點(diǎn)，這些信息確實(shí)和其他人也沒什么關(guān)系

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