Testing ReactJS for XSS vulnerabilities


React is a Javascript framework from Facebook. Although it can be utilised natively, I'm going to focus on its front-end use. If you're not familiar with React, Facebook has a pretty good tutorial available.

The simplest explanation of React, is to consider it a natural progression from AJAX queries that try to render output by hand.

React - XSS handling

One of React's features is that it handles XSS escapes by default. On the surface this is a good thing - new developers are far less likely to introduce XSS vounerabilities in code that escapes everything by default. They make very obvious the risks associated with bypassing this filter.

There are a few obvious downsides here, namely, you have to trust React to properly escape everything it's given. If you utilise any form of web security application scanner, you'll quickly notice it continually flagging alerts that it believes are XSS vulnerabilities, as it sees json come down the wire with unescapated HTML. Burp Suite did exactly this on a recent application test, which is the purpose for this testing. Unfortunately I'm not very good at shrugging my shoulders and declaring Facebook probably secured my services.

The React XSS Smoke test

Facebook's code is generally very good, and I had every expectation I was going to get the result I did. That said, sometimes it's good to be testing. This service can also serve as an ongoing test for regressions.

As a source, I am utilising the OWASP XSS Filter Evasion cheat sheet. This page is updated regularly and hence the developed process includes grabbing the latest.

Extracting the latest XSS list

I've created a short Ruby script which will parse the OWASP page, and create a .json file. This file is used by the front end.


With assistance from Babel and Gulp, we have a short peice of React front end that will:

  • Perform an ajax query on the generated json
  • Render each element on screen

This single script will attempt to execute each element from the OWASP cheat sheet. The fact you can view it without any issues including popups or network activity, shows the current version of React is intact.

Get it

You can view it all on my Github. https://github.com/technion/reactxss

The current code base is also running live at https://lolware.net/reactxss/index.html. No, it doesn't look like much. That's a TODO.


With a third party smoke test in place, I have a higher level of confidence in trusting React to sanitise frontends. I'll be expanding capabilities over the coming weeks, to ensure it tests the latest release, and to automate the testing.

Property based tests, contracts with Ruby

Base App

For this demonstration, we are going to be using the venerable Fizzbuzz application. For those who haven't seen it, it's a common programming koan - see here the Wikipedia page.

Despite being a very single function, it can be surprising the issues you pick up.

With thanks to @Kerrick on Github, I've taken the first example code found on Google. Here's our sample file fb.rb:

#!/usr/bin/env ruby

def fizz_buzz(max)
  arr = []
  (1..max).each do |n|
    if ((n % 3 == 0) && (n % 5 == 0))
      arr << "FizzBuzz"
    elsif (n % 3 == 0)
      arr << "Fizz"
    elsif (n % 5 == 0)
      arr << "Buzz"
      arr << n
  return arr

For a quick demonstration, let's see how it looks:

2.2.2 :001 > require_relative 'fb'
 => true
2.2.2 :004 > fizz_buzz(5)
 => [1, 2, "Fizz", 4, "Buzz"]


So far so good. The first thing I'm going to do is setup contracts. Let's create this Gemfile:

source 'http://rubygems.org'
gem 'contracts'

And install the gem (locally for this app, keeping the global space clean):

bundle install --path=vendor/bundle

Using contracts involves placing this at the start of your script:

require 'contracts'
include Contracts

And then we need to think about our function. In this case, the input parameter is a positive integer, and it returns an array of strings. So I placed this directly before the function definition:

Contract Pos => ArrayOf[String]

Now let's try and run it. It sounds simple and should "just work", but let's see:

2.2.0 :003 > fizz_buzz 5
ReturnContractError: Contract violation for return value:
    Expected: (a collection Array of String),
    Actual: [1, 2, "Fizz", 4, "Buzz"]
    Value guarded in: Object::fizz_buzz
    With Contract: Pos => CollectionOf
    At: /home/technion/fizzbuzz_tests/fb.rb:7

Turns out, the current code doesn't return an array of strings, it mixes integers with strings. I can hear it already. "But my code works fine". Really? Let's go back to the pre-contract code and try something:

2.2.0 :007 > puts "The third Fizzbuzz output is " + fb[2]
The third Fizzbuzz output is Fizz

Sounds legit..

2.2.0 :008 > puts "The fourth Fizzbuzz output is " + fb[3]
TypeError: no implicit conversion of Fixnum into String

Purists will point out that string interpolation would have resolved this, but that's not the point. The point is seeing unexpected behaviour because the return type differents from what was expected. With that in mind, let's put our contract in place, and alter the final branch of our statement on line 17 accordingly:

arr << n.to_s

Running it in irb:

2.2.0 :002 > fizz_buzz 5
=> ["1", "2", "Fizz", "4", "Buzz"]

