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

則用戶訪問(wèn)的任何以wilsonliu.cn結(jié)尾的站點(diǎn)都會(huì)講此cookie發(fā)布出去。

cookie的路徑屬性
cookie規(guī)范甚至允許用戶將cookie與部分web站點(diǎn)關(guān)聯(lián)起來(lái)。可以通過(guò)Path屬性來(lái)實(shí)現(xiàn)這一功能。

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

則只會(huì)在/year/下的站點(diǎn)時(shí)才會(huì)發(fā)布此cookie。

Set-Cookie首部

Name=Value

Expires

domain

Path

Secure

cookie首部
客戶端發(fā)送請(qǐng)求時(shí)，會(huì)將所有與域，路徑，安全過(guò)濾器匹配的未過(guò)期的cookie都發(fā)送給這個(gè)站點(diǎn)。

Set-Cookie2

Name = Value

Version

Comment

CommentURL

Discard

domain

Max-Age

Path

Port

Secure

cookie首部
版本1的cookie會(huì)帶回與傳輸?shù)拿總€(gè)cookie相關(guān)的附加信息，用來(lái)描述每個(gè)cookie途徑的過(guò)濾器。每個(gè)匹配的cookie都必須包含來(lái)自相應(yīng)的Set-Cookie2首部的所有Domain,Port和Path屬性。

基本認(rèn)證質(zhì)詢首部

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

響應(yīng)首部(通過(guò)base64編碼傳輸)

Authorization:Basic base64-username-and-password

基本認(rèn)證便捷靈活，但極不安全。用戶名與密碼明文傳輸，也沒(méi)有采取任何措施防止對(duì)報(bào)文的篡改。安全使用基本認(rèn)證的唯一方式就是將其與SSL配合使用。

摘要認(rèn)證與基本認(rèn)證兼容。但卻更為安全。

永遠(yuǎn)不會(huì)以明文的方式在網(wǎng)絡(luò)上發(fā)送密碼

可以防止惡意用戶捕獲并重放認(rèn)證的握手過(guò)程

可以有選擇地防止對(duì)報(bào)文內(nèi)容的篡改

防范其他幾種常見(jiàn)的攻擊方式

摘要認(rèn)證遵循的箴言是"絕不通過(guò)網(wǎng)絡(luò)發(fā)送密碼"。客戶端不會(huì)發(fā)送密碼，而是會(huì)發(fā)送一個(gè)“指紋”或密碼的"摘要"，這是密碼的不可逆擾碼。

摘要是"對(duì)信息主體的濃縮"。摘要是一種單向函數(shù)，主要用于將無(wú)限的輸入值轉(zhuǎn)換為有限的濃縮輸出值。常見(jiàn)的摘要函數(shù)MD5，會(huì)將任意長(zhǎng)度的字節(jié)序列轉(zhuǎn)換為一個(gè)128位的摘要。
有時(shí)也將摘要函數(shù)稱為加密的校驗(yàn)和，單向散列函數(shù)或指紋函數(shù)。

使用單向摘要就無(wú)需以明文形式發(fā)送密碼，沒(méi)有哪個(gè)而已用戶能夠輕易地從摘要中解碼出原始密碼。

但是僅僅隱藏密碼并不能避免危險(xiǎn)，因?yàn)榧幢悴恢烂艽a，也可以截獲摘要，并重放給服務(wù)器。摘要和密碼一樣好用。

為防止此類重放攻擊的發(fā)生服務(wù)器可以向客戶端發(fā)送一個(gè)稱為隨機(jī)數(shù)(nonce)的特殊令牌，這個(gè)數(shù)會(huì)經(jīng)常發(fā)生變化(可能是每毫秒，或者是每次認(rèn)證都變化)。客戶端在計(jì)算摘要之前要先將這個(gè)隨機(jī)數(shù)令牌附加到密碼上去。

摘要認(rèn)證的核心就是對(duì)公共信息，保密信息和有時(shí)限的隨機(jī)值這個(gè)組合的單項(xiàng)摘要。

與安全性相關(guān)的數(shù)據(jù)(A1) ——包含有用戶名，密碼，保護(hù)域和隨機(jī)數(shù)等內(nèi)容

與報(bào)文有關(guān)的數(shù)據(jù)(A2) ——比如URL，請(qǐng)求方法和報(bào)文實(shí)體，A2有助于防止方法，資源或報(bào)文被篡改

在普通的認(rèn)證方式中，事務(wù)結(jié)束之前，每條請(qǐng)求都要有一次請(qǐng)求/質(zhì)詢的循環(huán)。
如果客戶端事先知道下一個(gè)隨機(jī)數(shù)是什么，就可以取消這個(gè)請(qǐng)求/質(zhì)詢循環(huán)。

服務(wù)器預(yù)先在Authentication-Info成功首部中發(fā)送下一個(gè)隨機(jī)數(shù)

服務(wù)器允許在一小段時(shí)間內(nèi)使用同一個(gè)隨機(jī)數(shù)

