HTTP的識別,認證與安全——《HTTP權威指南》系列

WilsonLiu's blog 首發地址

識別,認證與安全

第三部分的4章提供了一系列的技術和機器，可用來跟蹤身份，進行安全性檢測，控制對內容的訪問。

客戶端識別與cookie機制 第十一章

HTTP最初是一個匿名，無狀態的請求/響應協議。服務器處理來自客戶端的請求，而後向客戶端回送一條響應。web服務器幾乎沒有什麼信息能夠用來斷定是哪一個用戶發送的請求，也沒法記錄來訪用戶的請求序列。

用戶識別機制

• 承載用戶身份信息的HTTP首部

• 客戶端IP地址跟蹤，經過用戶的IP地址對其進行識別

• 用戶登陸，用認證方式來識別用戶

• 胖URL，一種在URL中嵌入識別信息的技術

• cookie，一種功能強大且高效的持久身份識別技術

HTTP首部

下表給出了7種常見的用來承載用戶相關信息的HTTP請求首部。後面3個首部是擴展類型的請求首部。

首部名稱	描述
From	用戶的E-mail地址
User-Agent	用戶的瀏覽器軟件
Referer	用戶是從這個頁面上依照連接跳轉過來的
Authorization	用戶名和密碼
Client-IP	客戶端的IP地址
X-Forwarded-For	客戶端的IP地址
Cookie	服務器產生的ID標籤

用戶登陸

爲了使web站點的登陸更加簡便，HTTP中包含了一種內建機制，能夠用WWW-Authenticate首部和Authorization首部向web站點傳送用戶的相關信息。一旦登陸，瀏覽器就能夠不斷地在每條發往這個站點的請求中發送這個登陸信息了。

缺點：保密性不強，不能跨站點，不一樣的站點須要從新輸入帳戶密碼。

胖URL

能夠經過胖URL將服務器上若干個獨立的HTTP事務捆綁成一個"會話"或"訪問"。用戶首次訪問這個web站點時，會生成一個惟一的ID，用服務器能夠識別的方式將這個ID添加到URL中，而後服務器就會將客戶端從新導向這個胖URL。

問題：

• 醜陋的URL

• 沒法共享URL

• 破壞緩存

• 額外的服務器負荷

• 逃逸口

• 在會話間是非持久的

cookie

cookie是當前識別用戶，實現持久會話的最好方式。最初由網景公司開發，但如今全部的主要瀏覽器都支持他。

cookie的類型

能夠籠統的分爲:會話cookie和持久cookie。會話cookie和持久cookie的惟一區別就是他們的過時時間。 若是設置了Discard參數，或者沒有設置Expires或Max-Age參數來講明擴展的過時時間，這個cookie就是一個會話cookie。

不一樣的站點使用不一樣的cookie

cookie的域屬性
產生cookie的服務器能夠向Set-Cookie響應首部添加一個Domain屬性來控制哪些站點開業看到那個cookie。

Set-cookie: user="wilson";domain="wilsonliu.cn"

則用戶訪問的任何以wilsonliu.cn結尾的站點都會講此cookie發佈出去。

cookie的路徑屬性
cookie規範甚至容許用戶將cookie與部分web站點關聯起來。能夠經過Path屬性來實現這一功能。

Set-cookie: year="21";domain="wilsonliu.cn";path=/year/

則只會在/year/下的站點時纔會發佈此cookie。

cookie成分

cookie版本0 (Netscape)

Set-Cookie首部

• Name=Value

• Expires

• domain

• Path

• Secure

cookie首部
客戶端發送請求時，會將全部與域，路徑，安全過濾器匹配的未過時的cookie都發送給這個站點。

cookie版本1 (RFC 2965)

Set-Cookie2

• Name = Value

• Version

• Comment

• CommentURL

• Discard

• domain

• Max-Age

• Path

• Port

• Secure

cookie首部
版本1的cookie會帶回與傳輸的每一個cookie相關的附加信息，用來描述每一個cookie途徑的過濾器。每一個匹配的cookie都必須包含來自相應的Set-Cookie2首部的全部Domain,Port和Path屬性。

基本認證機制 第十二章

基本認證質詢首部

HTTP/1.0 401 Unauthorized
WWW-Authenticate: Basic realm=quoted-realm

響應首部(經過base64編碼傳輸)

Authorization:Basic base64-username-and-password

摘要認證 第十三章

基本認證便捷靈活，但極不安全。用戶名與密碼明文傳輸，也沒有采起任何措施防止對報文的篡改。安全使用基本認證的惟一方式就是將其與SSL配合使用。

摘要認證與基本認證兼容。但卻更爲安全。

摘要認證的改進

• 永遠不會以明文的方式在網絡上發送密碼

