这是由一个框架安全防范功能引发的思考
最近项目中接触到一个自主封装的框架，它对所有输入的数据都做了过滤。将所有的html标签做了过滤，并且在查询的接口对所有的<或者>都进行抛错。这个防范行为不仅对查询功能不友好，且禁止了所有有HTML语义的字符输入，由此会导致这个框架无法支持富文本功能。因为所有富文本不可避免会带上各种编辑样式的标签如<strong>等，都在后端接收数据时做了全量过滤，传过去的数据就只有输入的文本，导致富文本样式丢失。
这些行为会导致项目中部分需求无法实现，那么如何在保有这些功能的前提下，做XSS攻击的防范？
首先引用一段解释，来介绍什么是 XSS
Cross-Site Scripting（跨站脚本攻击）简称 XSS，是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行。利用这些恶意脚本，攻击者可获取用户的敏感信息如 Cookie、SessionID 等，进而危害数据安全。
不可信的数据来源有以下但不限于：
- 来自用户的 UGC 信息（User Generated Content）
- 来自第三方的链接
- URL 参数
- POST 参数
这些不可信的数据来源都有可能成为恶意代码，恶意代码就是的XSS攻击要素，攻击原理如下：
- 攻击者提交恶意代码。
- 浏览器执行恶意代码。
那么我们应该如何防范？根据以上供给来源分析，是否该由前端过滤输入？
答案是不可行的。原因如下：
- 因为数据的来源不一定是UGC，黑客可以绕过前端进行数据提交。那么又可以引申一个问题，怎么防范这种行为。现在行内采用的较为通用的手段是对数据传输做Mac校验，使用加密算法和密钥对时间戳和请求报文做一个加密作为sign传输，不仅可以防止黑客使用postman这样的工具进行数据提交，还可以防重放。
- 前端过滤后的数据，提交给后台。但是这个数据到底会用在哪里，并不能确定，例如
<1>被过滤成<1>进行传输。这条数据如果渲染在HTML中，就能展现为正常的字符串"<1>"，但是如果在Vue或者React等模板中展示，那么会渲染一段乱码的字符串，也就是"<1>'，跟用户输入并且预期展示的内容是不一致的。
转义应该在输出 HTML 时进行，而不是在提交用户输入时
所有要插入到页面上的数据，都要通过一个敏感字符过滤函数的转义，过滤掉通用的敏感字符后，就可以插入到页面中。
所以UGC输入层做过滤的这种行为既不能完全防范XSS，也会造成不确定性和乱码问题。
整体的 XSS 防范是非常复杂和繁琐的，我们不仅需要在全部需要转义的位置，对数据进行对应的转义。而且要防止多余和错误的转义，避免正常的用户输入出现乱码。
那么现在的前端开发中，我们经常采用的防范方法是：
- 纯前端渲染（使用Vue或者React这样的框架时，采用的正是这样的方法，除SSR）
- 如果用 Vue/React 技术栈，并且不使用 v-html/dangerouslySetInnerHTML 功能，就能在前端 render 阶段避免 innerHTML、outerHTML 的 XSS 隐患。
- 在这个前提下，前端是可以输入具有攻击性的字符串，如
<img src=x onerror=alert('xss') />，但是当后端返回的时候，前端框架都会对其做过滤，当作一段文本渲染，而不会执行该攻击代码。例如Vue框架使用的是he开源库，框架在渲染数据时调用he.encode("<img src=x onerror=alert('xss') />")，转义后的数据为<img src=1 onerror=alert('xss') />，这样的转义字符串，不会造成攻击。- 如果在Vue或者react中直接渲染这段代码字符串，则会造成安全隐患，也就是Vue的v-html属性。在Vue文档中如下描述：
在网站上动态渲染任意 HTML 是非常危险的，因为容易导致 XSS 攻击。只在可信内容上使用v-html，永不用在用户提交的内容上。
- 对一定会渲染HTML的位置做前端过滤（eg: 富文本功能正是如此）
其实现在绝大部分的前端富文本编辑器，在提交数据的时候，对于用户输入的具有语义的字符都会做转义，例如用户输入
<div>，提交到后端时数据会是<div>。
但是自身因为编辑样式而带入的<strong>或者<p>这样的标签则不会，这是因为编辑器带入的标签都属于白名单，不会造成攻击风险。但是并不是所有的富文本编辑器在渲染数据时都做了XSS防范，例如我们项目中正在使用的quill正是如此，当加载外部一段XSS数据时，编辑器会成功被攻击。我们对此的应对是使用sanitize-html将传入富文本的数据再进行一次转义和过滤。
在研究项目中框架XSS防范功能时，遇到了另一个项目的XSS漏洞。
当时在和同事进行debugger的过程中，一度怀疑是antd的Tree组件的漏洞（对Tree组件尝试了很久都无法攻击成功，后面发现是我们too naive）。漏洞来源于一个开源库，该开源库的功能为一个组织架构图渲染组件，传入数据即可渲染出图中的节点。当数据塞入攻击代码片段时，项目就会被成功攻击到。我们在通过对这个开源库的源码debugger过程中，发现有一段代码
nodeDiv.innerHtml = `
<div class="title">${nodeData[opts.nodeTitle]}</div>
${opts.nodeContent ?
`<div class="content">${nodeData[opts.nodeContent]}</div>`
: ''}`
发现的确是在innerHTML里面拼接了攻击代码片段，才会造成漏洞。那么我们采用的解决方案是使用sanitize-html对这个库的数据注入进行一个前端过滤和转义，挡住一切可执行的攻击代码。
虽然很难通过技术手段完全避免 XSS，但我们可以总结以下原则减少漏洞的产生。基于以上描述，我们在项目中采用的采用的防范手段如下：
1. 开启Mac校验，增加防重放和防篡改，加大黑客绕过前端进行提交的攻击难度
2. 用户的在前端输入不做过滤，而是在明确的有渲染风险的地方做过滤。例如可知的富文本功能和某些具有渲染DOM节点功能的第三方库。过滤开源库我们使用Vue同款的he或者sanitize-html，都是比较稳定安全的开源库。
3. 后端对于富文本输入的数据调用xss_filter视情况使用不同的方法进行黑名单过滤或者转义具有攻击性的字符片段。但是也不会在所有接口使用该工具包，因为无差别且不与前端进行沟通的转义，很容易造成系统的渲染乱码。
4. 不使用v-html/dangerouslySetInnerHTML渲染UGC等来源不被信任的内容。
5. HTTP-only Cookie: 禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie。
6. 主动检测和发现，使用安全检测工具对 XSS 攻击字符串进行自动扫描工具以寻找潜在的 XSS 漏洞并且加以修复。
在对XSS的学习过程中，看到一篇更为全面的文章，获益匪浅，也从中借鉴和学习许多。
前端安全系列（一）：如何防止XSS攻击？
前端防XSS攻击转义库有he和sanitize-html，都比较成熟，star也很多。
网友评论