一、如何预防XSS
XSS 攻击有两⼤要素:
-
攻击者提交恶意代码。
-
浏览器执⾏恶意代码。
针对第⼀个要素:我们是否能够在⽤户输⼊的过程,过滤掉⽤户输⼊的恶意代码呢?
输入过滤
在⽤户提交时,由前端过滤输⼊,然后提交到后端。这样做是否可⾏呢? 答案是不可⾏。⼀旦攻击者绕过前端过滤,直接构造请求,就可以提交恶意代码了。 那么,换⼀个过滤时机:后端在写⼊数据库前,对输⼊进⾏过滤,然后把“安全的”内容,返回给前端。这样是否可行呢?我们举⼀个例子,⼀个正常的⽤户输⼊了 5 < 7 这个内容,在写入数据库前,被转义,变成了 5 < 7 。问 题是:在提交阶段,我们并不确定内容要输出到哪⾥。
这⾥的“并不确定内容要输出到哪⾥”有两层含义:
-
用户的输入内容可能同时提供给前端和客户端,而⼀旦经过了 escapeHTML() ,客户端显示的内容就变成了乱码(5 < 7)。
-
在前端中,不同的位置所需的编码也不同。
- 当 作为 5 < 7 HTML 拼接页面时,可以正常显示:
<div title="comment">5 < 7</div>
- 当 5 < 7 通过 Ajax 返回,然后赋值给 JavaScript 的变量时,前端得到的字符串就是转义后的字符。这个内容不能直接⽤于 Vue 等模板的展示,也不能直接用于内容长度计算。不能⽤于标题、alert 等。
所以,输⼊侧过滤能够在某些情况下解决特定的 XSS 问题,但会引⼊很⼤的不确定性和乱码问题。在防范 XSS 攻击时 应避免此类⽅法。
当然,对于明确的输⼊类型,例如数字、URL、电话号码、邮件地址等等内容,进⾏输⼊过滤还是必要的。
既然输入过滤并非完全可靠,我们就要通过“防止浏览器执行恶意代码”来防范 XSS。这部分分为两类:
-
防止HTML 中出现注入。
-
防止JavaScript 执行时,执行恶意代码。
预防存储型和反射型 XSS 攻击
存储型和反射型 XSS 都是在服务端取出恶意代码后,插⼊到响应 HTML 里的,攻击者刻意编写的“数据”被内嵌到“代码”中,被浏览器所执行。
预防这两种漏洞,有两种常见做法:
-
改成纯前端渲染,把代码和数据分隔开。
-
对 HTML 做充分转义。
纯前端渲染
纯前端渲染的过程:
-
浏览器先加载⼀个静态 HTML,此 HTML 中不包含任何跟业务相关的数据。
-
然后浏览器执行 HTML 中的 JavaScript。
-
JavaScript 通过 Ajax 加载业务数据,调用DOM API 更新到页面上。
在纯前端渲染中,我们会明确的告诉浏览器:下面要设置的内容是文本( .innerText ),还是属性 ( .setAttribute ),还是样式( .style )等等。浏览器不会被轻易的被欺骗,执行预期外的代码了。 但纯前端渲染还需注意避免 DOM 型 XSS 漏洞(例如 onload 事件和 href 中的 javascript:xxx 等,请参考下⽂”预防 DOM 型 XSS 攻击“部分)。 在很多内部、管理系统中,采用纯前端渲染是⾮常合适的。但对于性能要求⾼,或有 SEO 需求的页面,我们仍然要面对拼接 HTML 的问题。
转义 HTML
如果拼接 HTML 是必要的,就需要采⽤合适的