Much better.

Some basic tests

Before we do any new, exciting tests, let's get some basic ones in place. This is a boilerplate Rakefile for minitest:

require 'rake'
require 'rake/testtask'

Rake::TestTask.new do |t|
  t.test_files = Dir.glob('spec/*.rb')
task(default: :test)

The two test applications were added to our Gemfile. We'll be using minitest, and we'll come back to explaining rubycheck.

gem 'rubycheck'
gem 'minitest'

Re-run bundler as above to install these gems. We also created spec/fbtests.rb. Rather than walk you through each individual test, we've annotated them in comments.

#!/usr/bin/env ruby

require 'minitest/autorun'
require 'rubycheck'
require_relative '../fb'

class FBTest < MiniTest::Test
  #The most basic test is a matter of identifying a simple input and 
  #confirming that a simple output matches exactly.
  #A small number like 5 can be fully typed out
  def test_5
    fb = fizz_buzz 5
    assert_equal ["1", "2", "Fizz", "4", "Buzz"], fb
  #A larger fizzbuzz test needs to be considered more methodically. Noone
  #Will sit there typing out the expected results for fizz_buzz 100.
  def test_100
    fb = fizz_buzz 100
    #One thing we can say about fizzbuzz 100 is the length. Check it
    assert_equal 100, fb.length
    #This test verifies every element in the array matches one of the valid
    #results. This is a great way of checking every single value in some way.
    assert fb.all? { |e| /(\d+)|(FizzBuzz)|(Fizz)|(Buzz)/.match(e) }
  def test_negative
    #We said earlier our contract shouldn't allow this. Check for an exception.
    assert_raises {fizzbuzz -1 }

And that's a simple guide to writing tests. We recommend running them:

bundle exec rake test

But that's where a lot of guides would stop.

Property based testing

One of the great things about the fizzbuzz 100 test we wrote is that it's fairly generic. It should work for fizzbuzz 10, or fizzbuzz 1000 in the same way. So why not write a test that tests this property?

As a first example, we'll write simple a test that checks against one random number. Add in this test:

def test_random
    r = RubyCheck.gen_uint
    fb = fizz_buzz r
    assert fb.all? { |e| /(\d+)|(FizzBuzz)|(Fizz)|(Buzz)/.match(e) }

All we've done here is made '100' into a random variable 'r'. The output however is interesting:

]$ bundle exec rake test
Run options: --seed 11306

# Running:

...rake aborted!
SignalException: SIGKILL

It'll take you a while to track down that segfault, and when you do, you'll see a huge dump sitting in the server logs, ending in this:

kernel: Out of memory: Kill process 2994 (ruby) score 896 or sacrifice child
kernel: Killed process 2994 (ruby) total-vm:2610792kB, anon-rss:1895804kB, file-rss:2024kB

What you are looking at is the fact that a huge, random number is able to crash our fizz_buzz application. We're just lucky the OOM killer killed the right app. Win one, for property based testing.

To pick a, somewhat arbitrary, upper bound, I've placed this in the first line of our updated fizzbuzz function:

fail if max > 65536

And then we baked in a test for it:

def test_too_high
    assert_raises { fizz_buzz 65538 }

If you comment out the random_test for a moment, you should be able to run a successful:

bundle exec rake test

So what to do about getting the random test running again? Well this sort of thing should work:

r = RubyCheck.gen_uint % 65537

However, I really feel property based testing should have a "property" for a 16 bit integer, so I've submitted a PR to rubycheck. If it gets through, this will be equivalent:

 r = RubyCheck.gen_uint16

Whichever you use, you should not find yourself able to check a random number with your fizzbuzz application.

You can probably see where I'm going with this - if you can test one random number, why not test many? rubycheck does have a "for_all" function, however, for various reasons, I prefer to implement this myself. Let's run a series of numbers through the checker.

Obviously, the more the better, but any more than a few hundred makes this a very boring test to sit through. So, I will be implementing some general tests, then more tests for the upper and lower bounds.

def test_random
    200.times do
      r = RubyCheck.gen_uint16
      fb = fizz_buzz r
      assert_equal r, fb.length
      assert fb.all? { |e| /(\d+)|(FizzBuzz)|(Fizz)|(Buzz)/.match(e) }
  def test_low_random
    100.times do
      r = RubyCheck.gen_uint16%256
      fb = fizz_buzz r
      assert_equal r, fb.length
      assert fb.all? { |e| /(\d+)|(FizzBuzz)|(Fizz)|(Buzz)/.match(e) }
  def test_high_random
    100.times do
      r = RubyCheck.gen_uint16%256 + 65280 #2e16 - 256
      fb = fizz_buzz r
      assert_equal r, fb.length
      assert fb.all? { |e| /(\d+)|(FizzBuzz)|(Fizz)|(Buzz)/.match(e) }
