XSS 那些事

前言

随着互联网的高速发展，信息安全问题已经成为企业最为关注的焦点之一，而前端又是引发企业安全问题的高危据点。在移动互联网时代，前端人员除了传统的 XSS、CSRF 等安全问题之外，又时常遭遇网络劫持等新型安全问题。当然，浏览器自身也在不断在进化和发展，不断引入 CSP、Same-Site Cookies 等新技术来增强安全性，但是仍存在很多潜在的威胁，这需要前端技术人员不断进行“查漏补缺”。没有绝对安全的网站，web常见的攻击也是永远绕不开的话题，这次的分享简单聊聊 XSS。

在开始本文之前，我们先提出一个问题，请判断以下两个说法是否正确：

1. XSS 防范是后端 RD（研发人员）的责任，后端 RD 应该在所有用户提交数据的接口，对敏感字符进行转义，才能进行下一步操作。
2. 所有要插入到页面上的数据，都要通过一个敏感字符过滤函数的转义，过滤掉通用的敏感字符后，就可以插入到页面中。

如果你还不能确定答案，那么可以带着这些问题向下看，我们将逐步拆解问题。

XSS 漏洞是如何发生的

为了更形象的介绍，我们用发生在小明同学身边的事例来进行说明。

一个案例

某天，公司需要一个搜索页面，根据 URL 参数决定关键词的内容。小明很快把页面写好并且上线。代码如下：

xss-test

const Koa = require('koa')
const router = require('koa-router')()
const app = new Koa()
 
