How Much XSS Vulnerability Protection is React Responsible For?

[sebmarkbage]

There was a security hack that mentions React here: http://danlec.com/blog/xss-via-a-spoofed-react-element

Ultimately this is a server-side bug and NOT a bug in React itself. This issue is about figuring out if there is something we can do to mitigate issues when you have a JSON parsing bug or some server-side issue.

isValidElement

React is designed to work with plain objects as input, and in fact, we're even getting rid of the _isReactElement as a way to verify this. We'll allow any JSON object. IMO, there is no problem with the verification here.

All string values are sanitized before inserted into the DOM (except for CSS styles which is a known wontfix issue for IE8).

In earlier versions we used instanceof checks but that didn't work well with multiple Reacts, it makes it difficult to optimize (inline objects are much faster) and couples JSX permanently to React, which we would like to avoid.

dangerouslySetInnerHTML

One possible solution is to disable this feature and require it to be used imperatively (React.findDOMNode(ref).innerHTML = '') which makes for worse performance at insertion time.

However, I don't believe this is the only bad thing once you can insert arbitrary HTML tags. It is certainly the easiest way to gain access to XSS though. You can also insert arbitrary Web Components which could expose data. You can render form elements that can potentially pass data.

What else can we do?

Ultimately this is an issue where <div>{userData}</div> seems like a valid use case, but if your userData is compromised, it becomes dangerous.

Should React be responsible for protecting itself against arbitrary JSON as children?

[yukinying]

Hi, Albert from Yahoo Security team here. I was working with @mridgway on studying this issue. Just wanna share more thoughts.

Re: disabling dangeriouslySetInnerHTML, it is a good move, but it would not be sufficient. React allow inject "script" and "style" tag, or "style" attributes. All of those would allow script execution. Also, in general, we worried about UI redressing attack that attackers can create arbitrary overlay on a page that could steal all the input submitted.

[sebmarkbage]

I don't think "script" tags will execute because we use innerHTML to create them. Do the "style" tag and "style" attributes allow you to execute (in context) scripts in modern browsers? I think it is only older versions of IE.

Regardless, the UI redressing attack is still an equally valid concern.

[yukinying]

I was also having the same doubt on script tag when I saw that it was supported in facebook.github.io/react/docs/tags-and-attributes.html, and then I figured out that script tag is used in server side react and it would be executable. And indeed most style attacks only works in IE8 or minor. But it still contributes to quite some amount of traffic.

[yukinying]

I am more inclined to see _isReactElement be used as a validation mechanism. The issue here is that we can't easily distinguish if an JSON object would have execution context or data context. While it is true that server side validation could help, it only works if every time we get an JSON we have a schema to validate it. The nature of JSON, as you suggested, is plain and free form. Otherwise it will be falling back as XML validation that would discourage developers to use it.

In a nutshell, we really need a way to distinguish if a JSON object has executable context (i.e. _isReactElement). Thanks!

[mattapperson]

None... I think React should stay as light and lean as it can be. Unix philosophy fan here.

[sebmarkbage]

Note that JSON rendering of a virtual DOM tree is a perfectly valid use case. E.g. you can prerender a high level component into a smaller level virtual DOM tree on the server and then render the result on the client. This is also one of the ideas we had for web worker rendering where it would construct a virtual DOM that can be postMessaged and rendered on the other side.

Therefore, we also have to consider what options we have if we chose not to protect ourselves against JSON data. How much can we mitigate that scenario?

[graue]

Possible solution, use different syntax for inserting strings as children:

• <span>{=this.props.username}</span>: Coerces username to a string.
• <a href={this.props.url}> .. </a>: Coerces url to a string (as now).
• <div>{this.renderFooter()}</div>: If this.renderFooter() returns a string or number, warns in 0.14, error in 0.15. Explicitly wrap in a span or use {=str}.

Feels ugly but would solve the problem, wouldn't it?

[sebmarkbage]

