I ran into an issue running the LOAD DATA INFILE command from a PHP script the other day. When I logged in as ROOT and executed the script on MySQL Query Browser it worked like a charm. However, when I executed the script from PHP as another use with only SELECT, INSERT, UPDATE and DELETE premission the script failed saying the user does not have enough rights to perform the operation. According to the documentation if the client and server are on the same machine you use the LOAD DATA INFILE form to bulk insert data. However this requires that FILE permission be granted to the user, which is obviously a possible security risk. There does exists a simple work around to this however use the following form of the statement:

LOAD DATA LOCAL INFILE …

This form of the statement should be used when the client and server exists on different machines but works just as well if they are on the same machine and removes the need for the FILE permission.

A friend of mine recently had an issue while installing MySQL 5.1.34 on a Windows 2003 R2 system using the binary installer. All seemed to have gone well with the install except that when it was done he couldn’t log into the database as root. Obviously, we thought that the password was wrong, so we tried to reset it using mysqladmin using the command:

c:\> mysqladmin -u root flush-privileges password <new-password>

However this did not work, even after restarting with the –skip-grant-tables option set. So the next course of action was to re-install. The current installation was removed using the uninstall option and the mySQL folder created on the C:\Program Files folder was junked. 

The re-install started with no problems but curiously remembered all the previous settings (sign of problems to come!). The install completed but configuration failed with the wizard unable to apply security settings because the password was incorrect. Apparently it seems that the password is stored somewhere that was not removed in the previous uninstall.

In the end the following steps worked for completely removing and re-installing:

1. Perform un-install using wizard
2. Manually remove the service if still installed
3. Delete folder C:\Program Files\MySQL
4. Delete C:\Windows\my.ini
5. Delete the MySQL folder in Application Data. The actual Application Data folder will depend on the user performing the installation
6. Re-install

This is a very useful article for anyone experiencing deadlock issues with SQL Server 2005.

http://www.simple-talk.com/sql/learn-sql-server/how-to-track-down-deadlocks-using-sql-server-2005-profiler/

I made use of this while tracking down the cause of the following error:

Transaction (Process ID 97) was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

When using Profiler it is important that you don’t set too many items on trace in a production environment, this can cause your database performance to degrade dramatically.

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.

This is an article I came across on Ben Forta’s blog. This gives some very good tips on preventing SQL  injection attacks and provides some excellent best practices.

 http://www.adobe.com/devnet/coldfusion/articles/sql_injection.html

When I took up my current position we had to do a vulnerability scan to become PCI compliant and well we originally failed horribly. After much work we got it compliant and fixed all of the security holes identified. The article above gives some ColdFusion specific items but also defines some techniques that can be applied to other languages. A few things that are of note are:

• Database user privileges
• Use of stored procedures
• Use of dynamic table names

These three points are usually overlooked by the average developer and should really be implemented. 

Database User Access:

Only give the user the minimum rights required to perform the task. So if your user only needs to perform select and update operations they should not have delete, create or other rights.

Stored Procedures:

Stored procedures provide a very good way to abstract and hide database logic from your code. This is a problem with many of the frameworks that use Active Record patterns like Rails and CakePHP or ORM systems like Reactor in ColdFusion but stored procedures can provide significant performance improvements as well as having security benefits.

Dynamic Table Names:

By prefixing your database tables with a custom string, you can build queries that use a dynamic string for accessing the table information instead of hardcoding the table name. This is another good idea since many systems use generic table names like users, categories, groups etc which can be easily guessed.

It is very important to analyse every section of code and perform a security audit ensuring that all forms are protected since this is the first place that attackers target.

Scenario:

Query grabs user data from MySQL 5 database using the built in MySQL 4/5 driver in ColdFusion 8 on a Windows 2003 Server.

Problem:

Cannot convert value ‘0000-00-00 00:00:00′ from column 10 to TIMESTAMP error returned on execution.

Analysis:

After a quick search on Google, it appears that the default behaviour for the Connector J MySQL driver is to not allow zero date values. A specific value must be included in the connect string to overide this value.

Resolution:

Include the zeroDateTimeBehavior=convertToNull value in the connect string. In ColdFusion the instructions are:

• Go to Data Sources in the ColdFusion Administrator
• Select the MySQL 4/5 datasource and click the Show Advanced Settings button
• In the Connect String box append the following: zeroDateTimeBehavior=convertToNull 

Note: if there is already a connect string add an ampersand to the end of the existing string before adding the new value. For example if the connect string was set to:

useUnicode=true&characterEncoding=iso-8859-1

The new string would look like:

useUnicode=true&characterEncoding=iso-8859-1&zeroDateTimeBehavior=convertToNull