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隧道協議，客戶端首先告訴代理，它想要連接的安全主機和端口。這是在開始加密之前，以明文形式告知的。