XSS
XSS: Cross-Site Scripting
原理概述：
簡單來說
正常用戶 A 提交正常內容，顯示在另一個用戶 B 的網頁上，沒有問題。
惡意用戶 H 提交惡意內容，顯示在另一個用戶 B 的網頁上，對 B 的網頁隨意篡改。
造成 XSS 有幾個要點：
惡意用戶可以提交內容
提交的內容可以顯示在另一個用戶的頁面上
這些內容未經過濾，直接運行在另一個用戶的頁面上
舉個例子
假設我們有一個評論系統。
用戶 A 提交評論「Hello你好」到服務器，然后用戶 B 來訪問網站，看到了 A 的評論「Hello你好」，這里沒有 XSS。
惡意用戶 H 提交評論「<script>console.log(document.cookie)</script>」，然后用戶 B 來訪問網站，這段腳本在 B 的瀏覽器直接執行，惡意用戶 H 的腳本就可以任意操作 B 的 cookie，而 B 對此毫無察覺。有了 cookie，惡意用戶 H 就可以偽造 B 的登錄信息，隨意訪問 B 的隱私了。而 B 始終被蒙在鼓里。
XSS的成因及解決辦法
一般XSS成因跟后端和前端都有關系
后端方面：
模板問題：
<p>
評論內容：<?php echo $content; ?>
</p>
$content 的內容，沒有經過任何過濾，原樣輸出。
要解決這個原因，只需要后臺輸出的時候，將可疑的符號 < 符號變成 < （HTML實體）就行。
前端方面：
$p.html(content)
//或者
$p = $('<p>'+ content +'</p>')
content 內容又被原樣輸出了。解決辦法就是不要自己拼 HTML，盡量使用 text 方法。如果一定要使用 HTML，就把可疑符號變成 HTML 實體。
CSRF
總結：
XSS的防范措施：后端模板方面，要將可疑符號<替換成HTML實體< ，前端在寫代碼的時候避免使用html方法或者拼接字符串。
CSRF
Cross Site Request Forgery 跨站請求偽造
原理：
攻擊者構造網站后臺某個功能接口的請求地址，誘導用戶去點擊或者用特殊方法讓該請求地址自動加載。用戶在登錄狀態下這個請求被服務端接收后會被誤以為是用戶合法的操作。對于 GET 形式的接口地址可輕易被攻擊，對于 POST 形式的接口地址也不是百分百安全，攻擊者可誘導用戶進入帶 Form 表單可用POST方式提交參數的頁面。
解決方案：
- 服務端在收到路由請求時，生成一個隨機數，在渲染請求頁面時把隨機數埋入頁面（一般埋入 form 表單內，<input type="hidden" name="_csrf_token" value="xxxx">）
- 服務端設置setCookie，把該隨機數作為cookie或者session種入用戶瀏覽器
- 當用戶發送 GET 或者 POST 請求時帶上_csrf_token參數（對于 Form 表單直接提交即可，因為會自動把當前表單內所有的 input 提交給后臺，包括_csrf_token）
- 后臺在接受到請求后解析請求的cookie獲取_csrf_token的值，然后和用戶請求提交的_csrf_token做個比較，如果相等表示請求是合法的。
