When creating a web application, or a web site with more than one page, you will need to reference different resources. If you create a blog, you need to create unique paths to all the blog posts, like we are doing in this Christmas calendar. You see that the url is https://security.christmas/2018/20, where 2018 is a reference to the year, and 20 to the day of December. It is a fairly simple system, and you may have tried to skip ahead, but been met by a page saying you have to wait a bit longer?

A Direct Object Reference, is a key which reference to some kind of resource, where the user can change the key to something else, and get another resource. An Insecure Direct Object Reference, is a Direct Object Reference where the developers failed to implement access control to the resource.

In the calendar, we use the year and the day of December together as a Direct Object Reference. This points to a file with the day as the filename, in a folder named with the year. If we had not secured this with access control on the current date, this would have been an Insecure Direct Object Reference. We could have secured only the calendar page, where you see the days are blurred until the current time has passed midnight on each day, but this would only leave us with false security.

Although we clearly see that securing only the listing of the hatches are not enough, these kind of vulnerabilities are quite often seen in applications. It seems to be difficult to get this correct, at least if the resources are used in more complex implementations. In our calendar, all the users have the same access control, they all need to wait until the hatch is open, but in an applications where the users have access to different resources, we have to do access control in the context of the user.

As an example, you can access your bank accounts through your bank's web site, and other users should not be able to see your bank accounts, or worse use them to pay bills. If you choose to pay a bill, the bank website will show your accounts, and you are able to choose which of your bank accounts to transfer the money from. But what if an attacker chooses to tamper with the request sent to the server, and changes the account paying the bill, to an account belonging to someone else? If this succeeds and such an vulnerability exists, this would classify as Insecure Direct Object Reference and Broken Access Control.

How to do it right?

The obvious answer would of course be to check if the user has access every time a resource is referenced, but in some cases this can be difficult and in a large application it can be forgotten at some point.

There are many solutions that can be implemented, depending on the usage, and whether you are developing a new application or trying to secure an old legacy application. An easy solution can be to run a filter which does the authorization on each request. With a filter, it is easy to review if the access control is done, but it can be difficult to make it general enough due to the usage in different contexts.

To make sure we do not have Insecure Direct Object References, we need to remove the Direct Object Reference, hence it cannot be insecure. We can transform the resources to a list specific to the user. In the example where you pay your bill, you should transform the accounts to a list which only makes sense to the user. Instead of sending the whole account number when paying the bill, you can send the index in the list, which make it impossible for an attacker to reference your account as the paying account.

It is fairly easy to test for this vulnerability, just increment that id you normally see in your url. If you get some resource you should not have seen, you have an Insecure Direct Object Reference.

Insecure Direct Object Reference

D3 (Data Driven Documents) is a JavaScript library that's well suited to create data visualizations on the web. It brings data to life using HTML, SVGs and CSS. You can make everything from static graphs to interactive articles.

D3.js has been around for a long time, it was initially released in 2011, and has gained a lot of traction during these years. Nowadays, it is the de facto standard of data visualization and has a large community. Just take a look at this list of examples.

What's the fuss about?

The core idea of D3 is to connect data with HTML and/or SVG. Let's say we have some data about the population in some countries and we want to visualize it.

Then we let D3 do its magic, and suddenly we have the SVG below.

The SVG contains three circles, each of which has a radius relative to the population of the country.

This is where the magic happens

Let's take it one step further, and take a glimpse at what D3 can do.

Given this html and the same data as in the previous example.

Then we use the data method of D3 to join each datum in our dataset to a circle element in the SVG above.

Wait, what?! There are no circle elements in the SVG.

I found this really confusing the first (and second) time I saw it. Instead of telling D3 how to do something, you tell D3 what you want. In our case we want one circle element for each datum in our dataset. This concept is called joining data and this article explains it better than I ever could.

In our example the SVG does not contain any circle elements. Hence, all our data points are a part of the enter selection. The enter selection contains unbound data points, which represents missing elements.

Joining data with the data method creates multiple selections. To better understand data binding in D3 you should check them out.

Then we use the append method to append a circle element for each of the datums in the enter selection.

Now we have modified the original html and it contains three circles that represent the population of each of the countries.

This is just the tip of the iceberg. You can literally make anything you want with D3.

If this article got you interested, you should check out the offical documentation (link below). In my humble opinion that's the best place to start.

D3 in action

A hot topic these days, and I don't think we'll ever agree, but here are some ways to do CSS in your React app

Getting started using Create React App

If you are starting from scratch, Create React App is a great way to get started. Without any configuration you can import your CSS files like you import your React components. Since CRA uses Babel you can also use ES6 imports for this

Since CRA version 2.0, support also includes auto-prefixing, so there is no need to write browser specific CSS like -webkit-* or similar prefixes anymore.

CRA + Sass

Using Sass is also available, just make sure you add node-sass to your project. Then you can import your .scss-files directly

CSS preprocessors like Sass or LESS build upon CSS and add features like variables, functions, mixins and nesting. CSS variables is already supported in some browsers, but lack of support in IE and Edge still is a deal breaker for many.

CSS Modules

CRA also supports CSS Modules. For each component you want to style you can now create an associated CSS-file, just add .module.css (or .module.scss if you're using Sass) to the file name:

Using CSS Modules allows you to scope your CSS to the component, meaning if you have another component that has a class .mainTitle it will not be affected. If you inspect your component in your browser the actual class name will be postfixed .mainTitle__yLE5s making it unique for that component.

But I don't use Create React App

Well, then you have to do the build setup yourself, but it is still possible to use CSS Modules, Sass, LESS, and there are plenty of tutorials out there to help you get going. Here is an example using LESS and CSS Modules.

So... CSS-in-JS 💥

So very simply put, CSS-in-JS basically allows you to create component scoped CSS by specifying it directly in JavaScript. Similar to CSS Modules you will get unique classes for each component preventing different component styles for overwriting each other.

Keep in mind, CSS-in-JS and inline styling are not the same thing. Inline styling adds the styling directly to the component, which gives you less control over your styles, decreases performance, doesn't support pseudo classes, and should be avoided.

Let me show you an example how CSS-in-JS works using the styled-components library:

This will give you something like this

The <style> is applied to the top of the DOM with a unique class name for your component.

There are several libraries you pick from. Emotion, styled-components and JSS are three examples. You don't need any additional build steps to get started, just add your desired library to your project. This site is built with styled-components, and it works just fine!

Using JavaScript to describe how your components look is appealing to many, and has both pros and cons. In this Gist, Sunil Pai tries to shed some light on the advantages and disadvantages of CSS-in-JS. I recommend reading both his post and the following discussion if you're interested.

What should I use?

There are many good reasons to use any of the mentioned ways to style your app, but there is no right answer. Pick the one that best suits your needs and stick with it. If you can't decide take some time to read some posts about the advantages of the different libraries/frameworks.

20-Dec

Today's posts

Insecure Direct Object Reference

D3 in action

How to CSS in React