富文本XSS防御

XSS的一般防御

一般轉義掉所有尖括號 < > to < > 和雙引號 " " to " " 即可。

優點是成本比較低，且一勞永逸。

缺點是部分情況可能會出現轉義字符未渲染的情況，比如瀏覽就直接顯示 <

根據可在三個環節轉義：

1. 后端接收前端提交的數據后，在數據存入數據庫前轉義，缺點是可能會污染數據庫中的數據，如果數據庫還要放到其他地方用的話，讀出還要轉義回去

2. 后端接受前端請求后，將數據庫的數據轉義后輸出給前端，缺點是每次請求都需要轉義會增加服務器一點負擔，當然如果網站沒有前后端分離那不用考慮此問題

3. 對於前后端分離的網站，前端拿到后端數據后，轉義再填充進頁面中

如果不想轉義后入庫，需要注意一些輸入框會重復轉義，比如新增一個內容，其中含有 <>"" ，當用戶再修改時，textarea中已經填充了上次輸入的內容，其中的 <>"" 已經被轉義，當用戶追加一些內容提交后，<>"" 仍以開發者不願看到的轉義的形式入庫了。

富文本的XSS防御

一些需要提交富文本的功能，比如郵件、公告內容，需要用到html標簽；再比如一些流程、作業的設計，可能要以xml格式來保存。這種情況下上述轉義的方法就不適用了。

這時就必須識別出XSS攻擊代碼了，識別出來有兩種處理方法，一是攔截，直接 403 Forbidden；二是過濾，一般是刪掉或者替換然后存入數據庫。

不推薦過濾處理，容易被繞過。

這里簡述一下識別XSS攻擊的邏輯：

• 禁止一些危險的標簽，比如 script 、 object。標簽名和<間必須無其他字符，標簽只能大小寫不能進行其他編碼

• 禁止所有事件屬性，比如 onerror 、 onmouseover，這里難以搜尋全面的 event list，最好是禁止 on 開頭屬性。屬性只能大小寫

• 對於 src、href 中的鏈接，檢驗其中是否有關鍵字 javascript:。javascript:字母中可以穿插其他編碼的ascii控制字符，但是本身字母不可以編碼，后面的js代碼的字母才能編碼

• 特別地，說一下 iframe、embed 等嵌套的頁面，似乎是安全的，比如iframe中的 alert(document.cookie)，是沒法讀取宿主頁面的cookie的

  不然 <iframe src="http://"> 誰敢用

特殊情況

如果遇到一些特殊的功能，比如Web應用分前台和管理台，管理台可以配置前台的頁面，比如頁眉頁腳等，就是需要js。

管理台控制前台的js，個人認為是沒問題的，管理台可以有這個權限。

但管理台這個地方如果是富文本的，可查看效果，就有安全隱患了。 可以用 input 或 textarea 輸入，相對安全一點。

最安全的做法就是運維的事，不要放到線上進行，直接上服務器上操作。