https劫持

953 阅读2分钟

        https虽然已经很好的解决了http通信过程中的三大问题。在深入了解https中已经讲过,感兴趣的可以去了解。但是https也不是完全不可以被劫持的。在一些不当的操作后仍然会被劫持。

        在介绍劫持前先介绍一下浏览器对于不信任证书的一些提示。如果数字证书记载的网址与正在浏览的网址不一致,说明这个证书被替换或者冒用,浏览器会提示告警。如果这个证书在链式信任过程中并不能最终被信任说明该证书不是授信机构颁发的,浏览器也会发出警告。还有一种HSTS情况的提示后边在介绍。

       中间人劫持

         中间人劫持的思路如下图,相当于中间人劫持住了客户端的握手请求,然后由中间人向服务器发送握手请求,在server hello 阶段替换响应体中的证书。但是中间人证书由于没有对服务器域名的申请权限,所以也没法申请服务器域名的证书,所以中间人证书的URL信息是错误的。当中间人将该证书返回给客户端后,客户端会发出前边提到的信任警告。如果用户点击继续访问那么后边的通信将被中间人劫持。这也是charles这样的抓包工具使用的方式。

         

       SSLstrip

         SSLStrip 的思路是通过ARP攻击的方式对客户的https的请求强制转换成http请求。这样客户端与中间人的所有通信都是明文通信,就可以拿到客户的提交信息等内容。接下来就是如何将https转换http了。可以通过xss code对js location对像进行替换,来处理可能存在的前端对URL的check。再将所有script标签中的https和脚本中的https替换成为http。就可以很好的劫持https。

        

       解决方案

       可以使用HSTS来解决问题。可以在响应头中增加Strict-Transport-Security:

max-age=172800字段来设定请求必须是用https。如果没有使用也会提示HSTS告警。

      但是在https的响应头中增加,如果第一次被拦截了也会被替换掉,导致浏览器无法正确处理。

      可以通过HSTS preload list方案,该方案是将申请了hsts的域名硬编码到浏览器中。这样就解决SSLStrip的问题。

     **注意:**在HSTS被开启后想要关闭它就很复杂,所以慎重开启。