Coercion doesn't catch mistakes where you miss it. We would need to make that a requirement, e.g. by wrapping strings in some placeholder that is distinct from elements: { __thisIsSupposeToBeAString: str }

[graue]

That's why I suggested making it an error to pass a string to the non-coercing syntax (plain {}).

[sebmarkbage]

I see. That would be difficult to enforce since they can come nested arrays or non-JSX sources.

[monsanto]

dangerouslySetInnerHTML is really useful when interfacing with existing Markdown libraries. (I know of one that generates React elements, but that isn't the point I'm trying to make.) Removing this feature over a bug that isn't even React's fault seems pretty scorched earth to me.

[syranide]

@sebmarkbage As schemaless storages are becoming somewhat popular, this is going to become more prevalent. At some level it is a repeat of inserting foreign HTML markup as a result of lack of escaping (React made it a goal to make it a thing of the past), but instead the vulnerability moved to React components where wrongly typed values can lead to insertion of foreign hierarchies.

I'd argue that even if we could somehow guarantee that insertion of foreign hierarchies wouldn't be dangerous, it would always be very bad. Malicious data will always wreak havoc on a system and React is just one part of it. The danger I see with React being targeted (apart from being easily exploited due to being debuggable client-side) is malicious data being rendered for other users of the same system, it's hard to guarantee that the malcious data won't be able to act freely under the assumed identity of those users.

---

I think the way forward is to drop implicit wrapping of primitive values. Printable values should be elements like everything else from React's perspective, they should not be implicitly wrapped like they are today. A printable value should look something like React.createValue('foobar') => {type: 'value', props: 'foobar'}, it's still serializable but it's not exploitable. JSX could have some simple syntax sugar for it too, say {=foobar}, and inline text would be automatically wrapped.

While it may seem rather draconian in a sense, I think this is the sensible way forward, HTML introduced a lot of conviences that turned out to be really inconvenient (for user interfaces), this is another one. I think the practical implication of this is not as bad as it seems; any sensible user interface backend would expose labels as <label value={...} />, buttons as <button label={...} />, etc. React.createValue would be largely exclusive to rich-text components where it actually makes sense.

[glenjamin]

I think the way forward is to drop implicit wrapping of primitive values.

I think to provide safety it would actually have to be the reverse - it should be easier to render a primitive value than to render a component. This is the approach that other front-end frameworks have converged on over time.

For instance <p>{user.name}</p> should always be a primitive render, which is known to be safe. The potentially unsafe version should look different, which causes the reader/author to look more closely, eg. <p>{!:user.name:!}</p> or something similarly wacky. This is possibly too much of a departure from the current way of doing things to be viable?

Note that JSON rendering of a virtual DOM tree is a perfectly valid use case.
In a nutshell, we really need a way to distinguish if a JSON object has executable context (i.e. _isReactElement). Thanks!
React is designed to work with plain objects as input, and in fact, we're even getting rid of the _isReactElement as a way to verify this.

These are conflicting goals, so I think React would have to make a clear choice here, the options I can think of are:

1. Decide that all data is renderable, and increase documentation warning about this
2. Decide that all data is primitive by default, and introduce new JSX syntax to render data intended to be non-primitive
3. Find a way to mark data as "safe".

For point 3, to support the JSON cases, as well as createElement, there might need to be some sort of hydrateElement which can take a plain object and mark it as safe to render eg. <p>{React.hydrateElement(someJSONobj)}</p>.

As proved by the bug which prompted the discussion, a boolean property is not enough to mark some data as executable, as I understand it, the only "safe" option would be an object reference, perhaps something like {type: "div", React: React}, which can be checked using React === React at render-time. This re-introduces the multiple-react problem discussed above, and while that could be alleviated slightly by sharing some arbitrary flag object via global (window || global).___reactMarker = {}, this doesn't really help for iframes, web workers, or multiple windows.

A bit of a brain dump, (1) seems simplest but unsafe. (2) is safest but a large change, (3) seems fiddly and error prone.

Hopefully someone else has a better idea!