Stories by Ron Perris on Medium

Avoiding XSS via Markdown in React

Ron Perris — Thu, 19 Apr 2018 23:44:30 GMT

Using Markdown with Sanitization

Websites often use Markdown to allow their users to create content. It provides a lightweight markup language that can be converted to HTML and other formats by many common libraries.

There has been some recent discussion in the news about Markdown based XSS exploits in major websites like Pastebin.

We also heard about this Markdown XSS issue during a recent presentation at the LocoMoco Security Conference.

The root of the issue it that Markdown specification actively encourages HTML in Markdown, but that isn’t a good default for sites who are worried about code injection attacks.

Markdown Converts to HTML

// Markdown Input

Heading
=======

// HTML Output

<h1>Headingh1>

Some developers choose Markdown over HTML because they feel that it will help them avoid code injection attacks like XSS. Markdown doesn’t provide any security benefits by default.

In fact the most popular Markdown parsing library on npm, called marked, by default doesn’t sanitize or escape HTML content found within Markdown text when making a conversion. This is also what the standard encourages.

// Markdown Input

Heading
=======

// HTML Output

Heading

The JavaScript Markdown conversion library name marked has 1,054,581 downloads in the last 7 days and the npm hosted webpage for the project doesn’t mention security or sanitization. If you click some links and visit the projects home page you will find this message.

Security

The only completely secure system is the one that doesn’t exist in the first place. Having said that, we take the security of Marked very seriously.

Code Injection via Unsanitized Markdown (The Default)

Using the code example from the marked webpage we can add a XSS payload to the innerHTML of an element in the DOM and perform a XSS attack. This is the default behavior of the library. It just forwards on any HTML that is found in the source text and puts it directly into the results after converting the Markdown tags to HTML.




  
  Marked in the browser

Opting in to Markdown Sanitization

Marked knows how to safely handle XSS payloads in the Markdown text, you just need to opt-in to that behavior. It is three clicks from the npm page on the advanced configuration page.

myMarked.setOptions({
renderer: new myMarked.Renderer(),
highlight: function(code) {
return require('highlight.js').highlightAuto(code).value;
},
pedantic: false,
gfm: true,
tables: true,
breaks: false,
sanitize: false,
smartLists: true,
smartypants: false,
xhtml: false
});

// Compile
console.log(myMarked('I am using __markdown__.'));

If you read through the list of options passed into setOptions you can see that the sanitize property defaults to false. If you would like marked to prevent XSS attacks in your Markdown you just have to set that value to true.

marked.setOptions({ sanitize: true })
marked('')
// Returns "<img src=x onerror=alert(1)></img>
"

The fine author of the marked package got the XSS sanitization right, the sanitization works, if you opt-in for it.

Injection Attacks in React Components with Sanitization Turned On

I found a popular React component module on npm called react-marked-markdown. It allows you to make React components that render Markdown. It uses the marked library we talked about earlier under the hood.

The react-marked-markdown module was downloaded 972 times last week. It mentions on the npm page that it used the sanitize: true option from marked by default.

Unfortunately, if you use the react-marked-markdown module you will be vulnerable to XSS attacks even with the sanitize: true option.

import { MarkdownPreview } from 'react-marked-markdown'

const spike = '[XSS](javascript: alert`1`)'

const Post = ({ post }) => (
  
    {post.title}

          markedOptions={{
        gfm: true,
        tables: true,
        breaks: false,
        pedantic: false,
        sanitize: true,
        smartLists: true,
        smartypants: false
      }}
      value={post.content}
    />
  

)

This is where things get interesting. It is possible that the marked npm package contains the correct sanitization logic but when the marked package is used by the react-marked-markdown module it is still vulnerable. Let me show you how this can happen. This is the code from the marked library that handles sanitization of links.

// https://github.com/markedjs/marked/blob/master/lib/marked.js#L973

Renderer.prototype.link = function(href, title, text) {
  if (this.options.sanitize) {
    try {
      var prot = decodeURIComponent(unescape(href))
        .replace(/[^\w:]/g, '')
        .toLowerCase()
    } catch (e) {
      return text
    }
    if (
      prot.indexOf('javascript:') === 0 ||
      prot.indexOf('vbscript:') === 0 ||
      prot.indexOf('data:') === 0
    ) {
      return text
    }
  }
  if (this.options.baseUrl && !originIndependentUrl.test(href)) {
    href = resolveUrl(this.options.baseUrl, href)
  }
  try {
    href = encodeURI(href).replace(/%25/g, '%')
  } catch (e) {
    return text
  }
  var out = '  if (title) {
    out += ' title="' + title + '"'
  }
  out += '>' + text + ''
  return out
}