$ bundle exec rake test
Run options: --seed 30688

# Running:


Finished in 76.904164s, 0.0910 runs/s, 7.7109 assertions/s.

  1) Error:
ParamContractError: Contract violation for argument 1 of 1:
        Expected: Pos,
        Actual: 0
        Value guarded in: Object::fizz_buzz
        With Contract: Pos => CollectionOf
        At: /home/technion/fizzbuzz_tests/fb.rb:7

Yes, we've found another issue. Our contract states "positive integer" - that means it does not accept a 0. Now you've entered a philosophical discussion: is there a fizzbuzz(0) ? If you believe not, then the contract served its purpose, and we should update the tests accordingly.

In the interests of shirking this convention, I have declared that on this project, fizzbuzz (0) is in fact an empty array. To this end, here is my final fizzbuzz code:

Contract Or[Pos, 0] => ArrayOf[String]
def fizz_buzz(max)
  fail if max > 65536
  arr = []
  return arr if max == 0
  (1..max).each do |n|
    if ((n % 3 == 0) && (n % 5 == 0))
      arr << "FizzBuzz"
    elsif (n % 3 == 0)
      arr << "Fizz"
    elsif (n % 5 == 0)
      arr << "Buzz"
      arr << n.to_s
  return arr

Of course, that deserves one more test:

def test_0
    assert_equal [], fizz_buzz(0)

Regardless of the position you take on this, the point is that randomised testing forced a developer to at least consider an edge case, and plan accordingly. That in turn, is what we call "less bugs".

Concurrent Vulnerability scanning with Erlang


Following the recent series of major vulnerabilities, a trend that's become popular has been the online scanner. It was far easier to test a service using and online Shellshock scanner, or an online Heartbleed scanner, or in this case, the MShttp.sys vulnerability. This scanner was inspired by this particular scanner.

Scanning larger amounts of machines has however, been historically quite slow. If any of the listed scanners simply iterated across a list of machines, it could take quite some time to run across reasonably large networks.

Concurrent scanning

That introduction is a perfect place to introduce the concurrency capabilities of Erlang. Concurrency has been a huge trend lately, mostly in relation to the (stupid) argument that argues Node.JS has concurrency and therefore it's the ony platform that can scale to handle a personal blog.

A much more powerful use of concurrency exists in this snippet of code, which I see myself using regularly.

Pid = spawn(fun() ->
        {From, execute} ->
            From ! {N, function(N)) }
Pid ! {self(), execute},

Which, in short, tells Erlang to run a particular function concurrently, and send the results back to the parent. In this example, I've written a scanner for CVE-2015-1635. By utilising this loop, I've found you can perform such a scan incredibly fast.

The time I've quoted is 200ms, which accounts for a certain amount of network latency, in scanning an entire /24 of network hosts. Without that, let's see the below:

$ time wget http://erlvulnscan.lolware.net:8080/?network= -O -

2015-06-12 10:15:48 (152 MB/s) - written to stdout [12593/12593]

real    0m0.062s
user    0m0.003s
sys     0m0.007s

Yes, that's less than one second to:

  • Make an HTTP connection to each server from to
  • Run the vulnerability check
  • Format the results nicely in JSON and render to the user

That's an impressive time. I look forward to being told it should be done in JS.


Source code for a complete implementation can be found here:

erlvulnscan on Github

A key design goal is to allow the project to easily forked and run new types of vulnerability scans, which I am likely to do at some point. A functional implementation can be seen here:

erlvulnscan demonstration

Although the project is scheduled for aesthetic improvements, the backend is now stable.


erlvulnscan is an Erlang OTP application built using Cowboy and Jiffy, and managed by rebar.

Rather than play with Cowboy routes for static data, assets such as the front page are intended to be served using nginx, with a routing rule to forward the API.

Code is intended to be dialyzer and edoc friendly.

The frontend uses ReactJS, although at this stage it is largely a copy of the React tutorial. Starting using this base will allow it to be rapidly improved however.


In the coming weeks, the project should see the following. Hopefully in time for a new major issue to scan for. This roadmap exists here both to serve as my own roadmap, and avoid the inevitable situation where the only contact someone makes about my this page is point me in the direction of something like Grunt.

  • Properly modularise the scanner, so replacement of a single file can facilitate management of a new vulnerability
  • Fully dialyze and tidy up all warnings
  • Frontend aesthetic overhaul and implementation
  • Route changes, entire project should be able to be served on one port!!
  • Frontend code overhaul. Many function names are straight out of ReactJS tutorial. JSX should be converted and minified on the backend.
  • Learn and implement EUnit
  • Implement Elvis
  • Implement Grunt for the frontend
  • Hot code load implement and test