浅谈 React 中的 XSS 攻击

时间 2020-09-22

标签浅谈 react xss 攻击栏目 React 繁體版

原文原文链接

第 70 篇原创好文～
本文首发于政采云前端团队博客：浅谈 React 中的 XSS 攻击

前言

前端通常会面临 XSS 这样的安全风险，但随着 React 等现代前端框架的流行，使咱们在平时开发时不用太关注安全问题。以 React 为例，React 从设计层面上就具有了很好的防护 XSS 的能力。本文将以源码角度，看看 React 作了哪些事情来实现这种安全性的。javascript

XSS 攻击是什么

Cross-Site Scripting（跨站脚本攻击）简称 XSS，是一种代码注入攻击。XSS 攻击一般指的是利用网页的漏洞，攻击者经过巧妙的方法注入 XSS 代码到网页，由于浏览器没法分辨哪些脚本是可信的，致使 XSS 脚本被执行。XSS 脚本一般可以窃取用户数据并发送到攻击者的网站，或者冒充用户，调用目标网站接口并执行攻击者指定的操做。css

XSS 攻击类型

反射型 XSS

XSS 脚原本自当前 HTTP 请求
当服务器在 HTTP 请求中接收数据并将该数据拼接在 HTML 中返回时，例子：

// 某网站具备搜索功能，该功能经过 URL 参数接收用户提供的搜索词：
   https://xxx.com/search?query=123
   // 服务器在对此 URL 的响应中回显提供的搜索词：
   <p>您搜索的是: 123</p>
   // 若是服务器不对数据进行转义等处理，则攻击者能够构造以下连接进行攻击：
   https://xxx.com/search?query=<img src="empty.png" onerror ="alert('xss')">
   // 该 URL 将致使如下响应，并运行 alert('xss')：
   <p>您搜索的是: <img src="empty.png" onerror ="alert('xss')"></p>
   // 若是有用户请求攻击者的 URL ，则攻击者提供的脚本将在用户的浏览器中执行。

存储型 XSS

XSS 脚原本自服务器数据库中
攻击者将恶意代码提交到目标网站的数据库中，普通用户访问网站时服务器将恶意代码返回，浏览器默认执行，例子：

// 某个评论页，能查看用户评论。
   // 攻击者将恶意代码当作评论提交，服务器没对数据进行转义等处理
   // 评论输入：
   <textarea>
      <img src="empty.png" onerror ="alert('xss')">
   </textarea>
   // 则攻击者提供的脚本将在全部访问该评论页的用户浏览器执行

DOM 型 XSS

该漏洞存在于客户端代码，与服务器无关html

相似反射型，区别在于 DOM 型 XSS 并不会和后台进行交互，前端直接将 URL 中的数据不作处理并动态插入到 HTML 中，是纯粹的前端安全问题，要作防护也只能在客户端上进行防护。

React 如何防止 XSS 攻击

不管使用哪一种攻击方式，其本质就是将恶意代码注入到应用中，浏览器去默认执行。React 官方中提到了 React DOM 在渲染全部输入内容以前，默认会进行转义。它能够确保在你的应用中，永远不会注入那些并不是本身明确编写的内容。全部的内容在渲染以前都被转换成了字符串，所以恶意代码没法成功注入，从而有效地防止了 XSS 攻击。咱们具体看下：前端

自动转义

React 在渲染 HTML 内容和渲染 DOM 属性时都会将 "'&<> 这几个字符进行转义，转义部分源码以下：java

for (index = match.index; index < str.length; index++) {
    switch (str.charCodeAt(index)) {
      case 34: // "
        escape = '&quot;';
        break;
      case 38: // &
        escape = '&amp;';
        break;
      case 39: // '
        escape = '&#x27;';
        break;
      case 60: // <
        escape = '&lt;';
        break;
      case 62: // >
        escape = '&gt;';
        break;
      default:
        continue;
    }
  }

这段代码是 React 在渲染到浏览器前进行的转义，能够看到对浏览器有特殊含义的字符都被转义了，恶意代码在渲染到 HTML 前都被转成了字符串，以下：react

