聊兩句XSS（跨站腳本攻擊）
XSS（跨站腳本攻擊），聊兩句，五毛的。
XSS的危害：
- 竊取Cookie，盜用用戶身份信息
這玩意兒是大多數XSS的目標，也好解決，可以先治個標，直接設置HttpOnly=true ，即不允許客戶端腳本訪問，設置完成後，通過js去讀取cookie，你會發現document.cookie 無法讀取到被標識為HttpOnly的Cookie內容了。
- 配合其他漏洞，如CSRF（跨站請求偽造）
這個其實就沒那麼好解決了，因為XSS利用用戶身份構造的請求其實對於服務端來說是合法的。比如說咱在B站上傳了一條視頻，發現沒幾個人點贊，於是動了歪心思，打開控制台找到了投幣點贊的接口，然後拿到了對應的請求參數。自己構造了一條投幣請求，然後誘導其他人點擊含有這個腳本的頁面為咱的視頻投幣，這樣就完成了一套攻擊流程。
不用嘗試了，沒用的。別問我怎麼知道的 =。=。
要是沒做校驗的話，那這就是一個高危漏洞，還傳啥視頻啊，趕緊發郵件給阿B領賞金去啊。
- 廣告
只要能發起XSS，我就能往頁面里插廣告，啥權限都不要，但是能引發這個問題的原因主要有兩個。
- XSS。
- 用戶自己安裝外部腳本。
使用外部腳本一定要保證腳本來源的可信性，腳本的安全性。如果腳本是惡意的，那麼他所能做的可就不只是彈彈廣告這麼簡單了，替換個按鈕，誘導點擊釣魚頁面，替換某一條搜索結果，這都是可能的。
XSS掃描及防範
XSS風險有些是可以通過code review發現的，比如：
let result = document.getElementById('test');
result.innerHTML = await getInfo();
這段代碼很容易看到風險位置——innerHTML ，如果後端返回的數據中包含惡意的代碼片段，那麼就能夠被攻擊。所以在使用Vue和React框架時，需要評估是否真的需要使用v-html 和dangerouslySetInnerHTML 功能，在前端的render（渲染）階段就避免innerHTML 和 outerHTML [1]。
如果不使用框架，那就避免直接使用
innerHTML就好了。
至於review時無法發現的風險，那就交給掃描器吧。
防範XSS，除了少使用、不使用innerHTML 外，還可以設置嚴格的CSP[2]，限制用戶的輸入長度。
XSS是一個安全問題，它不只是前端的職責，這也是所有RD和QA的職責。
前端過濾用戶輸入後發給後端，後端如果不做處理存入數據庫，那麼這就是一個攻擊點：直接抓前端的包，重新組裝一下參數，發給後端，完成存儲型XSS第一步，用戶再訪問這部分內容，就完成了一次XSS。
QA的總能搞出來一些奇奇怪怪的payload（亦稱測試用例），這些可能都是RD未能考慮到的方面。
附一段白名單過濾用戶輸入的代碼，點擊GitHub查看。
