常见网络攻击：XSS 篇

提起防御网络攻击，很多同学只知道需要转义，编码。但是这个话题实际上博大精深，不止这四个字这么简单。

文章目录：

常见的 XSS 攻击类型
不止如此
谈谈防御
总结

常见的 XSS 攻击类型

某天前端打杂小刘和后端同学在给现有业务加搜索功能，前端同学在展示模糊搜索结果的同时，需要展示用户当前搜索的字段，比如『没有关于 *** 的搜索内容』。在没有任何防御措施的时候，用户输入<script>alert(1)</script>，就有可能直接弹出在页面上。这就是反射型 XSS 攻击。还是这个搜索功能，如果有一天产品心血来潮要加一个『朋友们的最近搜索』功能，依然是在没有任何防御的时候，某个用户还是搜索<script>alert(1)</script>，那么其他用户访问时就有可能弹框，这就是存储型（持久型）XSS 攻击。
从上面这个例子可以看出，所谓反射型，是发生在当前用户的某些请求或者页面访问的 url 中携带的某些字段，回显到页面或者影响到当前页面的一些执行过程。但是并没有存储到数据库中，意味着不会影响到其他访问这个页面的用户。
存储型则不同，像刚才的例子，我们把用户最近输入的内容存储到数据库，以在他的关联用户访问时可以展示。这种攻击会影响到其他的用户。
DOM-based XSS 又是什么？很多文章指出DOM-based是反射型 XSS 的一种，但是我个人认为不太对，下面附上 mediawiki 的解释：

DOM-based XSS (or type-0 XSS) is a type of Cross-site scripting attack that occurs when client-side scripts (such as JavaScript) manipulate the page's DOM, allowing an attacker to run JavaScript in the victim's browser.
This class of XSS is distinct from Reflective XSS (type-1 XSS) and Stored XSS (type-2 XSS), since the server is not returning executable JavaScript to the browser. Instead, data that has been sanitized by the server, or possibly never sent to the server, is converted to executable JavaScript by the existing code running on the page.

只要是在客户端脚本操作页面 DOM 时运行了攻击者的 javascript 脚本，都归类于 DOM-based XSS。也就是说他概括的维度更贴近于触发的出口，而不是方式。所以他其实和反射型，存储型是有交叉的。DOM-based XSS 甚至不依赖于请求，只在客户端本身就具备发生此类攻击的条件。

不止如此

继续回到前端打杂小刘的故事。测试同学在安全测试的过程中，反馈了 bug。前端同学和后端同学两个人开始商量怎么处理。转义！两人一拍即合。后端同学针对字符串类型的数据进行实体化转义
[图片上传失败...(image-16800d-1524309858885)]
小刘在自己调用 innerHTML 方法的参数前也加了一层转义。大功告成！
没高兴几个小时，测试又提过来一个 bug 。小刘当时偷懒，直接在标签上写了dom 0级事件。如下写法：

<button onclick=`alert(${name})`></button>

而 name 是依赖于用户输入的。如果用户输入的 name 为：);alert(document.cookie 你看会发生什么？小刘惊讶于还有这种操作的同时，也深刻意识到了防范 XSS 攻击远远不止简单实体化转义 HTML 代码这么简单。我们需要对不同的应用场景，和你的代码，来做不同的转义。在这个例子里，我们需要对拼接进事件中的用户字符串进行一次 javascript 编码（这里科普一下 javascript 编码指的就是 unicode 编码）即：

<h1 class="title" onclick="alert('\u0027\u0029\u003b\u0061\u006c\u0065\u0072\u0074\u0028\u0027\u0053\u0052\u0043')">点击弹出</h1>

类似的场景还有很多，最近还有针对 css 攻击防御的文章，大家有时间可以了解一下。但是万变不离其宗，我们要秉持怀疑所有用户输入的态度，有针对性的转义和编码，而不是只是知道需要转义这么简单。

谈谈防御

在上面一个小节已经讲过转义的基本用法和针对的场景。下面来说一些老生常谈的话题：哪些是前端不能做的雷区。
new function、echo、innerHTML、dom 0 级事件等等。尤其是当他们的内容和用户输入有关联的时候，都有可能形成漏洞。

总结

XSS 防范是需要我们在养成好的写码习惯的同时，还要对所有用户输入保持警惕。
不能把自己的安全建立在其他接口是否返回正确的基础上，所以最好在前端也要加一层校验，而不能完全依赖后端。
现代浏览器很多都对类似的情况有过滤和处理，但是并不完备。大多数的模板引擎和框架内部也多有针对 XSS 的防范。