// 一段恶意代码
<img src="empty.png" onerror ="alert('xss')"> 
// 转义后输出到 html 中
&lt;img src=&quot;empty.png&quot; onerror =&quot;alert(&#x27;xss&#x27;)&quot;&gt;

这样就有效的防止了 XSS 攻击。数据库

JSX 语法

JSX 其实是一种语法糖，Babel 会把 JSX 编译成 React.createElement() 的函数调用，最终返回一个 ReactElement，如下为这几个步骤对应的代码：后端

// JSX
const element = (
  <h1 className="greeting">
      Hello, world!
  </h1>
);
// 经过 babel 编译后的代码
const element = React.createElement(
  'h1',
  {className: 'greeting'},
  'Hello, world!'
);
// React.createElement() 方法返回的 ReactElement
const element = {
  $$typeof: Symbol('react.element'),
  type: 'h1',
  key: null,
  props: {
    children: 'Hello, world!',
        className: 'greeting'   
  }
  ...
}

咱们能够看到，最终渲染的内容是在 Children 属性中，那了解了 JSX 的原理后，咱们来试试可否经过构造特殊的 Children 进行 XSS 注入，来看下面一段代码：promise

const storedData = `{
    "ref":null,
    "type":"body",
    "props":{
        "dangerouslySetInnerHTML":{
            "__html":"<img src=\"empty.png\" onerror =\"alert('xss')\"/>"
        }
    }
}`;
// 转成 JSON
const parsedData = JSON.parse(storedData);
// 将数据渲染到页面
render () {
    return <span> {parsedData} </span>; 
}

这段代码中，运行后会报如下错误，提示不是有效的 ReactChild。浏览器

Uncaught (in promise) Error: Objects are not valid as a React child (found: object with keys {ref, type, props}). If you meant to render a collection of children, use an array instead.

那到底是哪里出问题了？咱们看一下 ReactElement 的源码：

const symbolFor = Symbol.for;
REACT_ELEMENT_TYPE = symbolFor('react.element');
const ReactElement = function(type, key, ref, self, source, owner, props) {
  const element = {
    // 这个 tag 惟一标识了此为 ReactElement
    $$typeof: REACT_ELEMENT_TYPE,
    // 元素的内置属性
    type: type,
    key: key,
    ref: ref,
    props: props,
    // 记录建立此元素的组件
    _owner: owner,
  };
  ...
  return element;
}

注意到其中有个属性是 $$typeof`，它是用来标记此对象是一个 `ReactElement`，React 在进行渲染前会经过此属性进行校验，校验不经过将会抛出上面的错误。React 利用这个属性来防止经过构造特殊的 Children 来进行的 XSS 攻击，缘由是 `$$typeof 是个 Symbol 类型，进行 JSON 转换后会 Symbol 值会丢失，没法在先后端进行传输。若是用户提交了特殊的 Children，也没法进行渲染，利用此特性，能够防止存储型的 XSS 攻击。

在 React 中可引发漏洞的一些写法

使用 dangerouslySetInnerHTML

dangerouslySetInnerHTML 是 React 为浏览器 DOM 提供 innerHTML 的替换方案。一般来说，使用代码直接设置 HTML 存在风险，由于很容易使用户暴露在 XSS 攻击下，由于当使用 dangerouslySetInnerHTML 时，React 将不会对输入进行任何处理并直接渲染到 HTML 中，若是攻击者在 dangerouslySetInnerHTML 传入了恶意代码，那么浏览器将会运行恶意代码。看下源码：

function getNonChildrenInnerMarkup(props) {
  const innerHTML = props.dangerouslySetInnerHTML; // 有dangerouslySetInnerHTML属性，会不经转义就渲染__html的内容
  if (innerHTML != null) {
    if (innerHTML.__html != null) {
      return innerHTML.__html;
    }
  } else {
    const content = props.children;
    if (typeof content === 'string' || typeof content === 'number') {
      return escapeTextForBrowser(content);
    }
  }
  return null;
}

因此平时开发时最好避免使用 dangerouslySetInnerHTML，若是不得不使用的话，前端或服务端必须对输入进行相关验证，例如对特殊输入进行过滤、转义等处理。前端这边处理的话，推荐使用白名单过滤，经过白名单控制容许的 HTML 标签及各标签的属性。

经过用户提供的对象来建立 React 组件

举个例子：

// 用户的输入
const userProvidePropsString = `{"dangerouslySetInnerHTML":{"__html":"<img onerror='alert(\"xss\");' src='empty.png' />"}}"`;
// 通过 JSON 转换
const userProvideProps = JSON.parse(userProvidePropsString);
// userProvideProps = {
//   dangerouslySetInnerHTML: {
//     "__html": `<img onerror='alert("xss");' src='empty.png' />`
//      }
// };
render() {
     // 出于某种缘由解析用户提供的 JSON 并将对象做为 props 传递
    return <div {...userProvideProps} /> 
}

这段代码将用户提供的数据进行 JSON 转换后直接当作 div 的属性，当用户构造了相似例子中的特殊字符串时，页面就会被注入恶意代码，因此要注意平时在开发中不要直接使用用户的输入做为属性。

使用用户输入的值来渲染 a 标签的 href 属性，或相似 img 标签的 src 属性等

const userWebsite = "javascript:alert('xss');";
<a href={userWebsite}></a>

若是没有对该 URL 进行过滤以防止经过 javascript: 或 data: 来执行 JavaScript，则攻击者能够构造 XSS 攻击，此处会有潜在的安全问题。
用户提供的 URL 须要在前端或者服务端在入库以前进行验证并过滤。

服务端如何防止 XSS 攻击

服务端做为最后一道防线，也须要作一些措施以防止 XSS 攻击，通常涉及如下几方面：

在接收到用户输入时，须要对输入进行尽量严格的过滤，过滤或移除特殊的 HTML 标签、JS 事件的关键字等。
在输出时对数据进行转义，根据输出语境 (html/javascript/css/url)，进行对应的转义
对关键 Cookie 设置 http-only 属性，JS 脚本就不能访问到 http-only 的 Cookie 了
利用 CSP 来抵御或者削弱 XSS 攻击，一个 CSP 兼容的浏览器将会仅执行从白名单域获取到的脚本文件，忽略全部的其余脚本 (包括内联脚本和 HTML 的事件处理属性)

总结

出现 XSS 漏洞本质上是输入输出验证不充分，React 在设计上已经很安全了，可是一些反模式的写法仍是会引发安全漏洞。Vue 也是相似，Vue 作的安全措施主要也是转义，HTML 的内容和动态绑定的属性都会进行转义。不管使用 React 或 Vue 等前端框架，都不能百分百的防止 XSS 攻击，因此服务端必须对前端参数作一些验证，包括但不限于特殊字符转义、标签、属性白名单过滤等。一旦出现安全问题通常都是挺严重的，不论是敏感数据被窃取或者用户资金被盗，损失每每没法挽回。咱们平时开发中须要保持安全意识，保持代码的可靠性和安全性。

小游戏

看完文章能够尝试下 XSS 的小游戏，本身动手实践模拟 XSS 攻击，能够对 XSS 有更进一步的认识。

招贤纳士

政采云前端团队（ZooTeam），一个年轻富有激情和创造力的前端团队，隶属于政采云产品研发部，Base 在风景如画的杭州。团队现有 50 余个前端小伙伴，平均年龄 27 岁，近 3 成是全栈工程师，妥妥的青年风暴团。成员构成既有来自于阿里、网易的“老”兵，也有浙大、中科大、杭电等校的应届新人。团队在平常的业务对接以外，还在物料体系、工程平台、搭建平台、性能体验、云端应用、数据分析及可视化等方向进行技术探索和实战，推进并落地了一系列的内部技术产品，持续探索前端技术体系的新边界。

若是你想改变一直被事折腾，但愿开始能折腾事；若是你想改变一直被告诫须要多些想法，却无从破局；若是你想改变你有能力去作成那个结果，却不须要你；若是你想改变你想作成的事须要一个团队去支撑，但没你带人的位置；若是你想改变既定的节奏，将会是“5 年工做时间 3 年工做经验”；若是你想改变原本悟性不错，但老是有那一层窗户纸的模糊… 若是你相信相信的力量，相信平凡人能成就非凡事，相信能遇到更好的本身。若是你但愿参与到随着业务腾飞的过程，亲手推进一个有着深刻的业务理解、完善的技术体系、技术创造价值、影响力外溢的前端团队的成长历程，我以为咱们该聊聊。任什么时候间，等着你写点什么，发给 ZooTeam@cai-inc.com