关于前端:浅谈-React-中的-XSS-攻击

3次阅读

共计 5784 个字符,预计需要花费 15 分钟才能阅读完成。

70 篇原创好文~
本文首发于政采云前端团队博客:浅谈 React 中的 XSS 攻打

前言

前端个别会面临 XSS 这样的平安危险,但随着 React 等古代前端框架的风行,使咱们在平时开发时不必太关注平安问题。以 React 为例,React 从设计层面上就具备了很好的进攻 XSS 的能力。本文将以源码角度,看看 React 做了哪些事件来实现这种安全性的。

XSS 攻打是什么

Cross-Site Scripting(跨站脚本攻打)简称 XSS,是一种代码注入攻打。XSS 攻打通常指的是利用网页的破绽,攻击者通过奇妙的办法注入 XSS 代码到网页,因为浏览器无奈分辨哪些脚本是可信的,导致 XSS 脚本被执行。XSS 脚本通常可能窃取用户数据并发送到攻击者的网站,或者假冒用户,调用指标网站接口并执行攻击者指定的操作。

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

该破绽存在于客户端代码,与服务器无关

  • 相似反射型,区别在于 DOM 型 XSS 并不会和后盾进行交互,前端间接将 URL 中的数据不做解决并动静插入到 HTML 中,是纯正的前端平安问题,要做进攻也只能在客户端上进行进攻。

React 如何避免 XSS 攻打

无论应用哪种攻击方式,其本质就是将恶意代码注入到利用中,浏览器去默认执行。React 官网中提到了 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,以下为这几个步骤对应的代码:

// 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 注入,来看上面一段代码:

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

正文完
 0