前端安全系列（一）：如何防止XSS攻击？
前端安全
随着互联网的高速发展，信息安全问题已经成为企业最为关注的焦点之一，而前端又是引发企业安全问题的高危据点。在移动互联网时代，前端人员除了传统的 XSS、CSRF 等安全问题之外，又时常遭遇网络劫持、非法调用 Hybrid API 等新型安全问题。当然，浏览器自身也在不断在进化和发展，不断引入 CSP、Same-Site Cookies 等新技术来增强安全性，但是仍存在很多潜在的威胁，这需要前端技术人员不断进行“查漏补缺”。
近几年，美团业务高速发展，前端随之面临很多安全挑战，因此积累了大量的实践经验。我们梳理了常见的前端安全问题以及对应的解决方案，将会做成一个系列，希望可以帮助前端人员在日常开发中不断预防和修复安全漏洞。本文是该系列的第一篇。
本文我们会讲解 XSS ，主要包括：
1.XSS 攻击的介绍
2.XSS 攻击的分类
3.XSS 攻击的预防和检测
4.XSS 攻击的总结
5.XSS 攻击案例
XSS 攻击的介绍
在开始本文之前，我们先提出一个问题，请判断以下两个说法是否正确：
1.XSS 防范是后端 RD（研发人员）的责任，后端 RD 应该在所有用户提交数据的接口，对敏感字符进行转义，才能进行下一步操作。
2.所有要插入到页面上的数据，都要通过一个敏感字符过滤函数的转义，过滤掉通用的敏感字符后，就可以插入到页面中。
如果你还不能确定答案，那么可以带着这些问题向下看，我们将逐步拆解问题。
XSS 漏洞的发生和修复
XSS 攻击是页面被注入了恶意的代码，为了更形象的介绍，我们用发生在小明同学身边的事例来进行说明。
一个案例
某天，公司需要一个搜索页面，根据 URL 参数决定关键词的内容。小明很快把页面写好并且上线。代码如下：
< input type = "text" value = "<%= getParameter(" keyword ") %> ">
< button > 搜索
< div >
您搜索的关键词是： < %= getParameter (" keyword ") %>
然而，在上线后不久，小明就接到了安全组发来的一个神秘链接：
http://xxx/search?keyword=">
小明带着一种不祥的预感点开了这个链接 [请勿模仿，确认安全的链接才能点开] 。果然，页面中弹出了写着”XSS”的对话框。
可恶，中招了！小明眉头一皱，发现了其中的奥秘：
当浏览器请求 http://xxx/search?keyword="> 时，服务端会解析出请求参数 keyword，得到 ">，拼接到 HTML 中返回给浏览器。形成了如下的 HTML：
< input type = "text" value = "" > < script > alert( 'XSS' ); "> < button > 搜索 < div > 您搜索的关键词是："> < script > alert( 'XSS' );
浏览器无法分辨出 是恶意代码，因而将其执行。
这里不仅仅 div 的内容被注入了，而且 input 的 value 属性也被注入， alert 会弹出两次。
面对这种情况，我们应该如何进行防范呢？
其实，这只是浏览器把用户的输入当成了脚本进行了执行。那么只要告诉浏览器这段内容是文本就可以了。
聪明的小明很快找到解决方法，把这个漏洞修复：
< input type = "text" value = "<%= escapeHTML(getParameter(" keyword ")) %> ">
< button > 搜索
< div >
您搜索的关键词是： < %= escapeHTML ( getParameter (" keyword ")) %>
escapeHTML() 按照如下规则进行转义：
|字符|转义后的字符| |-|-| |&|&| |<|<| |>|>| |"|"| |'|'| |/|/|
经过了转义函数的处理后，最终浏览器接收到的响应为：
< input type = "text" value = ""><script>alert('XSS');</script>" >
< button > 搜索
< div >
您搜索的关键词是："><script>alert('XSS');</script>
恶意代码都被转义，不再被浏览器执行，而且搜索词能够完美的在页面显示出来。
通过这个事件，小明学习到了如下知识：
通常页面中包含的用户输入内容都在固定的容器或者属性内，以文本的形式展示。
攻击者利用这些页面的用户输入片段，拼接特殊格式的字符串，突破原有位置的限制，形成了代码片段。
攻击者通过在目标网站上注入脚本，使之在用户的浏览器上运行，从而引发潜在风险。
通过 HTML 转义，可以防止 XSS 攻击。 [事情当然没有这么简单啦！请继续往下看] 。
注意特殊的 HTML 属性、JavaScript API
自从上次事件之后，小明会小心的把插入到页面中的数据进行转义。而且他还发现了大部分模板都带有的转义配置，让所有插入到页面中的数据都默认进行转义。这样就不怕不小心漏掉未转义的变量啦，于是小明的工作又渐渐变得轻松起来。
但是，作为导演的我，不可能让小明这么简单、开心地改 Bug 。
不久，小明又收到安全组的神秘链接：http://xxx/?redirect_to=javascript:alert('XSS')。小明不敢大意，赶忙点开页面。然而，页面并没有自动弹出万恶的“XSS”。
小明打开对应页面的源码，发现有以下内容：
< a href = "<%= escapeHTML(getParameter(" redirect_to ")) %> ">跳转...
这段代码，当攻击 URL 为 http://xxx/?redirect_to=javascript:alert('XSS')，服务端响应就成了：
< a href = "javascript:alert('XSS')" > 跳转...
虽然代码不会立即执行，但一旦用户点击 a 标签时，浏览器会就会弹出“XSS”。
可恶，又失策了…
在这里，用户的数据并没有在位置上突破我们的限制，仍然是正确的 href 属性。但其内容并不是我们所预期的类型。
原来不仅仅是特殊字符，连 javascript: 这样的字符串如果出现在特定的位置也会引发 XSS 攻击。
小明眉头一皱，想到了解决办法：
// 禁止 URL 以 "javascript:" 开头
xss = getParameter( "redirect_to" ).startsWith( 'javascript:' );
if (!xss) {
" >
跳转...
} else {
跳转...
}
只要 URL 的开头不是 javascript:，就安全了吧？
安全组随手又扔了一个连接：http://xxx/?redirect_to=jAvascRipt:alert('XSS')
这也能执行？…..好吧，浏览器就是这么强大。
小明欲哭无泪，在判断 URL 开头是否为 javascript: 时，先把用户输入转成了小写，然后再进行比对。
不过，所谓“道高一尺，魔高一丈”。面对小明的防护策略，安全组就构造了这样一个连接：
http://xxx/?redirect_to=%20javascript:alert('XSS')
%20javascript:alert('XSS') 经过 URL 解析后变成 javascript:alert('XSS')，这个字符串以空格开头。这样攻击者可以绕过后端的关键词规则，又成功的完成了注入。
最终，小明选择了白名单的方法，彻底解决了这个漏洞：
// 根据项目情况进行过滤，禁止掉 "javascript:" 链接、非法 scheme 等
allowSchemes = [ "http" , "https" ];
valid = isValid(getParameter( "redirect_to" ), allowSchemes);
if (valid) {
" >
跳转...
} else {
跳转...
}
通过这个事件，小明学习到了如下知识：
1.做了 HTML 转义，并不等于高枕无忧。
2.对于链接跳转，如 <a href="xxx" 或 location.href="xxx"，要检验其内容，禁止以 javascript: 开头的链接，和其他非法的 scheme。
根据上下文采用不同的转义规则
某天，小明为了加快网页的加载速度，把一个数据通过 JSON 的方式内联到 HTML 中：
< script > var initData = < %= data.toJSON () %>
插入 JSON 的地方不能使用 escapeHTML()，因为转义 " 后，JSON 格式会被破坏。
但安全组又发现有漏洞，原来这样内联 JSON 也是不安全的：
1.当 JSON 中包含 U+2028 或 U+2029 这两个字符时，不能作为 JavaScript 的字面量使用，否则会抛出语法错误。
2.当 JSON 中包含字符串 时，当前的 script 标签将会被闭合，后面的字符串内容浏览器会按照 HTML 进行解析；通过增加下一个 \x3csVg/