• 能夠防止惡意用戶捕獲並重放認證的握手過程

• 能夠有選擇地防止對報文內容的篡改

• 防範其餘幾種常見的攻擊方式

用摘要保護密碼

摘要認證遵循的箴言是"毫不經過網絡發送密碼"。客戶端不會發送密碼，而是會發送一個「指紋」或密碼的"摘要"，這是密碼的不可逆擾碼。

單向摘要

摘要是"對信息主體的濃縮"。摘要是一種單向函數，主要用於將無限的輸入值轉換爲有限的濃縮輸出值。常見的摘要函數MD5，會將任意長度的字節序列轉換爲一個128位的摘要。
有時也將摘要函數稱爲加密的校驗和，單向散列函數或指紋函數。

用隨機數防止重放攻擊

使用單向摘要就無需以明文形式發送密碼，沒有哪一個而已用戶可以輕易地從摘要中解碼出原始密碼。

可是僅僅隱藏密碼並不能避免危險，由於即使不知道密碼，也能夠截獲摘要，並重放給服務器。摘要和密碼同樣好用。

爲防止此類重放攻擊的發生服務器能夠向客戶端發送一個稱爲隨機數(nonce)的特殊令牌，這個數會常常發生變化(多是每毫秒，或者是每次認證都變化)。客戶端在計算摘要以前要先將這個隨機數令牌附加到密碼上去。

摘要的計算

摘要認證的核心就是對公共信息，保密信息和有時限的隨機值這個組合的單項摘要。

數據

1. 與安全性相關的數據(A1) ——包含有用戶名，密碼，保護域和隨機數等內容

2. 與報文有關的數據(A2) ——好比URL，請求方法和報文實體，A2有助於防止方法，資源或報文被篡改

預受權

在普通的認證方式中，事務結束以前，每條請求都要有一次請求/質詢的循環。
若是客戶端事先知道下一個隨機數是什麼，就能夠取消這個請求/質詢循環。

• 服務器預先在Authentication-Info成功首部中發送下一個隨機數

• 服務器容許在一小段時間內使用同一個隨機數

• 客戶端和服務器使用同步的，可預測的隨機數生成算法

應該考慮的實際問題

• 多重質詢

• 差錯處理

• 保護空間

• 重寫URI

• 緩存

安全性考慮

• 首部篡改

• 重放攻擊

• 多重認證機制

• 詞典攻擊

• 惡意代理攻擊和中間人攻擊

• 選擇明文攻擊

• 存儲密碼

安全HTTP 第十四章

保護HTTP的安全

• 服務器認證

• 客戶端認證

• 完整性

• 加密

• 效率

• 普適性

• 管理的可擴展性

• 適應性

• 在社會的可行性

HTTPS

HTTPS是最流行的HTTP安全形式，它是由網景公司獨創，全部主要的瀏覽器和服務器都支持此協議。
使用HTTPS時，全部的HTTP請求和響應數據在發送到網絡以前，都要進行加密。HTTPS在HTTP下面提供了一個傳輸級的密碼安全層——可使用SSL，也可使用其後繼者，傳輸層安全(Transport Layer Security,TLS)。

大部分困難的編碼及解碼工做都是在SSL庫中完成的，因此web客戶端和服務器在使用安全HTTP時無需過多地修改器協議處理邏輯。在大多數狀況下，只須要用SSL的輸入/輸出調用取代TCP的調用，再增長其餘幾個調用來配置和管理安全信息就好了。

數字加密

• 密碼 對文本進行編碼，使偷窺者沒法識別的算法

• 密鑰 改變密碼行爲的數字化參數

• 對稱密鑰加密系統 編/解碼使用相同密鑰的算法

• 不對稱密鑰加密系統 編/解碼使用不一樣密鑰的算法

• 公開密鑰加密系統 一種可以使數百萬計算機便捷地發送機密報文的系統

• 數字簽名 用來驗證報文未被僞造或篡改的校驗和

• 數字證書 由一個可信的組織驗證和簽發的識別信息

密碼

密碼學基於一種名爲密碼(cipher)的祕密代碼。密碼是一套編碼方案——一種特殊的報文編碼方式和一種稍後使用的相應解碼方式的結合體。加密以前的原始報文一般被稱爲明文(plaintext或cleartext)。使用了密碼以後的編碼報文一般被稱做密文(ciphertext)。

使用密鑰的密碼

編碼算法和編碼機器均可能落入敵人手中，因此大部分機器上都有一些盤號，能夠將其設置爲大量不一樣的值以改變密碼的工做方式。這些密碼參數被稱爲密鑰(key)，要在密碼機中輸入正確的密鑰，解密過程才能正確進行。

