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来说是毫无保密性可言的。
这中间的问题在于，当我拿到一个公钥是，我无法知道我拿到的公钥是不是我目标通信对象的。要解决这个问题，必须要有一种办法，让收到公钥的人能够确认公钥的真实性。这就是后面会讲到的证书的作用。