React这个前端框架大家都很熟悉，但或许很多人不知道它能防御XSS，又或许知道但印象不深。直到最近，我才重新了解到React有这个能力。于是我会想，React是如何防御XSS的？我们在项目里用上了React就不用关注XSS攻击了吗？这篇文章将会逐一回答。

Cross Site Script，跨站脚本攻击，为了区分层叠式样式表（Cascading Style Sheet，CSS），改叫XSS。一开始这种攻击的演示案例是跨域的，但发展到现在，无论是否跨域，都有可能受到XSS的攻击。

XSS的定义：黑客往用户页面注入恶意脚本，但用户网站没有做任何处理，浏览器也无法判断脚本是否可信，从而让黑客修改了用户页面或者获取了cookies、session tokens等敏感的用户信息。

XSS是一种注入式攻击。

早期XSS分为3种类型：反射型、存储型、DOM Based型。

服务器直接从用户请求里取出恶意代码返回给用户，主打一个“反射”。

典型攻击步骤：

场景： 假设我们在某社交网站A上搜索内容，就会跳转以下页面。

这个页面的html包含以下内容。

如果黑客构造出以下url，并隐藏在邮件里发送给用户。

当用户点击该url，跳转到社交网站A后，页面会出现弹窗。

服务端从数据库或者消息队列等存储介质中取出恶意代码返回给用户，主打一个“存储”。它跟反射型XSS的区别在于是否有持久化储存。

典型攻击步骤：

场景： 比较典型的就是一些论坛上，黑客的评论内容里包含恶意脚本，提交后保存到数据库。当用户访问帖子时，返回的页面包含该脚本，用户受到攻击。

客户端执行js将恶意代码插入页面，比如使用eval()、innerHTML、document.write()等不安全的API。

典型攻击步骤：

场景： 和上面反射型XSS的场景类似，只不过是由js取出query参数，并插入到页面中。

DOM Based XSS又可以分为反射型DOM Based XSS和存储型DOM Based XSS，而反射型XSS和存储型XSS又都可以分为DOM Based的和非DOM Based的，因此前面3种XSS在概念上有重叠部分。

所以后来人们按由谁取得恶意代码并插入html中，将XSS分为Client型和Server型两类。

Server型XSS，无论从请求还是数据库中取出恶意代码，都是由服务端将恶意代码组装到html的。

Client型XSS，根本原因是前端js代码的安全漏洞，才导致用户受攻击。

前面说的反射型XSS和存储型XSS属于Server型，DOM Based XSS属于Client型。

总得来说，就是用script标签、href属性、onload等事件回调插入脚本。

css的url('javascript:alert(1)')语句在现在的主流浏览器上已经不会造成XSS攻击。

在可能插入的地方对内容进行html转义，可以避免以下XSS攻击：

小心使用.innerHTML、.outerHTML、document.write()等方法，它们很容易带来XSS攻击，使用.innerText、.textContent等方法会更安全。

内容安全策略（Content Security Policy），可信白名单机制，通过设置http头部或者配置开启，禁止不可信来源的内容的加载和执行。

XSS攻击一般是为了窃取用户信息。将cookie标记为http-only，避免恶意脚本获取cookie。

主要是上面提到XSS常见防御手段的前两种。

React防御XSS，关键在于jsx的处理上。

XSS分为Client型和Server型，React在客户端和服务端对XSS的防御方式又不一样。所以下面会从Client和Server两个方面分析。

我们知道，jsx实际上是React.createElement的语法糖，每一个元素在插入html之前都要先转成下面格式的对象：

记住这个知识点。下面就来讲React客户端如何防御XSS。

注意，不应该使用.innerHTML代替.textContent来插入内容。

因为React是这样创建script元素的：

即通过.innerHTML的方式插入使得它不可执行。

使用dangerouslySetInnerHTML属性插入也不行，因为底层也是调用.innerHTML。

主要关注React服务端生成html时做了哪些事情。

虽然React在客户端和服务端都有做一些事情来防御XSS，但它依然有漏洞。

在一些场景下，我们的确需要直接往页面插入html代码。React为我们提供dangerouslySetInnerHTML属性来实现这个功能，这有可能造成XSS攻击。

虽然属性名dangerouslySetInnerHTML和对象结构{__html: string}都在提醒开发者要谨慎使用，但有些情况还是容易蒙蔽开发者的眼睛。

比如，如果我们把后端接口返回的数据直接当作属性赋给元素，而这个数据又包含dangerouslySetInnerHTML属性，就可能造成XSS攻击。这种情况开发者是很难注意到的。

另外一种隐藏dangerouslySetInnerHTML的方式是给将一个React element对象直接作为children插入。

jsx转换过程中每一个元素和它的子元素都会递归地转成React的element对象。所以，我们可以考虑这样手动构造对象，插入到jsx：

但这样会报错：

原因在于React会校验$$typeof是否为合法值。所以有些人认为这也是React防御XSS的一种手段。诚然，这有一定效果。但因为React使用Symbol.for()而不是Symbol()来生成它的节点类型，我们完全能够构造出合法的$$typeof。比如：

这是第二种隐藏dangerouslySetInnerHTML并插入恶意代码的方式。不过，因为Symbol是不可以被Json序列化的，所以我们不用担心将接口返回的数据直接当作children插入jsx会导致XSS攻击。

a标签的href属性就是一个很好的例子，如果我们将后端接口返回的url直接赋给href，就可能造成XSS攻击。

总的来说，接口数据用在props和children时，我们要多留一个心眼。

React作为一个著名的前端框架，它在XSS防御上也做了不少事情，比如特殊字符转义、使用安全的API修改DOM、禁止执行。

可以说，React在它的领域范围内已经尽可能地帮我们防住了XSS攻击。

但这并不代表我们在React项目开发中可以高枕无忧。在一些可以执行代码或者利用dangerouslySetInnerHTML的地方，我们需要提高警惕，无法确保数据安全时需要做好防范措施。