router.get("/", async ctx => {
  const html = `
    <h1>xss示例</h1>
    <p>${ctx.request.query.search}</p>
  `
  ctx.body =  html
 
app
  .use(router.routes())
  .use(router.allowedMethods())
  .listen(9999, () => console.log('9999端口开启'))

小明经过自测

http://localhost:9999?search=123

页面正常展示，于是小明开开心心提交了代码。

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

http://127.0.0.1:9999/?search=<script>alert('你被xss攻击了')</script>

小明带着一种不祥的预感点开了这个链接。果然，页面中弹出了写着 ”你被xss攻击了” 的对话框。

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

当浏览器请求  http://127.0.0.1:9999/?search=<script>alert('你被xss攻击了')</script> 时，服务端会解析出请求参数 search，得到 <scrip``t>alert('你被xss攻击了')</script>，拼接到 HTML 中返回给浏览器。形成了如下的 HTML：

浏览器无法分辨出  <script>alert('你被xss攻击了')</script>  是恶意代码，因而将其执行。

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

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

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

ctx.body = `<p>${escapeHTML(ctx.request.query.search)}</p>

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

|字符|转义后的字符|       |-|-|  |&|&|   |<|<|   |>|>|   |"|"|   |'|'|   |/|/|

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

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

• 攻击者通常利用页面的用户输入片段，拼接特殊格式的字符串，突破原有位置的限制，形成了代码片段。
• 攻击者通过在目标网站上注入脚本，使之在用户的浏览器上运行，通常通过 qq群以链接形式发送，从而引发潜在风险。
• 通过 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('XSS')">跳转...</a>

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

可恶，又失策了…

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

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

小明眉头一皱，想到了解决办法：

// 禁止 URL 以 "javascript:" 开头
xss = getParameter("redirect_to").startsWith('javascript:');
if (!xss) {
  <a href="<%= escapeHTML(getParameter("redirect_to"))%>">
    跳转...
  </a>
} else {
  <a href="/404">
    跳转...
  </a>
}

只要 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) {
  <a href="<%= escapeHTML(getParameter("redirect_to"))%>">
    跳转...
  </a>
} else {
  <a href="/404">
    跳转...
  </a>
}

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

• 做了 HTML 转义，并不等于高枕无忧。
• 对于链接跳转，如 <a href="xxx" 或 location.href="xxx"，要检验其内容，禁止以 javascript: 开头的链接，和其他非法的 url。

某天，小明为了加快网页的加载速度，把一个数据通过 JSON 的方式内联到 HTML 中：

<script>
    var initData = <%= data.toJSON() %>
</script>

但安全组又发现有漏洞，原来这样内联 JSON 也是不安全的：

• 当 JSON 中包含 U+2028 或 U+2029 这两个字符时，不能作为 JavaScript 的字面量使用，否则会抛出语法错误。（Unicode 码）
• 当 JSON 中包含字符串 </script> 时，当前的 script 标签将会被闭合，后面的字符串内容浏览器会按照 HTML 进行解析；通过增加下一个 <script> 标签等方法就可以完成注入。

于是我们又要实现一个 escapeEmbedJSON() 函数，对内联 JSON 进行转义。

转义规则如下：

|字符|转义后的字符|   |U+2028|\u2028|   |U+2029|\u2029|   |<|\u003c|

修复后的代码如下：

var initData = <%= escapeEmbedJSON(data.toJSON()) %>

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

• HTML 转义是非常复杂的，在不同的情况下要采用不同的转义规则。如果采用了错误的转义规则，很有可能会埋下 XSS 隐患。
• 应当尽量避免自己写转义库，而应当采用成熟的、业界通用的转义库。

漏洞总结

小明的例子讲完了，下面我们来系统的看下 XSS 有哪些注入的方法：

• 在 HTML 中内嵌的文本中，恶意内容以 script 标签形成注入。
• 在内联的 JavaScript 中，拼接的数据突破了原本的限制（字符串，变量，方法名等）。
• 在标签属性中，恶意内容包含引号，从而突破属性值的限制，注入其他属性或者标签。
• 在标签的 href、src 等属性中，包含 javascript: 等可执行代码。
• 在 onload、onerror、onclick 等事件中，注入不受控制代码。
• 在 style 属性和标签中，包含类似 background-image:url("javascript:..."); 的代码（新版本浏览器已经可以防范）。
• 在 style 属性和标签中，包含类似 expression(...) 的 CSS 表达式代码（新版本浏览器已经可以防范）。

总之，如果开发者没有将用户输入的文本进行合适的过滤，就贸然插入到 HTML 中，这很容易造成注入漏洞。攻击者可以利用漏洞，构造出恶意的代码指令，进而利用恶意代码危害数据安全。

什么是 XSS

XSS 全称是 Cross Site Scripting（跨站脚本）, 为了与 “CSS” 区分开，故简称 XSS 。XSS 攻击是页面被注入了恶意的代码，从而再用户浏览页面时利用恶意脚本对用户实施攻击的一种手段。

恶意脚本可以做哪些事情

• 可以窃取 Cookie 信息。恶意脚本可以通过 “document.cookie” 获取 Cookie 信息，然后通过 XMLHttpRequest 或者 Fetch 加上 CORS 功能将数据发送给恶意服务器；恶意服务器拿到用户的 Cookie 信息之后，就可以模拟用户登录，然后进行其他操作了。
• 可以监听用户行为，恶意脚本可以使用 “addEventListener" 来监听键盘事件，比如可以获取用户输入的个人信息，将其发送到恶意服务器，黑客掌握这些信息之后，又可以进行其他操作了。
• 可以通过修改 DOM 伪造假的登录窗口，用来欺骗用户输入用户名和密码等个人信息
• 还可以再页面内生成浮窗广告，影响用户体验。

......

XSS 分类

存储型 XSS 攻击

存储型 XSS 的攻击步骤：

1. 攻击者将恶意代码提交到目标网站的数据库中。
2. 用户打开目标网站时，网站服务端将恶意代码从数据库取出，拼接在 HTML 中返回给浏览器。
3. 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
4. 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

这种攻击常见于带有用户保存数据的网站功能，如论坛发帖、商品评论、用户私信等。

反射型 XSS 攻击

反射型 XSS 的攻击步骤：

1. 攻击者构造出特殊的 URL，其中包含恶意代码。
2. 用户打开带有恶意代码的 URL 时，网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。
3. 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
4. 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

与存储型 XSS 攻击的区别：Web 服务器不会存储反射型 XSS 攻击的代码。

基于 DOM 的 XSS 攻击

DOM 型 XSS 的攻击步骤：

1. 攻击者构造出特殊的 URL，其中包含恶意代码。
2. 用户打开带有恶意代码的 URL。
3. 用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。
4. 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

基于 DOM 的 XSS 攻击是不牵涉到页面 Web 服务器的。攻击者通过各种手段将恶意脚本注入到用户页面中，比如通过网络劫持（ Wifi 路由器劫持、本地恶意软件）在页面传输过程中修改 HTML 页面的内容。

备注：https 只能增加攻击难度，不能防止所有场景的基于 DOM 的 XSS 攻击

XSS 攻击的预防

通过前面的介绍可以得知，XSS 攻击有两大要素：

1. 攻击者提交恶意代码。
2. 浏览器执行恶意代码。

针对第一个要素：我们是否能够在用户输入的过程，过滤掉用户输入的恶意代码呢？

输入过滤

在用户提交时，由前端过滤输入，然后提交到后端。这样做是否可行呢？

答案是不可行。一旦攻击者绕过前端过滤，直接构造请求，就可以提交恶意代码了。

那么，换一个过滤时机：后端在写入数据库前，对输入进行过滤，然后把“安全的”内容，返回给前端。这样是否可行呢？

我们举一个例子，一个正常的用户输入了 5 < 7 这个内容，在写入数据库前，被转义，变成了 5 < 7。

问题是：在提交阶段，我们并不确定内容要输出到哪里。

这里的“并不确定内容要输出到哪里”有两层含义：

1. 用户的输入内容可能同时提供给前端和客户端，而一旦经过了 escapeHTML()，客户端显示的内容就变成了乱码( 5 < 7 )。
2. 在前端中，不同的位置所需的编码也不同。

• 当 5 < 7 作为 HTML 拼接页面时，可以正常显示：

<div title="comment">5 < 7</div>

• 当 5 < 7 通过 Ajax 返回，然后赋值给 JavaScript 的变量时，前端得到的字符串就是转义后的字符。这个内容不能直接用于 Vue 等模板的展示，也不能直接用于内容长度计算。不能用于标题、alert 等。

所以，输入侧过滤能够在某些情况下解决特定的 XSS 问题，但会引入很大的不确定性和乱码问题。在防范 XSS 攻击时应避免此类方法。

当然，对于明确的输入类型，例如数字、URL、电话号码、邮件地址等等内容，进行输入过滤还是必要的。

既然输入过滤并非完全可靠，我们就要通过“防止浏览器执行恶意代码”来防范 XSS。这部分分为两类：

• 防止 HTML 中出现注入。
• 防止 JavaScript 执行时，执行恶意代码。

预防存储型和反射型 XSS 攻击

存储型和反射型 XSS 都是在服务端取出恶意代码后，插入到响应 HTML 里的，攻击者刻意编写的“数据”被内嵌到“代码”中，被浏览器所执行。

预防这两种漏洞，有两种常见做法：

• 改成纯前端渲染，把代码和数据分隔开。
• 对 HTML 做充分转义。

纯前端渲染

纯前端渲染的过程：

1. 浏览器先加载一个静态 HTML，此 HTML 中不包含任何跟业务相关的数据。
2. 然后浏览器执行 HTML 中的 JavaScript。
3. JavaScript 通过 Ajax 加载业务数据，调用 DOM API 更新到页面上。

在纯前端渲染中，我们会明确的告诉浏览器：下面要设置的内容是文本（.innerText），还是属性（.setAttribute），还是样式（.style）等等。浏览器不会被轻易的被欺骗，执行预期外的代码了。

但纯前端渲染还需注意避免 DOM 型 XSS 漏洞（例如 onload 事件和 href 中的 javascript:xxx 等，请参考下文 ”预防 DOM 型 XSS 攻击“ 部分）。

在很多内部、管理系统中，采用纯前端渲染是非常合适的。但对于性能要求高，或有 SEO 需求的页面，我们仍然要面对拼接 HTML 的问题。

转义 HTML

如果拼接 HTML 是必要的，就需要采用合适的转义库，对 HTML 模板各处插入点进行充分的转义。

常用的模板引擎，如 doT.js、ejs、FreeMarker 等，对于 HTML 转义通常只有一个规则，就是把 & < > " ' / 这几个字符转义掉，确实能起到一定的 XSS 防护作用，但并不完善。

HTML 的编码是十分复杂的，在不同的上下文里要使用相应的转义规则。

所以要完善 XSS 防护措施，我们要使用更完善更细致的转义策略。

例如 NodeJS 工程里，成熟的常用转义库为 js-xss（Github地址）（使用教程）。

特性：

• 白名单控制允许的 HTML 标签及各标签的属性
• 通过自定义处理函数，可对任意标签及其属性进行处理

预防 DOM 型 XSS 攻击

DOM 型 XSS 攻击，实际上就是网站前端 JavaScript 代码本身不够严谨，把不可信的数据当作代码执行了。

在使用 .innerHTML、.outerHTML、document.write() 时要特别小心，不要把不可信的数据作为 HTML 插到页面上，而应尽量使用 .textContent、.setAttribute() 等。

如果用 Vue/React 技术栈，并且不使用 v-html/dangerouslySetInnerHTML 功能，就在前端 render 阶段避免 innerHTML、outerHTML 的 XSS 隐患。

DOM 中的内联事件监听器，如 location、onclick、onerror、onload、onmouseover 等，<a> 标签的 href 属性，JavaScript 的 eval()、setTimeout()、setInterval() 等，都能把字符串作为代码运行。如果不可信的数据拼接到字符串中传递给这些 API，很容易产生安全隐患，请务必避免。

其他 XSS 防范措施

虽然在渲染页面和执行 JavaScript 时，通过谨慎的转义可以防止 XSS 的发生，但完全依靠开发的谨慎仍然是不够的。以下介绍一些通用的方案，可以降低 XSS 带来的风险和后果。

Content Security Policy（MDN-CSP）

严格的 CSP 在 XSS 的防范中可以起到以下的作用：

• 禁止加载外域代码，防止复杂的攻击逻辑。
• 禁止外域提交，网站被攻击后，用户的数据不会泄露到外域。
• 禁止内联脚本执行（规则较严格，目前发现 GitHub 使用）。
• 禁止未授权的脚本执行（新特性，Google Map 移动版在使用）。
• 合理使用上报可以及时发现 XSS，利于尽快修复问题。

CSP有如下几个功能：

1. 限制加载其他域下的资源文件，这样即使黑客插入了一个 JS 文件，这个文件也是无法被加载的
2. 禁止向第三方域提交数据，这样用户数据也不会外泄
3. 禁止执行内联脚本和未授权脚本
4. 还提供上报机制，这样可以帮助我们尽快发现有哪些 XSS 攻击，以便尽快修复问题。

输入内容长度控制

对于不受信任的输入，都应该限定一个合理的长度。虽然无法完全防止 XSS 发生，但可以增加 XSS 攻击的难度。

其他安全措施

• HTTP-only Cookie: 禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie。
• 验证码：防止脚本冒充用户提交危险操作。

XSS 的检测

上述经历让小明收获颇丰，他也学会了如何去预防和修复 XSS 漏洞，在日常开发中也具备了相关的安全意识。但对于已经上线的代码，如何去检测其中有没有 XSS 漏洞呢？

可以使用自动扫描工具寻找 XSS 漏洞，例如 Arachni、Mozilla HTTP Observatory、w3af 等。

XSS 攻击的总结

我们回到最开始提出的问题，相信同学们已经有了答案：

1. XSS 防范是后端 RD 的责任，后端 RD 应该在所有用户提交数据的接口，对敏感字符进行转义，才能进行下一步操作。

不正确。因为： * 防范存储型和反射型 XSS 是后端 RD 的责任。而 DOM 型 XSS 攻击不发生在后端，是前端 RD 的责任。防范 XSS 是需要后端 RD 和前端 RD 共同参与的系统工程。 * 转义应该在输出 HTML 时进行，而不是在提交用户输入时。

       2. 所有要插入到页面上的数据，都要通过一个敏感字符过滤函数的转义，过滤掉通用的敏感字符后，就可以插入到页面中。

不正确。 不同的上下文，如 HTML 属性、HTML 文字内容、HTML 注释、跳转链接、内联 JavaScript 字符串、内联 CSS 样式表等，所需要的转义规则不一致。 业务 RD 需要选取合适的转义库，并针对不同的上下文调用不同的转义规则。

整体的 XSS 防范是非常复杂和繁琐的，我们不仅需要在全部需要转义的位置，对数据进行对应的转义。而且要防止多余和错误的转义，避免正常的用户输入出现乱码。

XSS 攻击小游戏

以下是几个 XSS 攻击小游戏，开发者在网站上故意留下了一些常见的 XSS 漏洞。玩家在网页上提交相应的输入，完成 XSS 攻击即可通关。

在玩游戏的过程中，加深对 XSS 攻击的理解。

alert(1) to win    prompt(1) to win     XSS game

最后

没有绝对安全的系统，所以我们只能尽量做到知道原理，然后预防，提高攻击难度。

技术本身是个好东西，但是好技术要用在对的地方才能显示出它的价值