REDspace

Digital experiences that help empower brands

Approaching Web Security

For a lesson in information security, take a look at the cover of “The Hitchhiker’s Guide to the Galaxy”. It simply states:

DON’T PANIC.

That is always the best advice anyone can give to someone who is tackling an application’s security. The approach to security is two-fold: no matter how much effort you put into securing something, someone will always be able to put in more effort to break it. Also, it makes more sense to put more time into quick recovery, than it does to making sure you’re 100% secure all the time.

Below is a video by Kevin Roose who went to the largest hacker convention in the world in Las Vegas, and asked the world’s best hackers to hack him however they wanted. The results speak volumes:

Towards the end of the video, there’s an important message, one that’s too often overlooked among the flashy toys and whiz-bang new ways of hacking: security is subject to the Pareto Principle. You get 80% of your results from 20% of your efforts.

What does that mean? It means that for every one minute you spend optimizing for the latest front-page zero-day threat, you should be spending ten minutes working on foundational security practices. Below are a few examples of security practices we consider at REDspace.

SQL Injection

How does it work?

Well, let’s say that you want to create a page that returns search results. First thing you do is write a database query along the lines of “SELECT * FROM USERS WHERE USERNAME = $input;”.

But what happens when $input is equal to “FRED; SELECT PASSWORD FROM USER_PASSWORDS”? Your query becomes “SELECT * FROM USERS WHERE USERNAME = FRED; SELECT PASSWORD FROM USER_PASSWORDS;

Both queries run, and the answer is returned. Whoops.

How to prevent it from happening to you

Prepared statements are available in all popular languages with database support. They take the value of $input, and tell the database that even if it contains a ;, or any other special database symbol, the whole thing should be treated like plain text.

The above query would then return an error, since nobody is likely to have the username “FRED; SELECT PASSWORD FROM USER_PASSWORDS”.

But someone might. If you don’t use prepared statements to read that username from the database, then you are vulnerable to “second order” SQL injection.

Using prepared statements would save you again here, because the query would now just return the public data for that very oddly named user. No user’s password would be returned

XSS

How does it work?

Our example here will be blog comments. You put your text into a box, hit Submit, and it shows up at the bottom of the page.

The problem comes when you don’t differentiate between text you put there, and text other people put there. What if I added a comment like: “<script>alert(“You have been hacked”)<script>” to the blog? Everyone who came to your blog would be instantly insulted with an alert box saying ‘You have been hacked’.

And there are obviously worse things one can do with JavaScript. For instance, an attacker could write code that, as soon as you loaded the page, sent the value of your session cookie over AJAX to the person who wrote the comment. Bad stuff.

How to prevent it from happening to you

Don’t let people add whatever they want to your page, if that page will be visible to others. What you’re displaying will determine the sanitization method you use, but many good solutions exist.

CSRF

How does it work?

The final example will be from forum software. If you want to delete your account, you go to http://forum.com/account/38/delete, and click the Confirm button. All good, right?

But this attack can be combined with XSS to have that page be loaded without your knowledge. Loading up a page with malicious comments could cause an AJAX call to http://forum.com/account/38/delete?confirm=true in the background, without you knowing until you tried to access your account and found it gone.

How to prevent it from happening to you

There are a few popular methods, but the consensus is to use form tokens. This is a secondary kind of session ID, wherein a hidden field is added to all fields, pre-populated with a random key associated with that session.

If some random AJAX request comes in, it won’t have the token since that is only passed by requests from the legitimate confirmation page. In the end, you get to keep your account.

Summary

Keeping your webpage secure is important, but it doesn’t have to be difficult. By following a few simple rules such as “don’t trust user input”, you can protect your site from those who wish it harm.

Go forth, and code securely!