前端安全系列（一）：如何防止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>搜索</button>
<div>您搜索的关键词是：<%= getParameter("keyword") %>
</div> 

然而，在上线后不久，小明就接到了安全组发来的一个神秘链接：

<script>alert('XSS');</script>" target="_blank">http://xxx/search?keyword="><script>alert('XSS');</script>

小明带着一种不祥的预感点开了这个链接[请勿模仿，确认安全的链接才能点开]。果然，页面中弹出了写着"XSS"的对话框。

可恶，中招了！小明眉头一皱，发现了其中的奥秘：

当浏览器请求 <script>alert('XSS');</script>" target="_blank">http://xxx/search?keyword="><script>alert('XSS');</script> 时，服务端会解析出请求参数 keyword，得到 "><script>alert('XSS');</script>，拼接到 HTML 中返回给浏览器。形成了如下的 HTML：

<input type="text" value=""><script>alert('XSS');</script>">
<button>搜索</button>
<div>您搜索的关键词是："><script>alert('XSS');</script>
</div> 

浏览器无法分辨出 <script>alert('XSS');</script> 是恶意代码，因而将其执行。

这里不仅仅 div 的内容被注入了，而且 input 的 value 属性也被注入， alert 会弹出两次。

面对这种情况，我们应该如何进行防范呢？

其实，这只是浏览器把用户的输入当成了脚本进行了执行。那么只要告诉浏览器这段内容是文本就可以了。

聪明的小明很快找到解决方法，把这个漏洞修复：

<input type="text" value="<%= escapeHTML(getParameter("keyword")) %>">
<button>搜索</button>
<div>您搜索的关键词是：<%= escapeHTML(getParameter("keyword")) %>
</div> 

escapeHTML() 按照如下规则进行转义：

字符	转义后的字符
&	&
<	<
>	>
"	"
'	&#x27;
/	&#x2F;

经过了转义函数的处理后，最终浏览器接收到的响应为：

<input type="text" value=""><script>alert(&#x27;XSS&#x27;);<&#x2F;script>">
<button>搜索</button>
<div>您搜索的关键词是："><script>alert(&#x27;XSS&#x27;);<&#x2F;script>
</div> 

恶意代码都被转义，不再被浏览器执行，而且搜索词能够完美的在页面显示出来。

通过这个事件，小明学习到了如下知识：

• 通常页面中包含的用户输入内容都在固定的容器或者属性内，以文本的形式展示。

• 攻击者利用这些页面的用户输入片段，拼接特殊格式的字符串，突破原有位置的限制，形成了代码片段。

• 攻击者通过在目标网站上注入脚本，使之在用户的浏览器上运行，从而引发潜在风险。

• 通过 HTML 转义，可以防止 XSS 攻击。[事情当然没有这么简单啦！请继续往下看]。

注意特殊的 HTML 属性、JavaScript API

自从上次事件之后，小明会小心的把插入到页面中的数据进行转义。而且他还发现了大部分模板都带有的转义配置，让所有插入到页面中的数据都默认进行转义。这样就不怕不小心漏掉未转义的变量啦，于是小明的工作又渐渐变得轻松起来。

但是，作为导演的我，不可能让小明这么简单、开心地改 Bug 。

不久，小明又收到安全组的神秘链接：http://xxx/?redirect_to=javascript:alert('XSS')。小明不敢大意，赶忙点开页面。然而，页面并没有自动弹出万恶的“XSS”。

小明打开对应页面的源码，发现有以下内容：

<a href="<%= escapeHTML(getParameter("redirect_to")) %>">跳转...</a> 

这段代码，当攻击 URL 为 http://xxx/?redirect_to=javascript:alert('XSS')，服务端响应就成了：

<a href="javascript:alert(&#x27;XSS&#x27;)">跳转...</a> 

虽然代码不会立即执行，但一旦用户点击 a 标签时，浏览器会就会弹出“XSS”。

可恶，又失策了...

在这里，用户的数据并没有在位置上突破我们的限制，仍然是正确的 href 属性。但其内容并不是我们所预期的类型。

原来不仅仅是特殊字符，连 javascript: 这样的字符串如果出现在特定的位置也会引发 XSS 攻击。

小