對稱密鑰加密技術

編碼時使用的密鑰值和解碼時同樣，這就是對稱密鑰(symmetric-key)。

保持密鑰的機密狀態是很重要的，在不少狀況下，編/解碼算法都是衆所周知的，所以密鑰就是惟一保密的東西了。好的加密算法會迫使攻擊者試遍每個可能的密鑰，才能破解代碼。用暴力去嘗試全部的密鑰值稱爲枚舉攻擊(enumeration attack)。可用密鑰的數量取決於密鑰中的位數，以及可能的密鑰中有多少是有效的。

對稱密鑰加密技術的缺點之一就是發送者和接受者在互相對話以前，必定要有一個共享的保密密鑰。每對通訊實體都須要本身的私有密鑰。若是有N個節點，每一個節點都要和其餘全部的N-1個節點進行安全對話，總共須要N的平方個保密密鑰，這將是一個管理噩夢。

公開密鑰加密技術

公開密鑰使用了2個非對稱密鑰:一個用來對主機報文編碼，另一個用來對主機報文解碼。編碼密鑰是衆所周知的，但只要主機才知道私有的解密密鑰。
全部的公開密鑰非對稱加密系統所面臨的共同挑戰是，要確保即使有人擁有了下面全部的線索，也沒法計算出保密的私有密鑰:

• 公開密鑰

• 一小片攔截下來的密文(可經過對網絡的嗅探獲取)

• 一條報文及與之相關的密文(對任意一段文本運行加密器就能夠獲得)

混合加密系統和會話密鑰

兩節點間經過便捷的公開密鑰加密技術創建起安全通訊，而後再用那條安全的通道產生併發送臨時的隨即對稱密鑰，經過更快的對稱加密技術對其他的數據進行加密。

數字簽名

除了加/解密報文以外，還能夠用加密系統對報文進行簽名(sign)，以說明是誰編寫的報文，同時證實報文未被篡改過。這種技術被稱爲數字簽名(digital signing)。

1. 客戶端將變長報文提取爲定長的摘要

2. 客戶端對摘要應用了一個"簽名"函數，這個函數會將用戶的私有密鑰做爲參數。由於只有用戶才知道私有密鑰，因此正確的簽名函數會說明簽名者就是其全部者。

3. 一旦計算出簽名，客戶端就將其附加在報文的末尾，並將報文和簽名都發送給對方。

4. 在接收端，會用公開密鑰對簽名進行檢查，若是不匹配則表示已被篡改。

使用數字簽名的好處

1. 簽名能夠驗證是做者編寫了這條報文，只有做者纔會有最機密的私有密鑰，所以，只有做者才能計算出這些校驗和。校驗和就像來自做者的我的「簽名」同樣。

2. 簽名能夠防止報文被篡改，若是有惡意攻擊者在報文傳輸過程當中對其進行了修改，校驗和就再也不匹配了。因爲校驗和只有做者保密的私有密鑰才能產生，因此攻擊者沒法爲篡改了的報文僞造出正確的校驗碼。

數字證書

數字證書中包含了由某個受信任組織擔保的用戶或公司的相關信息。數字證書都是由官方的"證書頒發機構"以數字方式簽發的。
經過HTTPS創建了一個安全web事務以後，現代瀏覽器都會自動獲取所鏈接服務器的數字證書。若是服務器沒有證書，安全鏈接就會失敗。瀏覽器收到證書的時候會對簽名頒發機構進行檢查。

HTTPS——細節介紹

HTTPS將HTTP協議與一組強大的對稱，非對稱和基於證書的加密技術結合在一塊兒，使得HTTPS不只很安全，並且很靈活，很容易在處於無序狀態的，分散的全球互聯網上進行管理。

客戶端會對web資源執行某事務時，他會去檢查URL的方案，若是URL的方案是https，客戶端就會打開一條到服務器端口443(而不是傳統的http默認的80端口)的鏈接，而後與服務器進行SSL"握手"，以二進制格式與服務器交換一些SSL安全參數，附加上加密的HTTP命令。

站點證書的有效性

1. 日期檢測

2. 簽名頒發者可信度檢測

3. 簽名檢測

4. 站點身份檢測

經過代理以隧道形式傳輸安全流量

客戶端一般會用web代理服務器表明它們來訪問web服務器。但只要客戶端開始用服務器的公開密鑰對發往服務器的數據進行加密，代理就不再能讀取HTTP首部了！就沒法知道應該將請求轉向何處了。爲了使HTTPS與代理配合工做，能夠用HTTPS SSL隧道協議。使用HTTPS隧道協議，客戶端首先告訴代理，它想要鏈接的安全主機和端口。這是在開始加密以前，以明文形式告知的。