HTTP的安全性問題
一般地晰洒，HTTP的報(bào)文在網(wǎng)絡(luò)中是明文傳輸?shù)睦俣睢EB服務(wù)器或者瀏覽器組裝好HTTP數(shù)據(jù)包后野建，就直接遞交給了傳輸層（一般是基于TCP的）進(jìn)行傳送。而通常情況下确买，我們的數(shù)據(jù)包不是直接傳送到目標(biāo)主機(jī)的斤讥，中間會經(jīng)過很多的轉(zhuǎn)發(fā)節(jié)點(diǎn)，比如寢室或家里的路由器湾趾，學(xué)校的網(wǎng)關(guān)路由器芭商，運(yùn)營商的路由器等。這中間的任何節(jié)點(diǎn)都可以截獲我們的數(shù)據(jù)包撑帖，查看甚至篡改里面的內(nèi)容然后再進(jìn)行轉(zhuǎn)發(fā)。
在這里澳眷，舉三個例子胡嘿。
例1：Cookie竊取
我們都知道，HTTP協(xié)議是一個無狀態(tài)的協(xié)議钳踊，在不附帶其他額外信息的情況下衷敌，服務(wù)器是無法分辨前后兩次請求是否是來自同一用戶的。因此拓瞪，需要一些輔助手段來記錄用戶的信息缴罗。Cookie就是其中之一（Cookie的作用就不在這里詳述了）。Cookie最常見的作用就是用來記錄用戶登錄的Session ID祭埂。
我們首先來回顧一下登錄的原理：
- 用戶填寫用戶名面氓、密碼
- 發(fā)送登錄請求，此請求會帶上用戶填寫的用戶名蛆橡、密碼舌界，密碼通常會再瀏覽器端先進(jìn)行加密再傳送
- 服務(wù)器接收到登錄請求數(shù)據(jù)包，取出用戶名泰演、密碼進(jìn)行驗(yàn)證呻拌，驗(yàn)證通過則在服務(wù)器端創(chuàng)建一個記錄用戶信息的Session，然后構(gòu)造響應(yīng)數(shù)據(jù)包睦焕，并且在HTTP頭里面增加一個Set-Cookie字段藐握，把剛才創(chuàng)建的Session的ID放進(jìn)去
- 瀏覽器接收到響應(yīng)靴拱，并且把Set-Cookie頭中的Cookie信息保存到本地
- 以后瀏覽器再向該網(wǎng)站發(fā)起請求的時候，都會帶上本地存儲的Cookie信息猾普；同樣袜炕，服務(wù)器接收到請求的時候，也首先去檢查請求頭的Cookie信息抬闷，如果Cookie里有Session ID并且該Session ID對應(yīng)的Session在服務(wù)器端還存在且有效妇蛀，則服務(wù)器允許用戶進(jìn)行操作，否則將用戶重定向到登錄頁面笤成。
如下圖所示评架，這是登錄之后瀏覽器存儲的Cookie，里面有一個Session ID炕泳。
也就是說纵诞，如果我們的Cookie信息在傳輸?shù)倪^程中被竊取了，竊取者就可以登錄我們的賬號了培遵。我們拿163郵箱的登錄舉個例子浙芙。
-
首先，登錄我們的163郵箱
163郵箱登錄 -
然后籽腕，我們通過Chrome自帶的Network工具隨便獲取一個到main.163.com的請求嗡呼，并取出其中的Cookie信息
獲取Cookie信息 - 接下來打開另外一個瀏覽器，訪問 http://mail.163.com皇耗。如果你沒有在這個瀏覽器登錄過南窗，這個時候是不會直接登錄的。打開瀏覽器開發(fā)工具的JS控制臺郎楼，輸入如下代碼万伤，并且把剛才的獲取的Cookie粘貼到Prompt彈框里面。這個時候我們獲取的Cookie信息已經(jīng)寫入了新瀏覽器呜袁。按照設(shè)想敌买，此時我們應(yīng)該可以復(fù)原該賬號的登錄了。
寫入Cookie -
重新載入頁面阶界，果然虹钮，登錄進(jìn)去了。
復(fù)原登錄
所以膘融，從例子1我們能看出來芜抒，當(dāng)我們的Cookie信息被竊取，賬號就有可能被壞人登錄托启，然后做一些壞事^宅倒。我們的QQ空間，人人賬號，BBS等都有可能通過這種方式被別人登錄拐迁，因?yàn)樗麄兌际侵换贖TTP的蹭劈。所以，對于不信任的WIFI熱點(diǎn)线召，最好少連铺韧，連了也不要登錄這些只基于HTTP的社交賬號。當(dāng)然了缓淹，這里只是舉了一個例子哈打，能夠被竊取的還不僅僅是Cookie信息。由此可見讯壶，HTTP安全性問題一：數(shù)據(jù)有被竊取的危險(xiǎn)料仗。
例2: 運(yùn)營商HTTP劫持
明文HTTP數(shù)據(jù)包除了可以被竊取之外，還有可能被篡改伏蚊，而且通信的雙方都無法知道接收到的HTTP數(shù)據(jù)包是否被篡改過立轧。
接下來，讓我們來看一個HTTP數(shù)據(jù)包被篡改的例子躏吊。
我們有時候在瀏覽手機(jī)網(wǎng)頁的時候氛改，會發(fā)現(xiàn)頁面出了正常的內(nèi)容之外，還多出了一些奇怪的東西比伏，如下圖右下角的水泡胜卤。
點(diǎn)開一看，卻是運(yùn)營商充話費(fèi)赁项、充流量的一個導(dǎo)購頁面葛躏。
當(dāng)我通過電腦訪問，或者手機(jī)從數(shù)據(jù)切換到WIFI環(huán)境再訪問時肤舞，頁面上的水泡就消失了紫新。這說明均蜜，頁面上的這個水泡是運(yùn)營商做的手腳李剖。通過對比發(fā)現(xiàn)，在使用運(yùn)營商網(wǎng)絡(luò)訪問網(wǎng)頁時囤耳，獲取到的頁面被插入了一段JS篙顺。而這段JS的作用就是生成那個水泡和運(yùn)營商的導(dǎo)購頁面。
這說明充择，我們的響應(yīng)HTTP數(shù)據(jù)包在返回的時候被運(yùn)營商截獲并且修改了德玫。雖然這一行為很無恥，但是用戶和WEB服務(wù)提供者對此都無能為力椎麦。
例3：中間人攻擊
中間人攻擊舉一個典型的公鑰私鑰加密通信的例子吧宰僧。
一般的場景是：A要與B進(jìn)行通信，為了使通信內(nèi)容保密观挎，A會把自己的公鑰發(fā)給B琴儿，B也會把自己的公鑰發(fā)給A段化，然后A與B就可以進(jìn)行加密通信了。但是造成，如果此時A與B中間有一個人C在竊聽A與B的通信显熏，當(dāng)A把公鑰發(fā)給B的時候，C把A的公鑰截獲下來并且把自己的公鑰發(fā)給B晒屎，當(dāng)B把自己的公鑰發(fā)給A的時候喘蟆，C把B的公鑰截獲下來并且把自己的公鑰發(fā)給A，這樣C就可以冒充A和B進(jìn)行通信鼓鲁，也可以冒充B和A進(jìn)行通信蕴轨。A與B的通信內(nèi)容對與C來說是毫無保密性可言的。
這中間的問題在于坐桩，當(dāng)我拿到一個公鑰是尺棋，我無法知道我拿到的公鑰是不是我目標(biāo)通信對象的。要解決這個問題绵跷，必須要有一種辦法膘螟，讓收到公鑰的人能夠確認(rèn)公鑰的真實(shí)性。這就是后面會講到的證書的作用碾局。
