Did you know that an attacker could inject code into your application, which could retrieve data or do something else that you did not anticipate?

Code can be injected in many different contexts. Almost everywhere you take input from a user, could be exploited. In SQL, NOSQL, XML, OS commands etc. Of course this is bad, but luckily the situation is not as bad as it sounds. As long as you are aware of the dangers, these kind of vulnerabilities can be averted.

SQL injection

SQL injections was a large attack surface for a long time, and is unfortunately still quite common. This is partly because it is easy to probe for, and a simple SQL injection gives a lot of power to the attacker.

An SQL injection is done by escaping out of the query string, and add new SQL to the string. Let us say that you have form with username and password. When submitting this form with bob and `1234, the application does this SQL query

To check if this is vulnerable, we can input bob' instead of bob

In this example, the code will throw an error back to us. We now know that the code is potentially vulnerable, and we can try to inject some SQL.

Now we wrote bob' AND 1 = 1; into the username field. In this example, it will not throw an error, because it is perfectly valid SQL. It will find the user with username bob, because it will skip the password check due to the double hyphen, which is "start of comment" in many SQL languages.

By injecting this SQL, we can log in as bob without knowing his password.

When are you vulnerable?

When we concatenate SQL queries with user input, without escaping the input, it is possible to use special characters to break out of the context. In this instance, the character ' end the username string and let us add extra SQL, but this depends on the context.

This can be done secure by using parameterized queries, where we put placeholders in the SQL without joining SQL and user input directly. An example of the same query we just wrote can be done in Java like this:

Other injections

As mentioned, this problem is not exclusive to SQL. With OS commands, we can break out of the context with a ;.

Let us say the server has a service to ping an ip. Where the server is running the code system("ping IP_FROM_USER"), and is returning the output to the user.

If we insert 8.8.8.8; cat /etc/passwd, the server will print the output of ping against 8.8.8.8, and the passwd from the server! This is of course very bad, and it is why you should avoid letting the user dictate input to the command line. Instead you should use functions built into the language/framework. If you really have to run commands directly, you need to be very specific in your validation of the input, and escape characters like ; depending on the OS.

The lesson of this post is to always be aware that an attacker will try to write malicious input. And you should always take care of special characters in your language, and never concatenate user input into places where it can run code. In most cases, your language or framework will handle a lot of this for you, but you should always know the dangers in the code you write.

The illustration is from XKCD, and hopefully you can understand it after reading this.

Injections

Another surprisingly handy new feature proposal

Does this look familiar?

Providing a default value for when input values are undefined is a very common scenario. Many developers tend to rely on the boolean OR-operator for this.

The problem

This doesn't work when one of the possible values in the left-hand side expression is a so-called falsy value:

If parameters.respawns is zero, the statement would resolve to the default value, '3'. In fact, you would need a more complex construction to make zero a possible value of config.respawn:

This doesn't read very well and is difficult to remember and type.

The solution

A new JavaScript operator called the "Nullish Coalescing Operator" proposes a new syntax for this:

If the left-hand side of the expression evaluates to undefined or null, the right-hand side of the expression is returned.

The big advantage over || is therefore that so-called "falsy" values are passed through as legal values from the left-hand side.

Woah! Can I use it?

This feature is currently in stage 1, but is of course available as a babel plugin.

Enjoy!

The Nullish Coalescing Operator

Is your React app accessible to all of your users?

Accessibility in React

When we are creating web apps we should think of all our users. Everyone does not have perfect eyesight or normal motor functions. Depending where you are you might even have to accommodate for these users by law. I feel like it is our responsibilty as developers to make sure that everyone are able to use our React apps.

Use semantic HTML

The first thing you can do is to make sure your HTML is semantically correct, e.g. use <nav> for navigational elements, <a> for navigation and <buttons> for actions. This makes it easier for screen readers to know what the different elements on a page are supposed to do. It also makes it easier navigating with a keyboard. You can read more on what semantics is and the different HTML elements at MDN

WAI-ARIA in React

Aria-* HTML attributes are fully supported in React and JSX, and unlike other attributes or properties in React which has to be camelCased, aria-attributes are kebab-cased

Getting feedback in the browser

There are of course some tools to help you get started. First of all there is an offical react-a11y module. It identifies and warns you about potential accessibility issues with React elements in your app. Add it to your project with your preferred package manager, then add the following to your main application file

What next? Start your app and open the console in your browser and you might get a warning like this:

This was provoked by the following div element

To solve this you will either need to add a role, e.g. <div role="button" ... />, or change the element to a <button> for screen readers to understand its purpose. The latter of the two is also the best solution here. There are several rules you can add, some with configurable options. Explore them and use the ones that suits your use case.

Getting feedback while you code

Feedback in the browser console is nice, but it’s a lot more convenient to get it while you write your code. There is of course an eslint plugin for that eslint-plugin-jsx-a11y, and is inteded to use in conjunction with react-a11y. If you’re using Create React App you already have this plugin with some rules already activated.

Explore more

That's just a couple of tools to get you started. Don't forget to have a look at the React docs as well. They have a whole section on accessibility and it's great if you want to know more.

I also recommend visiting the The A11Y Project. They have some great tips and suggestions how to make any site more accessible, but also some test to see how well your site complies, in addition to crush a couple of myths regarding accessibility.

Finally, if you're on Twitter, I recommend you follow Ryan Florence. He's passionate about making React apps accessible for users and developers, and is behind projects like Reach UI and the earlier mentioned react-a11y.

8-Dec

Today's posts

Injections

The Nullish Coalescing Operator

Accessibility in React