> XSS（跨站指令碼攻擊），聊兩句，五毛的。 #### XSS的危害： * 竊取Cookie，盜用使用者身份資訊 這玩意兒是大多數XSS的目標，也好解決，可以先治個標，直接設定`HttpOnly=true` ，即不允許客戶端指令碼訪問，設定完成後，通過js去讀取cookie，你會發現`document.cookie` 無法讀取到被標識為HttpOnly的Cookie內容了。 * 配合其他漏洞，如CSRF（跨站請求偽造） 這個其實就沒那麼好解決了，因為XSS利用使用者身份構造的請求其實對於服務端來說是合法的。比如說咱在B站上傳了一條視訊，發現沒幾個人點贊，於是動了歪心思，開啟控制檯找到了投幣點讚的介面，然後拿到了對應的請求引數。自己構造了一條投幣請求，然後誘導其他人點選含有這個指令碼的頁面為咱的視訊投幣，這樣就完成了一套攻擊流程。 > 不用嘗試了，沒用的。別問我怎麼知道的 =。=。 > > 要是沒做校驗的話，那這就是一個高危漏洞，還傳啥視訊啊，趕緊發郵件給阿B領賞金去啊。 * 廣告 只要能發起XSS，我就能往頁面裡插廣告，啥許可權都不要，但是能引發這個問題的原因主要有兩個。 1. XSS。 2. 使用者自己安裝外部指令碼。 > 使用外部指令碼一定要保證指令碼來源的可信性，指令碼的安全性。如果指令碼是惡意的，那麼他所能做的可就不只是彈彈廣告這麼簡單了，替換個按鈕，誘導點選釣魚頁面，替換某一條搜尋結果，這都是可能的。 #### XSS掃描及防範 XSS風險有些是可以通過code review發現的，比如： ```js 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](https://github.com/ai977313677/blog/blob/master/snippet/xssFilter.js)檢視。 [^1]: [如何防止xss攻擊](https://tech.meituan.com/2018/09/27/fe-security.html) [^2]: [內容安全策略](https://developer.mozilla.org/zh-CN/docs/Web/HT