Web安全系列（四）：XSS 的防御

---

---

简介

XSS 的防御很复杂，并不是一套防御机制就能就解决的问题，它需要具体业务具体实现。

目前来说，流行的浏览器内都内置了一些 XSS 过滤器，但是这只能防御一部分常见的 XSS，而对于网站来说，也应该一直寻求优秀的解决方案，保护网站及用户的安全，我将阐述一下网站在设计上该如何避免 XSS 的攻击。

HttpOnly

HttpOnly 最早是由微软提出，并在 IE 6 中实现的，至今已经逐渐成为一个标准，各大浏览器都支持此标准。具体含义就是，如果某个 Cookie 带有 HttpOnly 属性，那么这一条 Cookie 将被禁止读取，也就是说，JavaScript 读取不到此条 Cookie，不过在与服务端交互的时候，Http Request 包中仍然会带上这个 Cookie 信息，即我们的正常交互不受影响。

Cookie 是通过 http response header 种到浏览器的，我们来看看设置 Cookie 的语法：

Set-Cookie: <name>=<value>[; <Max-Age>=<age>][; expires=<date>][; domain=<domain_name>][; path=<some_path>][; secure][; HttpOnly] 

第一个是 name=value 的键值对，然后是一些属性，比如失效时间，作用的 domain 和 path ，最后还有两个标志位，可以设置为 secure 和 HttpOnly。

栗子：

// 利用 express 这个轮子设置cookie
res.cookie('myCookie', 'test', {httpOnly: true
})
res.cookie('myCookie2', 'test', {httpOnly: false
}) 

然后回到浏览器查看：

这个时候我们试着在控制台输出：

我们发现，只有没有设置 HttpOnly 的 myCookie2 输出了出来，这样一来， javascript 就读取不到这个 Cookie 信息了。

HttpOnly 的设置过程十分简单，而且效果明显，不过需要注意的是，所有需要设置 Cookie 的地方，都要给关键的 Cookie 都加上 HttpOnly ，若有遗漏则会功亏一篑。

但是， HttpOnly 不是万能的，添加了 HttpOnly 不等于解决了 XSS 问题。

严格的说，HttpOnly 并非为了对抗 XSS ，HttpOnly 解决的是 XSS 后的 Cookie 劫持问题，但是 XSS 攻击带来的不仅仅是 Cookie 劫持问题，还有窃取用户信息，模拟身份登录，操作用户账户等一系列行为。

使用 HttpOnly 有助于缓解 XSS 攻击，但是仍然需要其他能够解决 XSS 漏洞的方案。

输入检查

记住一点：不要相信任何输入的内容。

无论是不是做了安全校验，都必须进行过滤操作，而且需要后台配合过滤，如果后端的检查校验还做得不好，那就可能被攻破。

输入检查在更多的时候被用于格式检验，例如用户名只能以字母和数字组合，手机号码只能有 11 位且全部为数字，否则即为非法。

这些格式检查类似于白名单效果，限制输入允许的字符，让一下特殊字符的攻击失效。

目前网上有很多开源的 XSS Filter ，这些 XSS Filter 目前来说还是有些效果的，能只能检验输入内容，高级一点的还会匹配 XSS 特征，例如内容是否包含了 <script>，javascript 等敏感字符，但是这些 XSS Filter 只是获取到了用户的输入内容，并不了解其上下文含义，很多时候会误过滤。

例如：

用户输入昵称：<|无敌是多么鸡毛|>，对于 XSS Filter 来说，<> 就是特殊字符，需要过滤然后过滤成为 |无敌是多么鸡毛| ，直接改变了用户的昵称。

所以，我们不能完全信赖开源的 XSS Filter ，很多场景需要我们自己配置规则，进行过滤。

输出检查

不要以为在输入的时候进行过滤就万事大吉了，恶意攻击者们可能会层层绕过防御机制进行 XSS 攻击，一般来说，所有需要输出到 HTML 页面的变量，全部需要使用编码或者转义来防御。

HTMLEncode

针对 HTML 代码的编码方式是 HTMLEncode，它的作用是将字符串转换成 HTMLEntities。

目前来说，为了对抗 XSS ，以下转义内容是必不可少的：

特殊字符	实体编码
&	&amp ;
<	&lt ;
>	&gt ;
"	&quot ;