第 70 篇原创好文~
本文首发于政采云前端团队博客: 浅谈 React 中的 XSS 攻击
![]()
前端通常会面临 XSS 这样的安全风险,但随着 React 等现代前端框架的流行,使咱们在平时开发时不用太关注安全问题。以 React 为例,React 从设计层面上就具有了很好的防护 XSS 的能力。本文将以源码角度,看看 React 作了哪些事情来实现这种安全性的。javascript
Cross-Site Scripting(跨站脚本攻击)简称 XSS,是一种代码注入攻击。XSS 攻击一般指的是利用网页的漏洞,攻击者经过巧妙的方法注入 XSS 代码到网页,由于浏览器没法分辨哪些脚本是可信的,致使 XSS 脚本被执行。XSS 脚本一般可以窃取用户数据并发送到攻击者的网站,或者冒充用户,调用目标网站接口并执行攻击者指定的操做。css
// 某网站具备搜索功能,该功能经过 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 ,则攻击者提供的脚本将在用户的浏览器中执行。
// 某个评论页,能查看用户评论。 // 攻击者将恶意代码当作评论提交,服务器没对数据进行转义等处理 // 评论输入: <textarea> <img src="empty.png" onerror ="alert('xss')"> </textarea> // 则攻击者提供的脚本将在全部访问该评论页的用户浏览器执行
该漏洞存在于客户端代码,与服务器无关html
不管使用哪一种攻击方式,其本质就是将恶意代码注入到应用中,浏览器去默认执行。React 官方中提到了 React DOM 在渲染全部输入内容以前,默认会进行转义。它能够确保在你的应用中,永远不会注入那些并不是本身明确编写的内容。全部的内容在渲染以前都被转换成了字符串,所以恶意代码没法成功注入,从而有效地防止了 XSS 攻击。咱们具体看下:前端
React 在渲染 HTML 内容和渲染 DOM 属性时都会将 "'&<>
这几个字符进行转义,转义部分源码以下:java
for (index = match.index; index < str.length; index++) { switch (str.charCodeAt(index)) { case 34: // " escape = '"'; break; case 38: // & escape = '&'; break; case 39: // ' escape = '''; break; case 60: // < escape = '<'; break; case 62: // > escape = '>'; break; default: continue; } }
这段代码是 React 在渲染到浏览器前进行的转义,能够看到对浏览器有特殊含义的字符都被转义了,恶意代码在渲染到 HTML 前都被转成了字符串,以下:react
// 一段恶意代码 <img src="empty.png" onerror ="alert('xss')"> // 转义后输出到 html 中 <img src="empty.png" onerror ="alert('xss')">
这样就有效的防止了 XSS 攻击。数据库
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 攻击。
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 标签及各标签的属性。
举个例子:
// 用户的输入 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
的属性,当用户构造了相似例子中的特殊字符串时,页面就会被注入恶意代码,因此要注意平时在开发中不要直接使用用户的输入做为属性。
const userWebsite = "javascript:alert('xss');"; <a href={userWebsite}></a>
若是没有对该 URL 进行过滤以防止经过 javascript:
或 data:
来执行 JavaScript,则攻击者能够构造 XSS 攻击,此处会有潜在的安全问题。
用户提供的 URL 须要在前端或者服务端在入库以前进行验证并过滤。
服务端做为最后一道防线,也须要作一些措施以防止 XSS 攻击,通常涉及如下几方面:
出现 XSS 漏洞本质上是输入输出验证不充分,React 在设计上已经很安全了,可是一些反模式的写法仍是会引发安全漏洞。Vue 也是相似,Vue 作的安全措施主要也是转义,HTML 的内容和动态绑定的属性都会进行转义。不管使用 React 或 Vue 等前端框架,都不能百分百的防止 XSS 攻击,因此服务端必须对前端参数作一些验证,包括但不限于特殊字符转义、标签、属性白名单过滤等。一旦出现安全问题通常都是挺严重的,不论是敏感数据被窃取或者用户资金被盗,损失每每没法挽回。咱们平时开发中须要保持安全意识,保持代码的可靠性和安全性。
看完文章能够尝试下 XSS 的小游戏,本身动手实践模拟 XSS 攻击,能够对 XSS 有更进一步的认识。
政采云前端团队(ZooTeam),一个年轻富有激情和创造力的前端团队,隶属于政采云产品研发部,Base 在风景如画的杭州。团队现有 50 余个前端小伙伴,平均年龄 27 岁,近 3 成是全栈工程师,妥妥的青年风暴团。成员构成既有来自于阿里、网易的“老”兵,也有浙大、中科大、杭电等校的应届新人。团队在平常的业务对接以外,还在物料体系、工程平台、搭建平台、性能体验、云端应用、数据分析及可视化等方向进行技术探索和实战,推进并落地了一系列的内部技术产品,持续探索前端技术体系的新边界。
若是你想改变一直被事折腾,但愿开始能折腾事;若是你想改变一直被告诫须要多些想法,却无从破局;若是你想改变你有能力去作成那个结果,却不须要你;若是你想改变你想作成的事须要一个团队去支撑,但没你带人的位置;若是你想改变既定的节奏,将会是“5 年工做时间 3 年工做经验”;若是你想改变原本悟性不错,但老是有那一层窗户纸的模糊… 若是你相信相信的力量,相信平凡人能成就非凡事,相信能遇到更好的本身。若是你但愿参与到随着业务腾飞的过程,亲手推进一个有着深刻的业务理解、完善的技术体系、技术创造价值、影响力外溢的前端团队的成长历程,我以为咱们该聊聊。任什么时候间,等着你写点什么,发给 ZooTeam@cai-inc.com