一、DNS劫持和HTTP劫持
DNS劫持表象：你輸入一個google.com網址，出來的是百度的頁面.
HTTP劫持表象：訪問着github的頁面，右下角出現了一個格格不入的廣告彈窗.
如何判斷所用的dns 有沒有受到劫持，最簡單的測試辦法：用nslookup 去查詢一個不存在的域名，如果返回一個IP，通過瀏覽打開這個IP會發現是一個廣告頁，那麼這個DNS 已經被劫持了，如果返回** server can't find wwwsfsefse.com: NXDOMAIN 則未被劫持。
二、DNS解析
例：
未被劫持的DNS：
[root@mail ~]# nslookup serwr3rsf.com 61.235.70.98
Server: 61.235.70.98
Address: 61.235.70.98#53
** server can't find serwr3rsf.com: NXDOMAIN
已經被劫持的DNS：
# nslookup sfsef333sf.com 202.96.128.86
Server: 202.96.128.86
Address: 202.96.128.86#53
Non-authoritative answer:
Name: sfsef333sf.com
Address: 61.140.3.66
[root@localhost ~]# yum install caching-nameserver
[root@localhost ~]# chkconfig named on
[root@localhost ~]# service named start
Starting named: [ OK ]
編輯/etc/resolv.conf，改爲下面的內容：
nameserver 127.0.0.1
測試：
[root@localhost ~]# nslookup www.google.com
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
www.google.com canonical name = www.l.google.com.
Name: www.l.google.com
Address: 64.233.189.99
Name: www.l.google.com
Address: 64.233.189.103
Name: www.l.google.com
Address: 64.233.189.104
Name: www.l.google.com
Address: 64.233.189.147
[root@localhost ~]# nslookup sefsf2sfef.com
Server: 127.0.0.1
Address: 127.0.0.1#53
** server can't find sefsf2sfef.com: NXDOMAIN
測試成功！
一般來說DNS劫持有這三種情況：
1.錯誤域名解析到糾錯導航頁面，導航頁面存在廣告。判斷方法:訪問的域名是錯誤的，而且跳轉的導航頁面也是官方的，如電信的114，聯通移網域名糾錯導航頁面。
2.錯誤域名解析到非正常頁面，對錯誤的域名解析到導航頁的基礎上，有一定機率解析到一些惡意站點，這些惡意站點通過判斷你訪問的目標HOST、URI、 referrer等來確定是否跳轉廣告頁面，這種情況就有可能導致跳轉廣告頁面（域名輸錯）或者訪問頁面被加廣告（頁面加載時有些元素的域名錯誤而觸發）這種劫持會對用戶訪問的目標HOST、URI、 referrer等會進行判定來確定是否解析惡意站點地址，不易被發現。
3.直接將特點站點解析到惡意或者廣告頁面，這種情況比較惡劣，而且出現這種情況未必就是運營商所爲，家裏路由器被黑，或者系統被入侵，甚至運營商的某些節點被第三方惡意控制都有可能。具體情況要具體分析，這裏就不展開了。
DNS劫持常見於使用自動的DNS地址，所以，不管有沒有被劫持，儘量不要使用運營商默認的DNS。
三、http劫持
HTTP劫持：你DNS解析的域名的IP地址不變。在和網站交互過程中的劫持了你的請求。在網站發給你信息前就給你返回了請求。
HTTP劫持很好判斷，當年正常訪問一個無廣告的頁面時，頁面上出現廣告彈窗，八成就是運營商劫持了HTTP。
1、HTTP劫持怎麼做到的呢？
一般來說 HTTP劫持主要通過下面幾個步驟來做：
1.1 標識HTTP連接。在天上飛的很多連接中，有許多種協議，第一步做的就是在TCP連接中，找出應用層採用了HTTP協議的連接，進行標識。
1.2篡改HTTP響應體，可以通過網關來獲取數據包進行內容的篡改。
1.3搶先回包，將篡改後的數據包搶先正常站點返回的數據包先到達用戶側，這樣後面正常的數據包在到達之後會被直接丟棄。
2、HTTP劫持的手段有哪些？
一般通用的方法都是插入靜態腳本或者是HTML Content，或者是將整體替換成Iframe，然後再在頂層的Iframe上進行內容的植入
3、如何防範HTTP劫持？
根據對抗HTTP劫持的時機來分類，可以主要分爲三類：
- 事前加密
- 事中規避
- 事後屏蔽
3.1 事前加密
HTTPS
很大一部分HTTP劫持，主要的原因就是在傳輸數據時都是明文的，使用了HTTPS後，會在HTTP協議之上加上TLS進行保護，使得傳輸的數據進行加密，但是使用HTTPS，一定要注意規範，必須要全站使用HTTPS，否則只要有一個地方沒有使用HTTPS，明文傳輸就很有可能會被HTTP劫持了
但是相應的，全部使用HTTPS，也會帶來一些問題：
- 性能可能有所降低，因爲多了TLS握手所帶來的2次RTT延時（但是基於HTTPS之上的HTTP2可以更有效的提升性能）
- 由於運營商可能會使用DNS劫持，在DNS劫持之下，HTTPS的服務完全用不了了，所以會導致白屏
加密代理
加密代理的原理就是在用戶側和目標web服務器之間增加一個代理服務器，在用戶和代理之間會經過運營商的節點，這裏使用各種加密手段保證安全，在代理服務器與web服務之間使用HTTP請求，只需確認代理與web服務之間不會被HTTP劫持就可以避開HTTP劫持
3.2 事中加密
拆分HTTP請求數據包
在HTTP劫持的步驟中，第一步是標記TCP連接，因此只要躲過了標識，那麼後續的運營商篡改就不會存在了，有一種方式就是拆分HTTP請求
拆分數據包就是把HTTP請求的數據包拆分成多個，運營商的旁路設備由於沒有完整的TCP/IP協議棧，所以就不會被標誌，而目標web服務器是有完整的TCP/IP協議棧，能接收到的數據包拼成完整的HTTP請求，不影響服務.
3.3 事後屏蔽
通過瀏覽器Api，根據若干規則去匹配DOM中的節點，對匹配到的節點作攔截和隱藏
CSP（內容安全策略），DOM事件監聽等。
CSP是瀏覽器附加的一層安全層，用於對抗跨站腳本與數據注入，運營商植入內容性質與數據注入類似，因此，可以用CSP對抗運營商劫持。通過在HTTP響應頭或meta標籤設置好規則，支持攔截和上報劫持信息的功能。
DOM事件監聽主要是監聽DOMNodeInserted、DOMContentLoaded、DOMAttrModified等事件，可以在前端DOM結構發生變化時觸發回調，這時補充一些檢測邏輯，即可判斷是不是業務的正常UI邏輯，如果不是，即可認爲是來自劫持.