Here is the code from the react-marked-markdown library overriding the render.link method with a custom function that doesn’t do the sanitization anymore.

const renderer = new marked.Renderer()
renderer.link = (href, title, text) =>
  `${text}`

Securely Adding Markdown Output to a React Component

The react-markdown module on npm takes a different approach to adding the HTML generated from Markdown into React components. They mention that they don’t use dangerouslySetInnerHTML on their npm page. That is a great start.

If you don’t need to render HTML, this component does not use dangerouslySetInnerHTML at all - this is a Good Thing™.

Rather than using strings to string conversions, they convert the Markdown to an Abstract Syntax Tree (AST). Then they use the React library functions, like React.createElement, to make the element tree. Then they let ReactDOM worry about rendering the tree and applying the correct contextual escaping.

They also take extra care in the react-markdown module to handle any dangerous props that could contain XSS exploits. For example they transform all anchor tag’s href attributes by default.

transformLinkUri - function|null Function that gets called for each encountered link with a single argument - uri. The returned value is used in place of the original. The default link URI transformer acts as an XSS-filter, neutralizing things like javascript:, vbscript: and file: protocols. If you specify a custom function, this default filter won't be called, but you can access it as require('react-markdown').uriTransformer. If you want to disable the default transformer, pass null to this option.

https://github.com/rexxars/react-markdown/blob/master/src/uriTransformer.js

'use strict'

var protocols = ['http', 'https', 'mailto', 'tel']

module.exports = function uriTransformer(uri) {

  var url = (uri || '').trim()
  var first = url.charAt(0)

if (first === '#' || first === '/') {
    return url
  }

var colon = url.indexOf(':')
  if (colon === -1) {
    return url
  }

var length = protocols.length
  var index = -1

while (++index < length) {
    var protocol = protocols[index]

if (
      colon === protocol.length &&
      url.slice(0, protocol.length) === protocol
    ) {
      return url
    }
  }

index = url.indexOf('?')
  if (index !== -1 && colon > index) {
    return url
  }

index = url.indexOf('#')
  if (index !== -1 && colon > index) {
    return url
  }

// eslint-disable-next-line no-script-url
  return 'javascript:void(0)'
}

If you use the react-markdown module and pass in attacker controlled anchor href attribute values they will be replaced with the string javascript:void(0).

const spike = '[xss](javascript:onerror=alert;throw%20"hi")'
ReactDOM.render(
      source={ spike }
  />,
  document.getElementById('root')
)

Conclusion

Using Markdown output in the innerHTML of an element will lead to trouble most of the time. If you use Markdown in the dangerouslySetInnerHTML prop of a React component you are also asking for trouble. If you want protection then make sure you enable the sanitization options in your Markdown library. If you are using a third-party module take a peak under the hood and make sure they are correctly setting the Markdown library options and sanitizing values before inserting them into the DOM.

Avoiding XSS via Markdown in React was originally published in javascript-security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Avoiding XSS in React is Still Hard

Ron Perris — Sun, 15 Apr 2018 04:43:30 GMT

Introduction

I’ve spent the last few weeks thinking about React from a secure coding perspective. Since React is a library for creating component based user interfaces, most of the attack surface is related to issues with rendering elements in the DOM. The smart folks over at Facebook have handled this by building automatic escaping into the React DOM library code.

Built-in Escaping is Limited

The escaping code in React DOM works great when you are passing a string value into [...children] . Notice the other two arguments to React.createElement type and [props], values passed into them are unescaped.

// From https://reactjs.org/docs/react-api.html#createelement
React.createElement(
  type,
  [props],
  [...children]
)

Data Passed as Props is Unescaped

When you pass data into a React element via props, the data is not escaped before being rendered into the DOM. This means that an attacker can control the raw values inside of HTML attributes. A classic XSS attack is to put a URL with a javascript: protocol into the href value of an anchor tag. When a user clicks on the anchor tag the browser will execute the JavaScript found in the href attribute value.

// Classic XSS via anchor tag href attribute.
Click me!

This classic XSS attack still works in React when rendering a component with React DOM.

// Classic XSS via anchor tag href attribute in a React component.
ReactDOM.render(
  Click me!,
  document.getElementById('root')
)

Mitigating XSS Attacks on React Props

There are a few options for mitigating attacks on React components. You could do contextual escaping for the prop value.

You would need a list of known bad values for each attribute and you would need to know which characters to escape to make the value benign. Historically this hasn’t gone very well.

You could also try filtering, which also hasn’t gone very well in the past.

For prop values you probably want to use validation. Here is a common attempt at avoiding XSS with blacklist style validation.

