Have you ever wondered how someone could steal money from your bank account while you browse certain sites, or post as you on Facebook? That is called Cross Site Request Forgery (CSRF), and we will try to explain what it is, and how you protect your website and users against it.

Web applications today have a lot of functionality. E.g. a banking website can transfer money, manage your portfolio and much more. What if an attacker could do this on your behalf while you browse the internet? Let us present Cross Site Request Forgery, popularly shortened CSRF or XSRF.

Let us say you are a customer of bank.com. If you want to transfer money to another account, you go to https://www.bank.com and log in. The bank will likely do a request similar to this when you press the transfer button:

The bank will then transfer 1000 from your account, to the account given in to_account.

But what if you visit a malicious website while you are logged in? If that website tries to send the same request, changing the parameter to_account to the account of the attacker. The browser will send the request without complaining, and it will even supply your session cookie, which identifies you as a user. When the server in the bank receive the request, it will transfer the money to attacker, because it does not distinguish a request sent from https://www.bank.com and the malicious website. This is called Cross Site Request Forgery.

Although the case is a simple example, attacks similar to this has actually happened.

How do you protect your users against this attack?

The main goal of protecting your users against this attack, is to distinguish a legitimate request and a malicious request. To accomplish this, the server needs to check the validity of something that the malicious website can not steal or generate. The most widely used technique, is to generate a token and use it in all requests from the website. The server can then check the validity of the token on the server. Due to the same origin policy that all normal browsers obey, a malicious website can not read the content of another domain and extract the value of the token.

It is important that this token is generated uniquely for each session, which can be accomplished in multiple ways. The server can generate a random token and store it in the session, which make it easy for the server to check its validity when it receives a request. Another technique which eliminate the state on the server, is to generate the token from something that identifies the user, together with a secret key on the server. This does not need to be stored in the session, because it can always be regenerated on the server and checked against the value in the request. Most modern frameworks has one of these, or a similar technique built in, and it is highly recommended to use it.

These techniques will protect your users against CSRF, but it is only designed to protect against requests which potentially changes the state of the server. Which means that it will not protect against a malicious website doing GET requests on the users behalf. This is intentionally, because a GET request should never change the state on the server, and thus will not need the protection against CSRF. Another consideration, is that if you put the token in a GET request, websites you link to can potentially get the token from the referrer header.

Hopefully you have gotten a little introduction to CSRF by reading this post, and if you want to know more, we suggest that you read more at OWASP CSRF. We hope to see you back tomorrow.

Cross Site Request Forgery

If we consider the code snippet above, what does the condition evaluate to? It might, or might not surprise you that the condition evaluate to true. But why?

Everybody that know JavaScript is familiar with the concept of true and false, the primitive boolean values. Truthy and falsy are used to evaluate a condition on values other than the primitive boolean values. This help us evaluate conditions without first performing an explicit type convertion on a value to a primitive boolean type. In other words, we can write:

instead of:

What values are truthy and what values are falsy? The easiest way for me to remember, is that all values are truthy, unless defined as falsy. The falsy values are as follows: false, 0, "", null, undefined, and NaN.

So, the reason the condition in the first code snippet evaluated to true, is that the value used is a Boolean object, and a object is truthy in JavaScript. Even an empty object {} is truthy, as we can see from the list of falsy values above.

All the expressions below will evaluate to true:

Truthy and falsy

Almost every application you write contains state and you'll need some way to manage it, but how?

Redux is often used for state management in React apps, but it is possible to manage state within React itself. So, what is the best solution for your application? It depends. Let's take a look at some characteristics that can make the choice clearer.

In the article 'You Might Not Need Redux', Dan Abramov states that not all applications need Redux for state management. I recommend reading for more insight on this topic. Even though your app needs Redux to handle state, there is nothing wrong in using local state in some parts of your application.

Different types of state

Some state is used widely and needs to be persisted over time, while other state needs to be stored shortly and is used at one place only. Whilst the first one might benefit from Redux or even needs more persistent storage, the second case is much simpler and can suffice with the simpler React State.

The following two questions can be helpful in making a decision.

For how long do the state need to be stored?

Data that only needs to be stored for a short time is well suited for using local React state. Examples are the content of an input field, a form that is not yet submitted, or how to filter a list of items.

If the state is needed as the user navigates across the application, and it is expected to be present until next refresh, local state is not recommended.

Where is the state used?

Is your state isolated? If your state is used at a small part of your application, or in a specific component, local state is a good solution.

If several unrelated components need the same data, it is better to put it in the Redux store. The same goes if the data is used by multiple subcomponents. In this case there will be a large amount of overhead in sending the required props down to all child components.

One big advantage with Redux is the possibility to track changes of state and play the changes step by step. This is useful when debugging complex state, but is not necessary for the parts of your state that are simple and isolated.

Local state is a good solution if the state is isolated and needs to be persisted shortly. Redux offers great state management, but also adds overhead which can be avoided if local state is used instead. The most important thing to remember is that one doesn't rule out the other.

4-Dec

Today's posts

Cross Site Request Forgery

Truthy and falsy

Handling component state