喜欢就 关注 我们吧！
概述 ：
Wo - 公号「八点半技术站」的创作者 - Bruce.D （姓氏：豆）。
今日主题：流量劫持、大家经常会看到公司的一些首页被插入一些小广告，这也就是流量劫持，今儿分享一下当前劫持的几个方法以及防劫持知识。
欢迎各位加入社群，技术交流不分语言、不分高低 。（本篇阅读预计花费：7分钟）
内容 ：
流量劫持划分成3大部分：DNS劫持、数据劫持、劫持监控。
DNS劫持：
首先聊聊这个，域名劫持是互联网一种攻击方式，通过攻击 DNS服务器 或者 伪造DNS 服务器方法，把目标服务器网站域名解析到错误地方，让用户无法正常访问真正的地址。
这里提问一个问题：那么 DNS是如何工作的呢？
客户端访问服务端的时候，首先要根据域名获取对应的IP地址，这一步要在 DNS服务器进行获取。请求DNS服务器的时候，需要通过UDP协议去寻找当地网络的运营商提供的公共域名服务器中查找IP。
如果没有找到，就会继续请求上级域名服务器进行处理，一直到返回IP为止。
域名劫持，即使是在请求 DNS解析域名时候出现的问题，目标域名被恶意解析到其他IP地址，造成用户无法正常使用服务。
为了减少 DNS 查询时间，HTTP协议栈中会缓存域名解析：
浏览器可能会缓存域名解析。
用户系统中的域名映射表（hosts）会缓存域名解析。
公共域名服务器通常由 ISP（互联网服务商）提供。
公共域名服务器会缓存上一级域名服务器的结果。
公共域名服务器 TTL 到期后，会向顶级域名服务器获取信息。
那么再提一个问题：如何污染 DNS？
常见的污染 DNS 方式有：
篡改 Hosts 文件；
污染中间链路设备（路由器等）；
修改 UDP内容，影响 DNS查询的结果；
入侵 DNS服务器（成本高）。
那么再提一个问题：如何抵御 DNS 劫持？
解决域名劫持的一个办法就是绕开安全性较差的 UDP协议，通过一个可信的源头来解析域名，解析方式不需要拘泥于 UDP协议，也可以通过 HTTP方式。
在 TLS 协议之上传输 DNS内容；
用 HTTP协议来传输 DNS；
用 HTTPS协议来传输 DNS；
使用自己维护的 DNS服务器（成本高）。
数据劫持：
接下来聊聊数据劫持，数据劫持最基本针对明文传输的内容发生。用户发起 HTTP请求，服务器返回页面时候，经过中间的运营商网络，页面内容的篡改或者内容加塞，强行插入弹窗或者广告。
那么问题又来了：如何抵御数据劫持？
目前行业内解决的办法是对内容进行 HTTPS加密，实现密文传输，彻底避免劫持问题。MD5校验同样能起到防止数据劫持的作用，MD5校验是指内容返回前，应用层对返回的数据进行校验，生成校验值。
同时内容接收方接收到内容后，也对内容进行校验，同样生成校验值，将这俩个校验值进行对比，倘若一致，则证明判断数据无劫持。
注意：HTTPS 也能被运营商劫持
1、伪造证书，通过病毒或者其他方式将伪造证书的根证书安装在用户系统中（较少）。
2、代理也有客户的证书与私钥，或者客户端与代理认证的时候不校验合法性，即可通过代理来与我们服务端进行数据交互（较多）。
下面说几款方法对数据劫持起到监控作用，但是并不能对劫持后的页面进行修复。
Content-Security-Policy (CSP)
实质就是白名单制度，开发者明确告诉客户端，哪些外部资源可以加载和执行，等同于提供白名单。它的实现和执行全部由浏览器完成，开发者只需提供配置。
指定每种资源类型可以加载执⾏的条件。
还可以防御 XSS 攻击。
也可以⽤于强迫资源使用 HTTPS 加载，降低劫持可能性。
两种方式开启 CSP：
// 通过 http 头信息
Content-Security-Policy: default-src https:
// 通过 meta 标签
<meta http-equiv="Content-Security-Policy" content="default-src https:" />
缺点:
由于 CSP 标识本身存在于 HTML 标签或者 HTTP 请求头中，可以被攻击者可以直接移除掉。
规则⽐较复杂。
影响动态创建脚本的使⽤。
Subresource Integrity (SRI)
将使用 base64 编码过后的文件哈希值写入你所引用的 <script> 或 <link> 标签的 integrity 属性值中即可启用子资源完整性功能。
如果校验不成功，则不会执行对应的 script 或 link 内容。
<script crossorigin="anonymous" integrity=“sha256-+Ec97...E=“ src=“https://a.com"></script>
缺点:
由于 SRI 标识 本身存在于 HTML 标签中，可以被攻击者可以直接移除掉。
影响动态创建脚本的使⽤。
校验失败时影响可⽤性。
兼容性有限，iOS Safari 不支持
劫持监控：
此方案参考了美团点评 2018 前端分享上的防治方案。
⽅案 A：在某些省份、地区⾃建监测站，定期抓取固定资源（资源太固定，监测站数量也远远不够）。
⽅案 B：业务⽅在⾃己的 HTML 中监听资源的 Error 事件（⽆法确认问题在于劫持，也可能只是普通的 JS 出错）。
⽅案 C：使⽤用第三⽅方企业服务进⾏监控（服务越多成本越⾼）。
⽅案 D：CSP、SRI（兼容性和灵活性差，⽆法进行⾃定义逻辑）。
上述方案可以看出，无论哪种方案，都有它的不足，于是搭建了下图的方案：
优势如下：
监控的级别是业务级甚至页面级，而不是某个固定的资源。
在业务方的 Node.js 中内置逻辑，给予了业务方自己进行降级和响应的能力。
监控层如果出现故障，不影响业务方的代码执行。
总结：
DNS 劫持是属于违法行为，已经在严厉打击，为了我们干净安全的上网浏览环境，我们也要做好一系列预防措施。
