Security and Privacy for Web Sites, Online Applications and Online Shops - Part 2.

File and Database locations.The risks of relevent file and database storage when developming your online shop or portal system.

Whether you are writing in Perl, Java or PHP, includes and classes should be used extensively throughout your site and most developers are in the habit of doing this. The real problem arises in where exactly these auxiliary files are kept within the filesystem. What we do see a lot of are these included files and programs residing in the same directory as the html files. These files often contain databases connection information, passwords or just code we would prefer the general public not to view. All files relevant to producing our website except the visual html files should be stored somewhere on the filesystem that is not published by the web server.

But wait I hear you say how are people going to know what these include files are called?

This is a fair question and has numerous answers depending on the setup of each system. I'll give you an example of a site I saw just last week.
I visited a quite upmarket site last week, they where using PHP to process a script I was about to use. There was presumably an error in the script and although it wasn't a critical error as the program seemed to run alright there was this error all the same. The PHP was set to publish errors on screen so as soon as I hit submit I received the error "error line whatever in thefile.inc". Of course the first thing I did was download the include file to have a bit of a look. This company had their database information in this script and I could have quite easily written up some quick code to query, update or delete all records in this user’s database. Very unprofessional and so easily rectified just by modifying where the error output of the PHP went and more importantly storing such important files well above the web servers document root.

This brings us to the database itself. Now I didn’t query this company's database but I have been involved in Web Development for long enough to know that many companies either keep relatively entire copies of their production databases online or use ODBC to query their actual production databases direct. What a mess this could cause you, the business owner now I have access to your entire client database, sales and all.
It doesn't take too much effort to create a completely separate database just for your online shop or portal. This database should be a skeleton copy of your main database with just sufficient information to allow customers or user to perform whatever tasks are required on your online portal. This database can easily be updated by utilising an ODBC push/pull from your primary database at designated timeframes or even real time if you really think that that is required. This way even if this database is compromised very little information is released.

And if anyone is still using those access databases get them out of the web root folder!

Brad Dixon, is curreently emplyed by
World Domain a Systems Integration and Website Programming company.
He is currently programming the backend work for World Domains' Search Engine Optimisation division

Information can be found at -
http://www.worlddomain.com.au
http://www.search-engine-optimise.com.au