客戶端和服務(wù)器使用同步的，可預(yù)測(cè)的隨機(jī)數(shù)生成算法

多重質(zhì)詢

差錯(cuò)處理

保護(hù)空間

重寫(xiě)URI

緩存

首部篡改

重放攻擊

多重認(rèn)證機(jī)制

詞典攻擊

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

選擇明文攻擊

存儲(chǔ)密碼

服務(wù)器認(rèn)證

客戶端認(rèn)證

完整性

加密

效率

普適性

管理的可擴(kuò)展性

適應(yīng)性

在社會(huì)的可行性

HTTPS是最流行的HTTP安全形式，它是由網(wǎng)景公司首創(chuàng)，所有主要的瀏覽器和服務(wù)器都支持此協(xié)議。
使用HTTPS時(shí)，所有的HTTP請(qǐng)求和響應(yīng)數(shù)據(jù)在發(fā)送到網(wǎng)絡(luò)之前，都要進(jìn)行加密。HTTPS在HTTP下面提供了一個(gè)傳輸級(jí)的密碼安全層——可以使用SSL，也可以使用其后繼者，傳輸層安全(Transport Layer Security,TLS)。

大部分困難的編碼及解碼工作都是在SSL庫(kù)中完成的，所以web客戶端和服務(wù)器在使用安全HTTP時(shí)無(wú)需過(guò)多地修改器協(xié)議處理邏輯。在大多數(shù)情況下，只需要用SSL的輸入/輸出調(diào)用取代TCP的調(diào)用，再增加其他幾個(gè)調(diào)用來(lái)配置和管理安全信息就行了。

密碼 對(duì)文本進(jìn)行編碼，使偷窺者無(wú)法識(shí)別的算法

密鑰 改變密碼行為的數(shù)字化參數(shù)

對(duì)稱密鑰加密系統(tǒng) 編/解碼使用相同密鑰的算法

不對(duì)稱密鑰加密系統(tǒng) 編/解碼使用不同密鑰的算法

公開(kāi)密鑰加密系統(tǒng) 一種能夠使數(shù)百萬(wàn)計(jì)算機(jī)便捷地發(fā)送機(jī)密報(bào)文的系統(tǒng)

數(shù)字簽名 用來(lái)驗(yàn)證報(bào)文未被偽造或篡改的校驗(yàn)和

數(shù)字證書(shū) 由一個(gè)可信的組織驗(yàn)證和簽發(fā)的識(shí)別信息

密碼學(xué)基于一種名為密碼(cipher)的秘密代碼。密碼是一套編碼方案——一種特殊的報(bào)文編碼方式和一種稍后使用的相應(yīng)解碼方式的結(jié)合體。加密之前的原始報(bào)文通常被稱為明文(plaintext或cleartext)。使用了密碼之后的編碼報(bào)文通常被稱作密文(ciphertext)。

編碼算法和編碼機(jī)器都可能落入敵人手中，所以大部分機(jī)器上都有一些盤號(hào)，可以將其設(shè)置為大量不同的值以改變密碼的工作方式。這些密碼參數(shù)被稱為密鑰(key)，要在密碼機(jī)中輸入正確的密鑰，解密過(guò)程才能正確進(jìn)行。

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

保持密鑰的機(jī)密狀態(tài)是很重要的，在很多情況下，編/解碼算法都是眾所周知的，因此密鑰就是唯一保密的東西了。好的加密算法會(huì)迫使攻擊者試遍每一個(gè)可能的密鑰，才能破解代碼。用暴力去嘗試所有的密鑰值稱為枚舉攻擊(enumeration attack)。可用密鑰的數(shù)量取決于密鑰中的位數(shù)，以及可能的密鑰中有多少是有效的。

對(duì)稱密鑰加密技術(shù)的缺點(diǎn)之一就是發(fā)送者和接受者在互相對(duì)話之前，一定要有一個(gè)共享的保密密鑰。每對(duì)通信實(shí)體都需要自己的私有密鑰。如果有N個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)都要和其他所有的N-1個(gè)節(jié)點(diǎn)進(jìn)行安全對(duì)話，總共需要N的平方個(gè)保密密鑰，這將是一個(gè)管理噩夢(mèng)。

公開(kāi)密鑰使用了2個(gè)非對(duì)稱密鑰:一個(gè)用來(lái)對(duì)主機(jī)報(bào)文編碼，另外一個(gè)用來(lái)對(duì)主機(jī)報(bào)文解碼。編碼密鑰是眾所周知的，但只要主機(jī)才知道私有的解密密鑰。
所有的公開(kāi)密鑰非對(duì)稱加密系統(tǒng)所面臨的共同挑戰(zhàn)是，要確保即便有人擁有了下面所有的線索，也無(wú)法計(jì)算出保密的私有密鑰:

公開(kāi)密鑰

一小片攔截下來(lái)的密文(可通過(guò)對(duì)網(wǎng)絡(luò)的嗅探獲取)