const URL = require('url-parse')
const url = new URL(attackerControlled)

function isSafe(url) {
  if (url.protocol === 'javascript:') return false

  return true
}

isSafe(URL('javascript: alert(1)')) // Returns false
isSafe(URL('http://www.reactjs.org')) // Returns true

This approach seems to be working, but as we will see shortly it will only prevent simple attacks that don’t attempt to evade the blacklist.

Validating Against a Blacklist is Hard

In the example above we are doing a lot of things right. We are using the npm module called url-parse to parse the URL instead of hand-rolling a solution. We are attempting to validate the url with an isolated reusable function, so that our security audits and remediation tasks will be easier. We are handling the failure case first in the function and using an early return strategy to handle a failure.

It is usually a bad idea to use blacklists to enforce validation. Here we can defeat the isSafe function using our spacebar.

const URL = require('url-parse')

function isSafe(url) {
  if (url.protocol === 'javascript:') return false

  return true
}

isSafe(URL(' javascript: alert(1)')) // Returns true
isSafe(URL('http://www.reactjs.org')) // Returns true

Reading npm Module Documentation is Hard (Not Joking)

The reason that isSafe(URL(' javascript: alert(1)')) doesn’t work as intended in our isSafe function is described in the documentation page for url-parse over on npm.

baseURL (Object | String): An object or string representing the base URL to use in case urlis a relative URL. This argument is optional and defaults to location in the browser.

So when we pass the string javascript: alert(1) with a leading space I think url-parse assumes we are providing a relative URL and it is happy to assume the protocol from the browser’s location. In this case it believes the protocol for javascript: alert(1) is http:.

const URL = require('url-parse')

URL(' javascript: alert(1)').protocol // Returns http:

If we look further down in the documentation for url-parse on npm we will find this part.

Note that when url-parse is used in a browser environment, it will default to using the browser's current window location as the base URL when parsing all inputs. To parse an input independently of the browser's current URL (e.g. for functionality parity with the library in a Node environment), pass an empty location object as the second parameter:

It tells us that if we pass an empty location object as the second parameter to instances of url-parse we can disable the behavior that is causing all strings to be treated as having the browser’s location protocol as their protocol.

const URL = require('url-parse')

URL(' javascript: alert(1)', {}).protocol // Returns ""

With an empty object as the second argument we can see that we get an empty string back as the protocol for javascript: alert(1) .

Fixing that Blacklist Function

Looking back at the isSafe(url) blacklist function we can improve it by looking for empty strings in addition to the javascript: protocol.

const URL = require('url-parse')
const url = new URL(attackerControlled)

function isSafe(url) {
  if (url.protocol === 'javascript:') return false
  if (url.protocol === '') return false

  return true
}

isSafe(URL('javascript: alert(1)', {})) // Returns false
isSafe(URL('http://www.reactjs.org')) // Returns true

Oh yeah, this is a post about React XSS security. Let’s get back to that now. We can try to use our improved isSafe function to do some validation in a React component.

import React, { Component } from 'react'
import ReactDOM from 'react-dom'
import URL from 'url-parse'

class SafeURL extends Component {
  isSafe(dangerousURL, text) {
    const url = URL(dangerousURL, {})
    if (url.protocol === 'javascript:') return false
    if (url.protocol === '') return false

    return true
  }

  render() {
    const dangerousURL = this.props.dangerousURL
    const safeURL = this.isSafe(dangerousURL) ? dangerousURL : null

    return {this.props.text}
  }
}

ReactDOM.render(
  ,
  document.getElementById('root')
)

This example above is not injectable, maybe.

Whitelist Validation

I’ve never feel very comfortable with blacklist based solutions for security. It would be like if you heard a noise in your house at night and went downstairs to find an unfamiliar person standing in your living room and in order to figure out if they belonged in your house you looked them up in a criminal offenders database.

I prefer whitelist based solutions. I know who is supposed to be in my house.

import React, { Component } from 'react'
import ReactDOM from 'react-dom'

const URL = require('url-parse')

class SafeURL extends Component {
  isSafe(dangerousURL, text) {
    const url = URL(dangerousURL, {})
    if (url.protocol === 'http:') return true
    if (url.protocol === 'https:') return true

    return false
  }

  render() {
    const dangerousURL = this.props.dangerousURL
    const safeURL = this.isSafe(dangerousURL) ? dangerousURL : null

    return {this.props.text}
  }
}

ReactDOM.render(
  ,
  document.getElementById('root')
)

Avoiding XSS in React is Still Hard was originally published in javascript-security on Medium, where people are continuing the conversation by highlighting and responding to this story.