Did you know that your application may be giving valuable clues to an attacker if an error occurs?

It is always easier and less time consuming to attack or exploit an application that you know something about. If you know which application server it runs on or what kind of database server is being used, this information narrows down the number of relevant attacks considerably. If you are in luck (as an attacker, that is!), you may find that this version of the application server has some vulnerability that you can take advantage of.

Gathering information

One of the most common ways to gather information about an application and the surrounding infrastructure is by provoking errors. For instance, if you have some text input field, an attacker may try to input characters like ', ; or other characters that means something to a database to see if the application will return an error message. If the application is poorly secured, the attacker may even get the complete SQL query in the error message, which can be extremely useful.

How can we fix this?

So, how can we avoid helping the attacker and stop providing internal information through error messages? NEVER show stacktraces or internal error messages to the user (or to the frontend application, which is basically the same thing). You should always show the user a generic error message when something unexpected happens. In addition to not leaking information, this will also provide a better user experience. The generic error message can say something like "Something went wrong", and should not contain any information about what actually went wrong. This is also important to remember for the login page: If the user types the wrong password, the error message should not say that "The password is incorrect" as that gives away that the user id was in fact a valid user id.

To make sure that all errors are replaced with the generic error message you can have a filter that takes care of this at the outer boundary of the application, one that all responses passes through.

The devil is in the comments..

Another thing that is easy to forget is to remove comments from the frontend code. As the frontend code may be visible to the user, the comment about the API usage that was nice to have during development is not something that you want an attacker to see.

Keep an eye on the application logs

As probing for errors is a common way to gather information prior to an attack, you should always pay attention to your application logs with regards to any suspicious activity.

Error messages and information leakage

You have begun building your React application. Maybe you even have set it up with Redux. Now you need some content - but how do you fetch it?

Fetching data from an API in React can be done quite simple. JavaScript now comes with the built in Fetch API, which gives you access to a fetch method. So if you want to make a request to an API, it can be done like this:

Great! Now your component request some data and puts the response in your component's state. The data however is only accessible for the component fetching it, and possibly its sub components if passed as props. In many applications you will find that it would be convenient if the data was accessible throughout the entire application. Luckily, we built our application with Redux, and thus have access to several handy libraries to help out. Two common ones are redux-thunk and redux-saga. In this article we will have a closer look at redux-saga.

Redux-saga

Redux-saga is a Redux middleware library which makes use of the ES6 feature generators, which in short is a way to control the ES6 iterator. As opposed to the first example, where the component itself requested data from an API, redux-saga provides a separate "thread" which handles the side effects of your application (this can be more than just data fetching, but let's focus on data fetching). This way, your components can focus on their main job; showing stuff to the user. So let's see what a saga will look like if we need to request a bunch of customers from an API.

So what is happening here? Why is there a star after function? This is how to define generators in ES6. The yield statement is just as mysterious. Generators are called using the next() function, and are paused when it encounters a yield statement. This flow continues like this until the last yield/return/end. Redux-saga does this for us, but you can read more about it from the article about generators above. What´s important to notice here is that the execution of the saga will not continue until the promise from the API call is resolved.

The watcher saga is responsible for watching the action FETCH_CUSTOMERS, and then call the worker saga once the action is dispatched. Then the worker saga will perform the API request. If it was successful, it dispatches the CUSTOMERS_FETCHED action with the customers as payload, and if we got an error, we will dispatch the action CUSTOMERS_FETCH_ERROR action with the error as payload. By defining a reducer for the actions dispatched, we can then receive the payload and i.e put the data on the redux state.

Connect your saga

Now you have your first saga - let´s look at how to connect and run your saga with your redux store. This will happen where you initialize your redux store, typically in the main entrypoint app.js file.

As shown, we create the saga middleware and then put in on our store. Then we import our watcherSaga and tells the middleware to run it. Now the watcherSaga will be able to react on the action we told it to watch.

It´s as simple as that. Happy fetching!

Let´s fetch some data

Let's be honest - manually formatting your code is super boring.

In any project, consistent code formatting brings value by improving readability and reducing frustration among coworkers. Some coders are really good at writing readable, understandable code, with consistent patterns and just the right amount of spacing. But honestly - I'm not one of them. You'll find me writing drafts of code until it works the way it should, then I'll start working on readability. I want my code to make sense to my coworkers (not to mention: to myself the next time I read it!) and I dread receiving code reviews requiring formatting changes. At the same time, I find spending time manually converting code to match our team's code conventions really draining 😩

Don't bother doing it yourself 🤷

Enter ESLint! ESLint is a linting tool that helps you achieve consistent code by configuring rules describing your team's preferred code format and patterns. Installation is really simple:

You should now see a file named .eslintrc in your directory. This is your config file, describing the environment your code runs in and the rules you want your code to follow. ESLint comes with a set of available rules, but you can also write your own ones if you feel like it. Rules come with docs describing what the rule evaluates as correct or incorrect code, as well as any available configuration options.

The rules in .eslintrc can be turned off, set to warn (meaning ESLint will not throw an error, just show a warning in your console) or set to throw errors:

To have ESLint check your files, run this command:

Even better, let's have ESLint fix as many errors automatically as possible:

Someone else has already thought of good rule sets 🙌

Alright. So you've got ESLint set up, but configuring rules is a bit of a chore. Instead of defining all the rules yourself, you can have your config extend another project's config. Neat! In your .eslintrc file, you can remove all the rules and add this:

Okay, so that's not actually a valid config. But here are some widely used ones you should take a look at:

Airbnb has a really nice base-config that I personally love to use. They have also shared their config for React projects, including accessibility checks and their set of best practices.

Google's JavaScript style guide is available as an ESLint config

If you've set up your own formatting rules but want to avoid accessibility issues, there's a react-a11y plugin for ESLint that adds accessibility rules. You can configure these yourself or use the recommended set of rules using this extension: "extends": "plugin:jsx-a11y/recommended"

You can still override an imported config by configuring rules under the rules property. Now you have a really nice tool that will help you write readable code, enforce accessibility and best practices!

Don't touch that file! 😮

If you want ESLint to keep its hands off some of your files (node_modules comes to mind), you can add a CLI argument or an .eslintignore-file. Ours looks something like this:

But wait, there's more 😎

Let's fix even more formatting automatically. There are some really good formatting tools that will improve your workflow immensely (trust me!).

My team uses Prettier, which is a code formatter that will go through your code formatting and just fix it. Nice! Prettier allows you some configuration control, but you don't really have to configure much at all. Prettier has an online sandbox that you can use to test the tool, or to prettify a code snippet. You can use Prettier as a standalone tool, but I mostly use it in combination with the full Airbnb ESLint config. Just add "prettier" to your list of extended ESLint configs, and ESLint will know not to worry about formatting - but still tell you about accessibility issues, unused code and bad patterns.

If you want even less config, and you're not into semicolons, check out StandardJS. StandardJS is a linter and formatter that will do much of the same as ESLint and Prettier, without the config. Just like Prettier, you can use this as a standalone tool or in combination with ESLint.

Save more time: Both of these can be configured to format files on save in most editors!

Are we done yet?

Almost! I just want to tell you about one last thing. Let's save even more time by having ESLint (and Prettier, in my case) verify your code during pull requests. In our package.json we have a couple of npm scripts that have to run without errors in order to merge a pull request:

Never worry about pushing ugly, unused, or inconsistent code to master branch again! I hope this is useful for you in some way - thanks for reading, and happy coding!

7-Dec

Today's posts

Error messages and information leakage

Let´s fetch some data

Automagically beautify your code