HTTP的安全性問題

一般地，HTTP的報文在網絡中是明文傳輸的。WEB服務器或者瀏覽器組裝好HTTP數據包后，就直接遞交給了傳輸層（一般是基于TCP的）進行傳送。而通常情況下，我們的數據包不是直接傳送到目標主機的，中間會經過很多的轉發節點，比如寢室或家里的路由器，學校的網關路由器，運營商的路由器等。這中間的任何節點都可以截獲我們的數據包，查看甚至篡改里面的內容然后再進行轉發。

在這里，舉三個例子。

例1：Cookie竊取
我們都知道，HTTP協議是一個無狀態的協議，在不附帶其他額外信息的情況下，服務器是無法分辨前后兩次請求是否是來自同一用戶的。因此，需要一些輔助手段來記錄用戶的信息。Cookie就是其中之一（Cookie的作用就不在這里詳述了）。Cookie最常見的作用就是用來記錄用戶登錄的Session ID。
我們首先來回顧一下登錄的原理：

• 用戶填寫用戶名、密碼
• 發送登錄請求，此請求會帶上用戶填寫的用戶名、密碼，密碼通常會再瀏覽器端先進行加密再傳送
• 服務器接收到登錄請求數據包，取出用戶名、密碼進行驗證，驗證通過則在服務器端創建一個記錄用戶信息的Session，然后構造響應數據包，并且在HTTP頭里面增加一個Set-Cookie字段，把剛才創建的Session的ID放進去
• 瀏覽器接收到響應，并且把Set-Cookie頭中的Cookie信息保存到本地
• 以后瀏覽器再向該網站發起請求的時候，都會帶上本地存儲的Cookie信息；同樣，服務器接收到請求的時候，也首先去檢查請求頭的Cookie信息，如果Cookie里有Session ID并且該Session ID對應的Session在服務器端還存在且有效，則服務器允許用戶進行操作，否則將用戶重定向到登錄頁面。

如下圖所示，這是登錄之后瀏覽器存儲的Cookie，里面有一個Session ID。

Cookie-Session

也就是說，如果我們的Cookie信息在傳輸的過程中被竊取了，竊取者就可以登錄我們的賬號了。我們拿163郵箱的登錄舉個例子。

• 首先，登錄我們的163郵箱

  
  
  163郵箱登錄

• 然后，我們通過Chrome自帶的Network工具隨便獲取一個到main.163.com的請求，并取出其中的Cookie信息

  
  
  獲取Cookie信息
• 接下來打開另外一個瀏覽器，訪問 http://mail.163.com。如果你沒有在這個瀏覽器登錄過，這個時候是不會直接登錄的。打開瀏覽器開發工具的JS控制臺，輸入如下代碼，并且把剛才的獲取的Cookie粘貼到Prompt彈框里面。這個時候我們獲取的Cookie信息已經寫入了新瀏覽器。按照設想，此時我們應該可以復原該賬號的登錄了。
  
  寫入Cookie

• 重新載入頁面，果然，登錄進去了。

  
  
  復原登錄

所以，從例子1我們能看出來，當我們的Cookie信息被竊取，賬號就有可能被壞人登錄，然后做一些壞事_^。我們的QQ空間，人人賬號，BBS等都有可能通過這種方式被別人登錄，因為他們都是只基于HTTP的。所以，對于不信任的WIFI熱點，最好少連，連了也不要登錄這些只基于HTTP的社交賬號。當然了，這里只是舉了一個例子，能夠被竊取的還不僅僅是Cookie信息。由此可見，HTTP安全性問題一：數據有被竊取的危險。

例2: 運營商HTTP劫持
明文HTTP數據包除了可以被竊取之外，還有可能被篡改，而且通信的雙方都無法知道接收到的HTTP數據包是否被篡改過。
接下來，讓我們來看一個HTTP數據包被篡改的例子。
我們有時候在瀏覽手機網頁的時候，會發現頁面出了正常的內容之外，還多出了一些奇怪的東西，如下圖右下角的水泡。

HTTP劫持示意圖1

HTTP劫持示意圖2

HTTP劫持示意圖3

例3：中間人攻擊
中間人攻擊舉一個典型的公鑰私鑰加密通信的例子吧。
一般的場景是：A要與B進行通信，為了使通信內容保密，A會把自己的公鑰發給B，B也會把自己的公鑰發給A，然后A與B就可以進行加密通信了。但是，如果此時A與B中間有一個人C在竊聽A與B的通信，當A把公鑰發給B的時候，C把A的公鑰截獲下來并且把自己的公鑰發給B，當B把自己的公鑰發給A的時候，C把B的公鑰截獲下來并且把自己的公鑰發給A，這樣C就可以冒充A和B進行通信，也可以冒充B和A進行通信。A與B的通信內容對與C來說是毫無保密性可言的。
這中間的問題在于，當我拿到一個公鑰是，我無法知道我拿到的公鑰是不是我目標通信對象的。要解決這個問題，必須要有一種辦法，讓收到公鑰的人能夠確認公鑰的真實性。這就是后面會講到的證書的作用。