?
? ????? PHP ??? ???? ??? ?? ??
HTTP為訪問(wèn)控制和身份驗(yàn)證提供了一個(gè)通用框架。最常見(jiàn)的HTTP認(rèn)證方案是“基本”認(rèn)證。本頁(yè)面介紹了一般HTTP驗(yàn)證框架,并展示了如何使用HTTP基本驗(yàn)證來(lái)限制對(duì)服務(wù)器的訪問(wèn)。
RFC 7235定義了HTTP認(rèn)證框架,服務(wù)器可以使用該框架挑戰(zhàn)客戶(hù)端請(qǐng)求,并由客戶(hù)端提供認(rèn)證信息。挑戰(zhàn)和響應(yīng)流程如下所示:服務(wù)器響應(yīng)具有401
(未授權(quán))響應(yīng)狀態(tài)的客戶(hù)端,并提供有關(guān)如何使用WWW-Authenticate
至少包含一個(gè)挑戰(zhàn)的響應(yīng)標(biāo)頭進(jìn)行授權(quán)的信息。然后,想要使用服務(wù)器進(jìn)行身份驗(yàn)證的客戶(hù)端可以通過(guò)Authorization
在憑證中包含請(qǐng)求標(biāo)頭字段來(lái)完成此操作。通常,客戶(hù)端會(huì)向用戶(hù)顯示密碼提示,然后發(fā)出包含正確Authorization
標(biāo)題的請(qǐng)求。
在如圖所示的“基本”認(rèn)證的情況下,交換必須通過(guò)HTTPS(TLS)連接進(jìn)行以確保安全。
代理驗(yàn)證可以使用相同的質(zhì)詢(xún)和響應(yīng)機(jī)制。在這種情況下,它是需要認(rèn)證的中間代理。由于資源認(rèn)證和代理認(rèn)證可以共存,因此需要一組不同的標(biāo)題和狀態(tài)代碼。對(duì)于代理服務(wù)器,具有挑戰(zhàn)性的狀態(tài)代碼是407
(需要代理服務(wù)器認(rèn)證),Proxy-Authenticate
響應(yīng)標(biāo)頭至少包含一個(gè)適用于代理服務(wù)器的挑戰(zhàn),并且Proxy-Authorization
請(qǐng)求標(biāo)頭用于向代理服務(wù)器提供憑證。
如果(代理)服務(wù)器接收到的有效憑證不足以獲取給定資源的訪問(wèn)權(quán)限,則服務(wù)器應(yīng)該使用403
Forbidden
狀態(tài)代碼進(jìn)行響應(yīng)。不像401
Unauthorized
或者407
Proxy Authentication Required
,這個(gè)用戶(hù)不可能進(jìn)行身份驗(yàn)證。
WWW-Authenticate
and Proxy-Authenticate
headersWWW-Authenticate
和Proxy-Authenticate
響應(yīng)標(biāo)頭定義應(yīng)該被用來(lái)獲得對(duì)資源的訪問(wèn)的驗(yàn)證方法。他們需要指定使用哪種認(rèn)證方案,以便希望授權(quán)的客戶(hù)端知道如何提供憑證。這些標(biāo)題的語(yǔ)法如下所示:
WWW-Authenticate: <type> realm=<realm>Proxy-Authenticate: <type> realm=<realm>
這里<type>
是認(rèn)證方案(“基本”是最常見(jiàn)的方案,下面介紹)。該領(lǐng)域用于描述保護(hù)區(qū)域或指示保護(hù)范圍。這可能是“訪問(wèn)登臺(tái)站點(diǎn)”或類(lèi)似消息,以便用戶(hù)知道他們?cè)噲D訪問(wèn)哪個(gè)空間。
Authorization
和Proxy-Authorization
標(biāo)題所述Authorization
和Proxy-Authorization
請(qǐng)求報(bào)頭包含憑證與一個(gè)(代理)服務(wù)器進(jìn)行認(rèn)證的用戶(hù)代理。在此,需要再次輸入憑證,憑證可以根據(jù)使用的認(rèn)證方案進(jìn)行編碼或加密。
Authorization: <type> <credentials>Proxy-Authorization: <type> <credentials>
一般的HTTP認(rèn)證框架被多個(gè)認(rèn)證方案使用。方案可以在安全強(qiáng)度和客戶(hù)端或服務(wù)器軟件的可用性方面有所不同。
最常見(jiàn)的認(rèn)證方案是下面更詳細(xì)介紹的“基本”認(rèn)證方案。IANA維護(hù)認(rèn)證方案列表,但還有其他由主機(jī)服務(wù)提供的方案,例如Amazon AWS。常見(jiàn)的認(rèn)證方案包括:
基本(請(qǐng)參閱RFC 7617,base64編碼憑證,請(qǐng)參閱下面的更多信息。),
承載(請(qǐng)參閱RFC 6750,承載令牌訪問(wèn)受OAuth 2.0保護(hù)的資源),
摘要(請(qǐng)參閱RFC 7616,F(xiàn)irefox中只支持md5散列,請(qǐng)參閱SHA加密支持的bug 472823),
HOBA(參見(jiàn)RFC 7486(草案),? TTP ? rigin- 乙 ound 甲 uthentication,數(shù)字簽名系),
相互(見(jiàn)draft-ietf-httpauth-mutual),
AWS4-HMAC-SHA256(請(qǐng)參閱AWS文檔)。
“基本”HTTP身份驗(yàn)證方案在RFC 7617中定義,該身份驗(yàn)證方案將憑據(jù)作為用戶(hù)ID /密碼對(duì)發(fā)送,并使用base64進(jìn)行編碼。
由于用戶(hù)標(biāo)識(shí)和密碼以明文形式傳遞(它是base64編碼,但base64是可逆編碼),因此基本認(rèn)證方案不安全。HTTPS / TLS應(yīng)與基本認(rèn)證一起使用。如果沒(méi)有這些額外的安全增強(qiáng)功能,則不應(yīng)使用基本身份驗(yàn)證來(lái)保護(hù)敏感或有價(jià)值的信息。
要在Apache服務(wù)器上密碼保護(hù)目錄,您需要一個(gè).htaccess
和一個(gè).htpasswd
文件。
該.htaccess
文件通常如下所示:
AuthType Basic AuthName "Access to the staging site"AuthUserFile /path/to/.htpasswd Require valid-user
該.htaccess
文件引用一個(gè).htpasswd
文件,其中每行包含由冒號(hào)(“:”)分隔的用戶(hù)名和密碼。您看不到加密的實(shí)際密碼(本例中為md5)。請(qǐng)注意,.htpasswd
如果您喜歡,您可以以不同的方式命名文件,但請(qǐng)記住,任何人都無(wú)法訪問(wèn)此文件。(Apache通常配置為阻止訪問(wèn).ht*
文件)。
aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/
對(duì)于nginx,你將需要指定一個(gè)你將要保護(hù)的位置,以及auth_basic
為密碼保護(hù)區(qū)域提供名稱(chēng)的指令。auth_basic_user_file
然后該指令指向包含加密用戶(hù)憑證的.htpasswd文件,就像上面的Apache示例一樣。
location /status { auth_basic "Access to the staging site"; auth_basic_user_file /etc/apache2/.htpasswd;}
許多客戶(hù)端還可以通過(guò)使用包含用戶(hù)名和密碼的編碼URL避免登錄提示:
https://username:password@www.example.com/
這些URL的使用已被棄用。在Chrome中,出于安全原因username:password@
,URL中的部分甚至被刪除。在Firefox中,檢查網(wǎng)站是否實(shí)際需要身份驗(yàn)證,如果不是,F(xiàn)irefox會(huì)提示用戶(hù)提示“您將用用戶(hù)名”username“登錄到網(wǎng)站”www.example.com“,但是網(wǎng)站不需要認(rèn)證,這可能是企圖誘騙你?!?/p>
WWW-Authenticate
Authorization
Proxy-Authorization
Proxy-Authenticate
401
, 403
, 407