眾所周知,web使人們可以很方便的訪問分布在世界各個角落裡資訊。但是僅僅是方便還是不夠的,並不是所有的資訊都適合在網際網路上公開訪問,我們需要保證只有特定的人才能看到我們的敏感資訊並且執行特定的操作。
伺服器需要通過某種方式了解訪問使用者的身份。一旦伺服器知道了使用者身份,就可以判斷使用者可以訪問的事務和資源了。認證意味著要證明客戶端訪問使用者是誰。通常情況是通過提供使用者名稱和密碼來認證的。http為我們提供了一些原生的工具。今天我們來看下基本認證。
http提供了乙個原生的質詢/響應框架,簡化了對使用者的認證過程。http的認證模型如圖所示。
web伺服器接收到一條http請求報文時,伺服器沒有直接響應請求的資源,而是以乙個「認證質詢」進行響應,要求使用者提供一些保密資訊來說明其身份。使用者再次發起請求時,要附上保密證書(使用者名稱和密碼)。如果與要求的不匹配,伺服器可以再次質詢客戶端,或者產生一條錯誤資訊。如果證書匹配則返回請求的資源。
http提供可定製的控制首部,為不同的認證協議提供了乙個可擴充套件框架。
http提供了兩個認證協議:基本認證和摘要認證。
基本認證例項
客戶端請求某資源。
伺服器對使用者進行質詢時,會返回一條401unauthorized響應,並在www-authenticate首部中說明可以使用的認證方式。
客戶端重新傳送請求,並在authorization首部附加上使用者名稱、密碼等其他一些認證引數。
授權成功完成後,伺服器會返回乙個正常的狀態碼(比如,200 ok),對於高階演算法來說,可能還會在authentication-info首部附加額外的資訊。
http基本認證將使用者名稱和密碼打包在一起,並使用base-64編碼方式對其進行編碼。具體過程如下圖所示。
基本認證通過網路傳送使用者名稱和密碼,雖然進行base-64編碼可以隱藏使用者名稱和密碼,但是很容易通過反向編碼過程進行解碼。
即使密碼以更加難以解碼的方式加密,第三方使用者仍然可以捕獲被修改過的使用者名稱和密碼,並通過重放攻擊獲取伺服器的訪問許可權。
基本認證沒有提供任何針對**和中間人節點的防護措施,他們沒有修改認證首部,但卻修改了報文的其餘部分,這樣就嚴重的改變了事務的本質。
假冒伺服器很容易騙過基本認證。如果在使用者實際鏈結到一台惡意伺服器或者閘道器的時候,能夠讓使用者相信他鏈結的是乙個受基本認證保護的合法主機,攻擊者就可以請求使用者輸入密碼。
iis中站點預設開啟匿名身份驗證,並可以直接訪問。
iis中站點預設開啟匿名身份驗證,並可以直接訪問
2. 關閉匿名認證,開啟基本認證方式,直接訪問需要輸入使用者名稱密碼
3.客戶端模擬基本認證過程
控制台模擬**如下
using system;
using system.collections.generic;
using system.io;
using system.linq;
using system.net;
using system.text;
using system.threading.tasks;
catch (webexception ex)
console.writeline("新增authorization認證頭部並重新傳送請求");
console.writeline("請求響應的內容如下");
HTTP 基本認證,摘要認證,擴充套件HTTP認證
http請求報頭 authorization http響應報頭 www authenticate http認證 基於質詢 回應 challenge response 的認證模式。基本認證 basic authentication http1.0提出的認證方法 客戶端對於每乙個realm,通過提供使用...
HTTP基本認證
http提供了乙個原生的質詢 響應框架,簡化了對使用者的認證過程。http的認證模型如圖所示.web伺服器接收到一條http請求報文時,伺服器沒有直接響應請求的資源,而是以乙個 認證質詢 進行響應,要求使用者提供一些保密資訊來說明其身份。使用者再次發起請求時,要附上保密證書 使用者名稱和密碼 如果與...
HTTP基本認證
在最近的專案中,需要實現乙個客戶端,通過http協議訪問web伺服器,即c s架構。使用客戶端的功能前需要先進行登入認證,原本的設計是 客戶端登入成功後,維護乙個cookie用於保持當前的登入狀態。但是最終的做法是,採用了 http基本認證 就是將使用者的使用者名稱和密碼放在http請求頭部的aut...