Database Activity Monitoring Part 2 – SQL Injection Attacks

If you think through the web sites you visit on a daily basis the chances are that you will need to login to verify who you are. In most cases your username would be stored in a relational database along with all the other registered users on that web site. Hopefully your password will be encrypted and not stored in plain text.

Unfortunately there are gaping holes in the security of some web sites that are being aggressively exploited by a form of hacker attack called SQL Injection.

Even more worrying is that this attack can be carried out against fully patched databases. It is not a problem with patches, more an issue with the way databases work and how a system has been designed.

This attack can be made against any website page that contains data from a database including search pages, feedback forms and customer comment forms. The types of database being used to run web sites include products such as MySQL, SQL Server and Oracle and all of these can be vulnerable to attack. SQL injection is not only specific to SQL Server!

In a typical database used to manage website logins a table will be used to store user’s details. This would probably have at least two columnsone for the username and one for the password. The table would probably be called users or something very similar.

When a user submits their details on the website the database will parse the username and password and convert it into a string of SQL to send to the database, so the database engine receives a line of SQL similar to this:

SELECT * FROM users WHERE username = ‘fredsmith’ AND password = ‘userspassword’

This is a pretty standard SQL statement and would look more or less the same whichever database you were using to store the user’s data.

Hackers are interested in SQL injection attacks as they can manipulate the database by sending it some duff data. Instead of giving a valid username they could type something like this:

SELECT * FROM users WHERE username = ‘ ‘ ‘ AND password = ‘ ‘

The hacker has supplied a single quote character as the username and a blank as the password. The database, being well behaved, would see this query and decide to create an error message. On seeing this error message the hacker will then start to dig around a bit more, as the error messages returned from the database will start to become increasingly more helpful, and start to point out the structure of the tables in the database. With some careful digging an experienced hacker could quite quickly compromise a vulnerable database.

In the next case we can start to fool the database further by adding in other strings to the username. For example if we type in or email=’345 as our username it will be resolved by the query parser as:

SELECT * FROM users
WHERE username = ‘ ‘ or email=’345