富文本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 输入，相对安全一点。

最安全的做法就是运维的事，不要放到线上进行，直接上服务器上操作。