年終前端安全防禦規範總結

時間 2019-12-18

原文原文鏈接

背景與意義

建了一個「全棧大前端」的微信交流羣，歡迎純粹技術交流愛好者加入！（入羣加微信mokinzhao）

隨着互聯網的發展，各類 Web 應用變得愈來愈複雜，知足了用戶的各類需求的同時，各類網絡安全問題也接踵而至，前端

QQ 郵箱、新浪微博、YouTube、WordPress 和百度等知名網站都曾遭遇攻擊，若是你從未有過安全方面的問題，不是由於你所開發的網站很安全，更大的多是你的網站的流量很是低或者沒有攻擊的價值。要想做爲一個優秀的前端工程師對安全防禦知識的瞭解和掌握是必不可少的。git

常見的安全漏洞

1.XSS 跨站腳本攻擊

XSS(Cross-Site Scripting，跨站腳本攻擊)是一種代碼注入攻擊。攻擊者在目標網站上注入惡意代碼，當被攻擊者登錄網站時就會執行這些惡意代碼，這些腳本能夠讀取 cookie，session tokens，或者其它敏感的網站信息，對用戶進行釣魚欺詐，甚至發起蠕蟲攻擊等。github

XSS 的本質是：惡意代碼未通過濾，與網站正常的代碼混在一塊兒；瀏覽器沒法分辨哪些腳本是可信的，致使惡意腳本被執行。因爲直接在用戶的終端執行，惡意代碼可以直接獲取用戶的信息，利用這些信息冒充用戶向網站發起攻擊者定義的請求。web

XSS 分類

1.反射型 XSS(非持久)

當用戶點擊一個惡意連接，或者提交一個表單，或者進入一個惡意網站時，注入腳本進入被攻擊者的網站。Web服務器將注入腳本，好比一個錯誤信息，搜索結果等，未進行過濾直接返回到用戶的瀏覽器上。算法

反射型 XSS 的攻擊步驟：shell

攻擊者構造出特殊的 URL，其中包含惡意代碼。
用戶打開帶有惡意代碼的 URL 時，網站服務端將惡意代碼從 URL 中取出，拼接在 HTML 中返回給瀏覽器。
用戶瀏覽器接收到響應後解析執行，混在其中的惡意代碼也被執行。
惡意代碼竊取用戶數據併發送到攻擊者的網站，或者冒充用戶的行爲，調用目標網站接口執行攻擊者指定的操做。

反射型 XSS 漏洞常見於經過 URL 傳遞參數的功能，如網站搜索、跳轉等。因爲須要用戶主動打開惡意的 URL 才能生效，攻擊者每每會結合多種手段誘導用戶點擊。數據庫

POST 的內容也能夠觸發反射型 XSS，只不過其觸發條件比較苛刻（須要構造表單提交頁面，並引導用戶點擊），因此很是少見。後端

查看反射型攻擊示例跨域

請戳： github.com/YvetteLau/B…瀏覽器

根據 README.md 的提示進行操做(真實狀況下是須要誘導用戶點擊的，上述代碼僅是用做演示)。

注意 Chrome 和 Safari 可以檢測到 url 上的xss攻擊，將網頁攔截掉，可是其它瀏覽器不行，如 Firefox

若是不但願被前端拿到cookie，後端能夠設置 httpOnly (不過這不是 XSS攻擊的解決方案，只能下降受損範圍)

如何防範反射型XSS攻擊

對字符串進行編碼。

對url的查詢參數進行轉義後再輸出到頁面。

app.get('/welcome', function(req, res) {
   //對查詢參數進行編碼，避免反射型 XSS攻擊
    res.send(`${encodeURIComponent(req.query.type)}`); 
});
複製代碼

2.存儲型 XSS(持久)

DOM 型 XSS 攻擊，實際上就是前端 JavaScript 代碼不夠嚴謹，把不可信的內容插入到了頁面。在使用 .innerHTML、 .outerHTML、 .appendChild、 document.write()等API時要特別當心，不要把不可信的數據做爲 HTML 插到頁面上，儘可能使用 .innerText、 .textContent、 .setAttribute() 等。

DOM 型 XSS 的攻擊步驟：

攻擊者構造出特殊數據，其中包含惡意代碼。
用戶瀏覽器執行了惡意代碼。
惡意代碼竊取用戶數據併發送到攻擊者的網站，或者冒充用戶的行爲，調用目標網站接口執行攻擊者指定的操做。

如何防範 DOM 型 XSS 攻擊

防範 DOM 型 XSS 攻擊的核心就是對輸入內容進行轉義(DOM 中的內聯事件監聽器和連接跳轉都能把字符串做爲代碼運行，須要對其內容進行檢查)。

1.對於 url連接(例如圖片的 src屬性)，那麼直接使用 encodeURIComponent 來轉義。

2.非 url，咱們能夠這樣進行編碼：

