淺析前端安全之 XSS

本文是我在掘金技術社區主辦的 JTalk 線下活動《前端安全大起底 | 美團技術團隊專場》 活動上的分享整理。本篇文章想講講 XSS 的產生和防禦，主要面向前端安全了解不多的同學。首先，就不直接照搬 XSS 的定義，我想通過下面一個實例來講講 XSS 攻擊如何進行的，希望會讓對前端安全了解不多的同學更容易理解。

從一個實例講起

這裡我準備了一個web im demo，在這個 IM 里實現了文字，鏈接，頭像等功能

但是在實現這些功能背後，隱藏了嚴重的安全問題，接下來，我們來看看這個 bug 是怎麼樣的，先來看看。可以看到這 IM 支持圖片，文字交流，如果我輸入一個圖片的 html 標籤字元，對方就能收到圖片。可是，如果輸入的是這樣的的 html 標籤字元，就會有意料之外的效果：

在看到對方的窗口調用了alert，並且內容中是自己的 cookie 信息，這通常意味著我們的 cookie 中的用戶認證憑據被盜取了。當然，這裡使用 alert 是為了展示腳本的執行能力，通常情況，黑客一旦通過確認某處存在漏洞，那之後利用這個漏洞的所能做的事情就很多了。

看到消息氣泡模板，找到問題所在了，這裡使用了 v-html 但是卻沒有做任何安全處理。對於具體安全的處理方式，我們在後面細說。

剛才通過這個簡單的 Case，簡單介紹了 XSS 的產生和利用。在常規分類中，XSS 共分為這三種：

存儲型

反射型

DOM based

我認為，前端應用的複雜度不斷提升的今天，這三個分類可能有不少融合的場景。

XSS 的風險

會話劫持

將 cookie 或 token 等類似令牌數據上報給黑客，黑客就能以受害用戶的許可權進行操作

信息泄露

個人隱私泄露

商業機密泄露

進一步的攻擊

運行惡意腳本的用戶瀏覽器可能被操控繼續攻擊其他目標

有黑客利用 XSS 嗅探內網服務，然後發起下一步的攻擊

如何防禦 XSS

轉義

網頁由HTML組成，通常在模板文件中描述，並在頁面呈現時嵌入動態內容。存儲的XSS攻擊利用對來自後端數據存儲的動態內容的不當處理。攻擊者通過插入一些JavaScript代碼來濫用可編輯欄位，當另一用戶訪問該頁面時，該代碼將在瀏覽器中執行。

{{ title }}

下面是從https://dev.w3.org/html5/html-author/charref截取的一部分字元和轉義編碼的表：

說到轉義，我們從實際場景出發，來看看我們在 nodejs 中常用的幾個模板引擎的實際用例，左邊上部分是 ejs ，在 ejs 中是輸出轉義結果，是不進行轉義。下面的雖然語法不一樣，都一樣提供了轉義和不轉義的功能。所以在絕大多數場景，請使用轉義輸出。

內容白名單

內容白名單，是一個比較寬泛的概念。比如，接著說剛才的富文本的需求，那麼我們的內容白名單其實就是 HTML 標籤、屬性等的一個白名單。比如常規文章、評論富文本，肯定是不需要標籤的。要去除內容中具有隱患的 script 標籤，最簡單的方案肯定是替換掉 script 的黑名單策略，但是黑名單意味著未知的風險。剛才說道不推薦是用黑名單對某些關鍵詞進行過濾。就像這裡的這個例子，我如果使用風險關鍵詞替換來實現安全過濾。這裡我實現的是將所有的替換為空字元。左邊的場景能夠攔截清除了輸入的, 但右邊的場景遇到，就不能適用了。

比如常見的富文本場景中，推薦對標籤內容進行白名單（標籤、屬性等）過濾。比如這裡是一個使用 xss 的庫對 HTML 做白名單過濾的簡單示例：

constxss=require("xss")

constoptions={

whiteList:{

a:["href","title","target"],

p:[],

span:[],

h1:[]

}

}

constmyxss=newxss.FilterXSS(options);

constresult=myxss.process("")

Content Security Policy

內容安全性政策 (CSP) 是一個可顯著降低現代瀏覽器中 XSS 攻擊的風險和影響的防護功能。 它允許網頁的作者控制可以從哪裡載入和執行JavaScript（和其他資源）。XSS攻擊依賴於攻擊者能夠在用戶的網頁上運行惡意腳本 - 通過在頁面標記內的某處插入內聯標記，或者通過誘騙瀏覽器從惡意第三方域載入JavaScript。 通過在響應頭中設置內容安全策略，您可以告訴瀏覽器永遠不會執行內嵌 JavaScript，並鎖定哪些域名可以為頁面託管 JavaScript使用方式

meta

header

Content-Security-Policy: default-src "none"; script-src "self" ssl.google-analytics.com;

https://content-security-policy.com/CSP 提供了很多指令用來約束不同資源的來源，比如這裡我列舉了一部分。除了資源來源的指令還有幾個特殊的指令，比如 report-uri 可以用於指定一個違反 csp 一些異常情況上報地址，讓開發者能夠了解到在瀏覽器的異常情況。

block-all-mixed-content：HTTPS 網頁不得載入 HTTP 資源（瀏覽器已經默認開啟）

upgrade-insecure-requests：自動將網頁上所有載入外部資源的 HTTP 鏈接換成 HTTPS 協議

plugin-types：限制可以使用的插件格式，比如禁用 flash, java applet

sandbox：瀏覽器行為的限制，比如不能有彈出窗口等。

安全意識

最後一點，正如這個圖片的標語一樣，我們需要時刻保持安全意識。雖然安全始終是相對的，但如果我們通過提高開發中的安全意識，也就增加攻擊者發起攻擊的成本。

參考鏈接

https://www.hacksplaining.com/prevention/xss-storedhttps://www.owasp.org/index.php/Cross-site_Scripting_(XSS)https://developers.google.com/web/fundamentals/security/csp/https://content-security-policy.com/

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！