web安全认证机制知多少
? ? 如今web服務隨處可見，成千上萬的web程序被部署到公網(wǎng)上供用戶訪問，有些系統(tǒng)只針對指定用戶開放，屬于安全級別較高的web應用，他們需要有一種認證機制以保護系統(tǒng)資源的安全，本文將探討五種常用的認證機制及優(yōu)缺點。
Basic模式
HTTP協(xié)議規(guī)范中有兩種認證方式，一種是Basic認證，另外一種是Digest認證，這兩種方式都屬于無狀態(tài)認證方式，所謂無狀態(tài)即服務端都不會在會話中記錄相關信息，客戶端每次訪問都需要將用戶名和密碼放置報文一同發(fā)送給服務端，但這并不表示你在瀏覽器中每次訪問都要自己輸入用戶名和密碼，可能是你第一次輸入賬號后瀏覽器就保留在內存中供后面的交互使用。先看下HTTP協(xié)議的Basic認證模式。
既然是HTTP協(xié)議規(guī)范，那其實就是約束瀏覽器廠商與web容器廠商實現(xiàn)各自軟件時的行為約束，例如典型的一個認證交互過程是：瀏覽器向web容器發(fā)送http請求報文，web容器接收到http請求報文后解析需要訪問的資源，如果該資源剛好是受保護資源，web容器則向瀏覽器發(fā)送認證http響應報文，瀏覽器接收到報文后彈出窗口讓用戶輸入賬號及密碼，接著再次發(fā)送包含了賬號信息的http請求報文，web容器對賬號信息進行鑒權，通過驗證則返回對應資源，否則重新認證。
Basic Access Authentication scheme是在HTTP1.0提出的認證方法，它是一種基于challenge/response的認證模式，針對特定的realm需要提供用戶名和密碼認證后才可訪問，其中密碼使用明文傳輸。Basic模式認證過程如下：
①瀏覽器發(fā)送http報文請求一個受保護的資源。
②服務端的web容器將http響應報文的響應碼設為401，響應頭部加入WWW-Authenticate: Basic realm=”myTomcat”。
③瀏覽器彈出對話框讓用戶輸入用戶名和密碼，并用Base64進行編碼，實際是用戶名+冒號+密碼進行Base64編碼，即Base64(username:password)，這次瀏覽器就會在HTTP報文頭部加入Authorization: Basic bXl0b21jYXQ=。
④服務端web容器獲取HTTP報文頭部相關認證信息，匹配此用戶名與密碼是否正確，是否有相應資源的權限，如果認證成功則返回相關資源，否則再執(zhí)行②，重新進行認證。
⑤以后每次訪問都要帶上認證頭部。
服務端返回的認證報文中包含了realm=”myTomcat”，realm的值用于定義保護的區(qū)域，在服務端可以通過realm將不同的資源分成不同的域，域的名稱即為realm的值，每個域可能會有自己的權限鑒別方案。
Basic認證模式有兩個明顯的缺點：①無狀態(tài)導致每次通信都要帶上認證信息，即使是已經(jīng)認證過的資源；②傳輸安全性不足，認證信息用Base64編碼，基本就是明文傳輸，很容易對報文截取并盜用認證信息。
Digest模式
HTTP協(xié)議規(guī)范的另一種認證模式是Digest模式，在HTTP1.1時被提出來，它主要是為了解決Basic模式安全問題，用于替代原來的Basic認證模式，Digest認證也是采用challenge/response認證模式，基本的認證流程比較類似，整個過程如下：
①瀏覽器發(fā)送http報文請求一個受保護的資源。
②服務端的web容器將http響應報文的響應碼設為401，響應頭部比Basic模式復雜，WWW-Authenticate: Digest realm=”myTomcat”,qop="auth",nonce="xxxxxxxxxxx",opaque="xxxxxxxx" 。其中qop的auth表示鑒別方式；nonce是隨機字符串；opaque服務端指定的值，客戶端需要原值返回。
③瀏覽器彈出對話框讓用戶輸入用戶名和密碼，瀏覽器對用戶名、密碼、nonce值、HTTP請求方法、被請求資源URI等組合后進行MD5運算，把計算得到的摘要信息發(fā)送給服務端。請求頭部類似如下，Authorization: Digest username="xxxxx",realm="myTomcat",qop="auth",nonce="xxxxx",uri="xxxx",cnonce="xxxxxx",nc=00000001,response="xxxxxxxxx",opaque="xxxxxxxxx"?。其中username是用戶名；cnonce是客戶端生成的隨機字符串；nc是運行認證的次數(shù)；response就是最終計算得到的摘要。
④服務端web容器獲取HTTP報文頭部相關認證信息，從中獲取到username，根據(jù)username獲取對應的密碼，同樣對用戶名、密碼、nonce值、HTTP請求方法、被請求資源URI等組合進行MD5運算，計算結果和response進行比較，如果匹配則認證成功并返回相關資源，否則再執(zhí)行②，重新進行認證。
⑤以后每次訪問都要帶上認證頭部。
其實通過哈希算法對通信雙方身份的認證十分常見，它的好處就是不必把具備密碼的信息對外傳輸，只需將這些密碼信息加入一個對方給定的隨機值計算哈希值，最后將哈希值傳給對方，對方就可以認證你的身份。Digest思想同樣采如此，用了一種nonce隨機數(shù)字符串，雙方約好對哪些信息進行哈希運算即可完成雙方身份的驗證。Digest模式避免了密碼在網(wǎng)絡上明文傳輸，提高了安全性，但它仍然存在缺點，例如認證報文被攻擊者攔截到攻擊者可以獲取到資源。
Form模式
上面介紹的兩種模式都屬于HTTP協(xié)議規(guī)范范疇，由于它的規(guī)范使得很多東西無法自定義，例如登錄窗口、錯誤展示頁面。所以需要另外一種模式提供更加靈活的認證，也就是基于Form的認證模式，各種語言體系的web容器都可以實現(xiàn)各自的Form模式，這里只介紹java體系的Form認證模式：
Form模式的認證流程如下：
①瀏覽器發(fā)送http報文請求一個受保護的資源。
②服務端的web容器判斷此uri為受保護資源，于是將請求重定向到自定義的登陸頁面上，例如login.html頁面，可以自定義登陸頁面的樣式，但要遵守的約定是表單的action必須以j_security_check結尾，即<form action='xxxxxx/j_security_check' method='POST'>。用戶名和密碼輸入框元素的name必須為'j_username'?和'j_password'。
③瀏覽器展示自定義的登陸頁面讓用戶輸入用戶名和密碼，然后提交表單。
④服務端web容器獲取表單的用戶名和密碼，匹配此用戶名與密碼是否正確，是否有相應資源的權限，如果認證成功則返回相關資源，否則再執(zhí)行②，重新進行認證。
⑤后面在同個會話期間的訪問都不用再進行認證，因為認證的結果已經(jīng)保存在服務端的session里面。 ????
Form模式跳出了HTTP規(guī)范提供了自定義的更加靈活的認證模式，由于每種語言都可以自己定義實現(xiàn)自己的Form模式，所以它沒有一個通用的標準，而且它也存在密碼明文傳輸安全問題。
Spnego模式
Spnego模式是一種由微軟提出的使用GSS-API接口的認證模式，它擴展了Kerberos協(xié)議，在了解Spnego協(xié)議之前必須先了解Kerberos協(xié)議，Kerberos協(xié)議主要解決身份認證及通信密鑰協(xié)商問題，它大致的工作流程如下：
?
①客戶端根據(jù)自己用戶名向密鑰分發(fā)中心KDC的身份認證服務AS請求TGS票證。
②AS生成一個TGS票證、查詢對應用戶的密碼，然后通過用戶密碼將TGS票證加密，響應給客戶端。
③客戶端通過用戶密碼解密TGS票證，如果密碼正確就能獲取到TGS票證，然后用TGS票證去票證授予服務TGS請求服務票證。
④TGS將服務票證響應給客戶端。
⑤客戶端使用服務票證去訪問某服務，服務驗證服務票據(jù)是否合法。
⑥驗證通過，開始通信。
在了解了Kerberos協(xié)議后，我們再來看看Spnego的認證過程是怎樣的。由于spnego擴展自kerberos協(xié)議，認證的核心流程一樣，只是在瀏覽器與web服務器之間的http通信過程中嵌入認證流程。如下圖：
?
①客戶端瀏覽器向web服務器發(fā)送http請求。
②服務器返回401狀態(tài)碼，響應頭部加上 WWW-Authenticate:Negotiate。
③用戶通過瀏覽器輸入用戶名向AS請求TGS票證。
④AS生成TGS票證，然后查詢用戶密碼并用此密碼加密TGS票證，返回瀏覽器。
⑤瀏覽器使用用戶密碼解密出TGS票證，并向TGS服務發(fā)起請求。
⑥TGS服務生成服務票證響應給瀏覽器。
⑦瀏覽器將服務票證封裝到SPNEGO token中，并發(fā)送給web服務器。
⑧服務器解密出用戶名及服務票證，將票證發(fā)往TGS服務驗證。
⑨通過驗證，開始通信。
????可以看到Spnego模式提供了更加強大的安全認證，它將認證模塊獨立出來，雖然結構復雜了，但這樣可以為所有應用提供認證功能，例如它可以很容易實現(xiàn)多個系統(tǒng)之間的單點登錄。
SSL模式
SSL模式是基于SSL通信的一種認證模式，它的大體流程是這樣的：客戶端與服務器之間通過SSL協(xié)議建立起SSL通道，這個過程比較復雜，涉及到客戶端服務端證書互相交互驗證，協(xié)商通信密鑰等過程，細節(jié)可以前往SSL章節(jié)閱讀。完成整個SSL通道建立后才是認證的核心步驟，如下圖，
?
①首先獲取客戶端證書文件，這個由于在SSL協(xié)議期間已經(jīng)發(fā)送到服務端，所以可以直接從內存中獲取，然后解析證書文件得到證書標識。
②通過這個證書標識去存放用戶信息的地方查找出對應客戶端證書用戶的相關信息。
③檢查此用戶是否有相關資源的權限，如果驗證通過則返回請求相關資源。 ?
SSL模式也提供了高安全認證，它只對頒發(fā)的客戶端證書個體信任，可用于服務端與服務端之間的通信，也可以用在瀏覽器與web服務器之間通信，這時必須使用https協(xié)議，因為它必須走SSL協(xié)議通道才能完成認證流程。 ???
本文介紹了五種常見的安全認證機制，他們各自有各自的優(yōu)缺點，在實際使用中根據(jù)具體的場景選擇不同的認證機制。
==========廣告時間==========
鄙人的新書《Tomcat內核設計剖析》已經(jīng)在京東預售了，有需要的朋友可以到 https://item.jd.com/12185360.html 進行預定。感謝各位朋友。
=========================
總結
以上是生活随笔為你收集整理的web安全认证机制知多少的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 线程池源码分析-FutureTask
- 下一篇： Self Crossing