Web data security paranoia

My recent experiences with several hacking attacks has made me think more about application and data security on the web. In today's world nothing can be taken for granted and security should be of the highest concern, no mater how simple you think your application or trivial the data you store. Many web applications are hosted on shared servers or virtual private servers where the first line of defense is often left to the hosting provider. The first line of defense is perimeter security such as hardware firewalls and other network related prevention. You are also at the hands of the hosting provider when it comes to software security, that is, your operating system, web server, application servers and scripting languages and ftp patches.

The first thing that and good security plan should have is a proper review of these basic things. Contact your hosting provider and find out about patch management and other security options that may be their responsibility. If you manage your own server then you need to be aware of firewalls (software or hardware), antivirus, patch management and user security.

Now, on to your web application security. In my previous article on preventing sql injection attacks in coldfusion  there are quite a few tips for securing the applications. One other place developers tend to ignore is the transmission of data to and storage of data in the database. So let's look at some of the options for securing data.

Database access:

If your budget supports it, the first thing that should be implemented would be to have your database on a separate physical machine from your application server or public web server. This has two positive effects. Firstly, moving the database server to another machine will take the load off the web server or application server which can only be a good thing. Secondly, you public web server would be the first machine to be attacked, thus if a breach were to occur having the database on another machine would add some level of defense.

Ensure that the web application database user has the bare minimum rights to the database. That is, if the web application has no need to add tables or drop tables then the user should not have CREATE or DROP rights. Ensure, under no circumstances that your web application uses ROOT, SA or any other master login to access your database. Create a separate user for each application and give it the required rights.

One other thing I like to do is limit remote access to the database, if you can get SSH/RDP access to the server limit that to specific IP addresses. This causes remote administration to be a pain but the security benefits outweight the inconvenience.

 

Data storage:

Now, once you have the correct rights on your database and secured it from web access the next step would be to secure the actual data being stored. You will want to ensure that the forms that submit information are secured with a valid strong SSL certificate. Now, you may not be interested in using SSL encryption for all forms on  your site but it is a good practice to secure forms such as registration, login, shopping carts and checkout forms. Basically, any form that has any user information should be secured.

This same thinking should extend to storing the data in the database. Many developers encrypt passwords and store them in the database, but I think other things like usernames, email addresses and any other information that can potential be regarded as sensitive information should be encrypted and stored in the database. There are two options for this. Let the database encrypt the data for you or let your application encrypt the data before it is inserted in the database.

In SQL Server 2005, you can achieve this using some special functions. You can read more about this method in the following articles:

http://www.sql-server-performance.com/articles/dev/encryption_2005_1_p1.aspx

http://www.sql-server-performance.com/articles/dev/encryption_2005_2_p1.aspx

Other popular databases would have similar features.

The other option would be to encrypt the data before storing it in the database and then decrypting it when it needs to be used. In ColdFusion, this can be achieved using the encrypt and decrypt functions. These functions allow you to choose and encryption algorithm (SHA1, Blowfish etc) and a security key. The major drawback to this method is speed. This would slow down the communication of data between the web application and the user, however I think this is a fair trade off for the security concious.

Related Posts

This entry was posted in ColdFusion, Databases, PHP, Security and tagged , , , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.