function encodeHtml(str){
    return str.relpace(/"/g,'&quot;') .replace(/'/g,'&apos;') .replace(/</g,'&lt;') .relpace(/>/g,'&gt;') } 複製代碼

DOM 型 XSS 攻擊中，取出和執行惡意代碼由瀏覽器端完成，屬於前端 JavaScript 自身的安全漏洞。

查看DOM型XSS攻擊示例(根據readme提示查看)

請戳： github.com/YvetteLau/B…

3.Dom 型 XSS

惡意腳本永久存儲在目標服務器上。當瀏覽器請求數據時，腳本從服務器傳回並執行，影響範圍比反射型和DOM型XSS更大。存儲型XSS攻擊的緣由仍然是沒有作好數據過濾：前端提交數據至服務端時，沒有作好過濾；服務端在接受到數據時，在存儲以前，沒有作過濾；前端從服務端請求到數據，沒有過濾輸出。

存儲型 XSS 的攻擊步驟：

攻擊者將惡意代碼提交到目標網站的數據庫中。
用戶打開目標網站時，網站服務端將惡意代碼從數據庫取出，拼接在 HTML 中返回給瀏覽器。
用戶瀏覽器接收到響應後解析執行，混在其中的惡意代碼也被執行。
惡意代碼竊取用戶數據併發送到攻擊者的網站，或者冒充用戶的行爲，調用目標網站接口執行攻擊者指定的操做。

這種攻擊常見於帶有用戶保存數據的網站功能，如論壇發帖、商品評論、用戶私信等。

如何防範存儲型XSS攻擊：

前端數據傳遞給服務器以前，先轉義/過濾(防範不了抓包修改數據的狀況)
服務器接收到數據，在存儲到數據庫以前，進行轉義/過濾
前端接收到服務器傳遞過來的數據，在展現到頁面前，先進行轉義/過濾

查看存儲型XSS攻擊示例(根據Readme提示查看)

請戳： github.com/YvetteLau/B…

除了謹慎的轉義，咱們還須要其餘一些手段來防範XSS攻擊:

1.Content Security Policy

在服務端使用 HTTP的 Content-Security-Policy 頭部來指定策略，或者在前端設置 meta 標籤。

例以下面的配置只容許加載同域下的資源：

Content-Security-Policy: default-src 'self'
<meta http-equiv="Content-Security-Policy" content="form-action 'self';">
複製代碼

前端和服務端設置 CSP 的效果相同，可是 meta沒法使用 report

更多的設置能夠查看 Content-Security-Policy

嚴格的 CSP 在 XSS 的防範中能夠起到如下的做用：

禁止加載外域代碼，防止複雜的攻擊邏輯。
禁止外域提交，網站被攻擊後，用戶的數據不會泄露到外域。
禁止內聯腳本執行（規則較嚴格，目前發現 GitHub 使用）。
禁止未受權的腳本執行（新特性，Google Map 移動版在使用）。
合理使用上報能夠及時發現 XSS，利於儘快修復問題。

2.輸入內容長度控制

對於不受信任的輸入，都應該限定一個合理的長度。雖然沒法徹底防止 XSS 發生，但能夠增長 XSS 攻擊的難度。

3.輸入內容限制

對於部分輸入，能夠限定不能包含特殊字符或者僅能輸入數字等。

4.其餘安全措施

HTTP-only Cookie: 禁止 JavaScript 讀取某些敏感 Cookie，攻擊者完成 XSS 注入後也沒法竊取此 Cookie。
驗證碼：防止腳本冒充用戶提交危險操做。

2.CSRF 跨站請求僞造

CSRF（Cross-site request forgery）跨站請求僞造：攻擊者誘導受害者進入第三方網站，在第三方網站中，向被攻擊網站發送跨站請求。利用受害者在被攻擊網站已經獲取的註冊憑證，繞事後臺的用戶驗證，達到冒充用戶對被攻擊的網站執行某項操做的目的。

典型的 CSRF 攻擊流程

受害者登陸 A 站點，並保留了登陸憑證（Cookie）。
攻擊者誘導受害者訪問了站點 B。
站點 B 向站點 A 發送了一個請求，瀏覽器會默認攜帶站點 A 的 Cookie 信息。
站點 A 接收到請求後，對請求進行驗證，並確認是受害者的憑證，誤覺得是無辜的受害者發送的請求。
站點 A 以受害者的名義執行了站點 B 的請求。
攻擊完成，攻擊者在受害者不知情的狀況下，冒充受害者完成了攻擊。

CSRF 的特色

1.攻擊一般在第三方網站發起，如圖上的站點 B，站點 A 沒法防止攻擊發生。

2.攻擊利用受害者在被攻擊網站的登陸憑證，冒充受害者提交操做；並不會去獲取 cookie 信息(cookie 有同源策略)

3.跨站請求能夠用各類方式：圖片 URL、超連接、CORS、Form 提交等等(來源不明的連接，不要點擊)

防護手段

添加驗證碼(體驗很差)
判斷請求的來源：檢測 Referer(並不安全，Referer 能夠被更改)
使用 Token(主流)
Samesite Cookie 屬性

3.點擊劫持

點擊劫持是指在一個 Web 頁面中隱藏了一個透明的 iframe，用外層假頁面誘導用戶點擊，其實是在隱藏的 frame 上觸發了點擊事件進行一些用戶不知情的操做。

典型點擊劫持攻擊流程

攻擊者構建了一個很是有吸引力的網頁【不知道哪些內容對大家來講有吸引力，我就不寫頁面了，偷個懶】
將被攻擊的頁面放置在當前頁面的 iframe 中
使用樣式將 iframe 疊加到很是有吸引力內容的上方
將 iframe 設置爲 100%透明
你被誘導點擊了網頁內容，你覺得你點擊的是*，而實際上，你成功被攻擊了。

防護手段

1. frame busting

 ( top.location != window.location ){
    top.location = window.location
}
複製代碼

須要注意的是: HTML5 中 iframe 的 sandbox 屬性、IE 中 iframe 的 security 屬性等，均可以限制 iframe 頁面中的 JavaScript 腳本執行，從而可使得 frame busting 失效。

2. X-Frame-Options

X-FRAME-OPTIONS 是微軟提出的一個 http 頭，專門用來防護利用 iframe 嵌套的點擊劫持攻擊。而且在 IE八、Firefox3.六、Chrome4 以上的版本均能很好的支持。

能夠設置爲如下值:

DENY: 拒絕任何域加載
SAMEORIGIN: 容許同源域下加載
ALLOW-FROM: 能夠定義容許 frame 加載的頁面地址

4.SQL 注入

一、簡介：

用戶能夠提交一段數據庫查詢代碼，根據程序返回的結果，得到某些他想得知的數據。

2.漏洞危害：

可致使數據庫被拖
重要信息泄露
上傳webshell
執行系統命令，進而控制服務器

之因此會發生SQL注入，主要由於代碼中存在拼接SQL語句的狀況。好比：

* SELECT field FROM tableName WHERE ( name = " + name + " )

這個查詢使用參數name拼接了一條SELECT語句。

3.防範：

要堵住這個漏洞，關鍵是保證參數name的值必須合法有效。

解決方案：在實際拼接SQL語句以前，要對name進行合法性驗證，經過驗證後再去拼接。

5.本地數據竊取

** 原理：**

直接打開chrom 瀏覽器 appction 修改讀取 cookie 、localStorage、sessionStorage

防範：

數據加密、脫敏處理，不保存敏感數據在storage裏

6.文件上傳

一、簡介：

用戶上傳一個可執行的腳本文件，並經過此腳本文件得到了執行服務端命令的能力。

二、分類：

1）文件名攻擊：上傳的文件採用上傳以前的文件名,可能形成客戶端和服務端字符碼不兼容,致使文件名亂碼問題;文件名包含腳本,從而形成攻擊.

2）文件後綴攻擊：上傳的文件的後綴多是exe可執行程序,js腳本等文件,這些程序可能被執行於受害者的客戶端,甚至可能執行於服務器上.所以咱們必須過濾文件名後綴,排除那些不被許可的文件名後綴.

3）文件內容攻擊：IE6有一個很嚴重的問題 , 它不信任服務器所發送的content type，而是自動根據文件內容來識別文件的類型，並根據所識別的類型來顯示或執行文件.若是上傳一個gif文件,在文件末尾放一段js攻擊腳本,就有可能被執行.這種攻擊,它的文件名和content type看起來都是合法的gif圖片,然而其內容卻包含腳本,這樣的攻擊沒法用文件名過濾來排除，而是必須掃描其文件內容，才能識別。

三、防護措施：

1）文件上傳的目錄設置爲不可執行。

2）判斷文件類型。在判斷文件類型的時候，能夠結合使用MIME Type，後綴檢查等方式。由於對於上傳文件，不能簡單地經過後綴名稱來判斷文件的類型，由於攻擊者能夠將可執行文件的後綴名稱改成圖片或其餘後綴類型，誘導用戶執行。

3）對上傳的文件類型進行白名單校驗，只容許上傳可靠類型。

4）上傳的文件須要進行從新命名，使攻擊者沒法猜測上傳文件的訪問路徑，將極大地增長攻擊成本。

5）限制上傳文件的大小。

6）單獨設置文件服務器的域名。

7.CDN 劫持

出於性能考慮，前端應用一般會把一些靜態資源存放到CDN（Content Delivery Networks）上面，例如 js 腳本和 style 文件。這麼作能夠顯著提升前端應用的訪問速度，但與此同時卻也隱含了一個新的安全風險。若是攻擊者劫持了CDN，或者對CDN中的資源進行了污染，攻擊者能夠肆意篡改咱們的前端頁面，對用戶實施攻擊。如今的CDN以支持SRI爲榮，script 和 link 標籤有了新的屬性 integrity，這個屬性是爲了防止校驗資源完整性來判斷是否被篡改。它經過驗證獲取文件的哈希值是否和你提供的哈希值同樣來判斷資源是否被篡改。使用 SRI 須要兩個條件：一是要保證資源同域或開啓跨域，二是在script中提供簽名以供校驗。