一條報(bào)文及與之相關(guān)的密文(對(duì)任意一段文本運(yùn)行加密器就可以得到)

混合加密系統(tǒng)和會(huì)話密鑰

兩節(jié)點(diǎn)間通過(guò)便捷的公開(kāi)密鑰加密技術(shù)建立起安全通信，然后再用那條安全的通道產(chǎn)生并發(fā)送臨時(shí)的隨即對(duì)稱密鑰，通過(guò)更快的對(duì)稱加密技術(shù)對(duì)其余的數(shù)據(jù)進(jìn)行加密。

除了加/解密報(bào)文之外，還可以用加密系統(tǒng)對(duì)報(bào)文進(jìn)行簽名(sign)，以說(shuō)明是誰(shuí)編寫(xiě)的報(bào)文，同時(shí)證明報(bào)文未被篡改過(guò)。這種技術(shù)被稱為數(shù)字簽名(digital signing)。

客戶端將變長(zhǎng)報(bào)文提取為定長(zhǎng)的摘要

客戶端對(duì)摘要應(yīng)用了一個(gè)"簽名"函數(shù)，這個(gè)函數(shù)會(huì)將用戶的私有密鑰作為參數(shù)。因?yàn)橹挥杏脩舨胖浪接忻荑€，所以正確的簽名函數(shù)會(huì)說(shuō)明簽名者就是其所有者。

一旦計(jì)算出簽名，客戶端就將其附加在報(bào)文的末尾，并將報(bào)文和簽名都發(fā)送給對(duì)方。

在接收端，會(huì)用公開(kāi)密鑰對(duì)簽名進(jìn)行檢查，如果不匹配則表示已被篡改。

使用數(shù)字簽名的好處

簽名可以驗(yàn)證是作者編寫(xiě)了這條報(bào)文，只有作者才會(huì)有最機(jī)密的私有密鑰，因此，只有作者才能計(jì)算出這些校驗(yàn)和。校驗(yàn)和就像來(lái)自作者的個(gè)人“簽名”一樣。

簽名可以防止報(bào)文被篡改，如果有惡意攻擊者在報(bào)文傳輸過(guò)程中對(duì)其進(jìn)行了修改，校驗(yàn)和就不再匹配了。由于校驗(yàn)和只有作者保密的私有密鑰才能產(chǎn)生，所以攻擊者無(wú)法為篡改了的報(bào)文偽造出正確的校驗(yàn)碼。

數(shù)字證書(shū)中包含了由某個(gè)受信任組織擔(dān)保的用戶或公司的相關(guān)信息。數(shù)字證書(shū)都是由官方的"證書(shū)頒發(fā)機(jī)構(gòu)"以數(shù)字方式簽發(fā)的。
通過(guò)HTTPS建立了一個(gè)安全web事務(wù)之后，現(xiàn)代瀏覽器都會(huì)自動(dòng)獲取所連接服務(wù)器的數(shù)字證書(shū)。如果服務(wù)器沒(méi)有證書(shū)，安全連接就會(huì)失敗。瀏覽器收到證書(shū)的時(shí)候會(huì)對(duì)簽名頒發(fā)機(jī)構(gòu)進(jìn)行檢查。

HTTPS將HTTP協(xié)議與一組強(qiáng)大的對(duì)稱，非對(duì)稱和基于證書(shū)的加密技術(shù)結(jié)合在一起，使得HTTPS不僅很安全，而且很靈活，很容易在處于無(wú)序狀態(tài)的，分散的全球互聯(lián)網(wǎng)上進(jìn)行管理。

客戶端會(huì)對(duì)web資源執(zhí)行某事務(wù)時(shí)，他會(huì)去檢查URL的方案，如果URL的方案是https，客戶端就會(huì)打開(kāi)一條到服務(wù)器端口443(而不是傳統(tǒng)的http默認(rèn)的80端口)的連接，然后與服務(wù)器進(jìn)行SSL"握手"，以二進(jìn)制格式與服務(wù)器交換一些SSL安全參數(shù)，附加上加密的HTTP命令。

日期檢測(cè)

簽名頒發(fā)者可信度檢測(cè)

簽名檢測(cè)

站點(diǎn)身份檢測(cè)

客戶端通常會(huì)用web代理服務(wù)器代表它們來(lái)訪問(wèn)web服務(wù)器。但只要客戶端開(kāi)始用服務(wù)器的公開(kāi)密鑰對(duì)發(fā)往服務(wù)器的數(shù)據(jù)進(jìn)行加密，代理就再也不能讀取HTTP首部了！就無(wú)法知道應(yīng)該將請(qǐng)求轉(zhuǎn)向何處了。
為了使HTTPS與代理配合工作，可以用HTTPS SSL隧道協(xié)議。使用HTTPS隧道協(xié)議，客戶端首先告訴代理，它想要連接的安全主機(jī)和端口。這是在開(kāi)始加密之前，以明文形式告知的。