Common Database Vulnerabilities: SQL Injection

Hold on - before you skip this article because you think you already know everything that there is to know about SQL Injection, ask yourself why there is so much to read about SQL Injection.

SQL Injection – The Most Written About SQL Vulnerability

Many people have heard about SQL Injection. Many people talk about SQL Injection. Many people write about SQL Injection. And yet, many people have SQL Injection vulnerabilities in their installations.

In fact, for several years now, injection vulnerabilities (which include SQL Injection vulnerabilities) have been the leading web-application vulnerability, according to the Open Web Application Security Project (OWASP) that regularly compiles web application vulnerability reports.

Although web applications are probably the most common form of application nowadays, they are not the only applications. If you are using another form of application, you are not safe from SQL Injection either. In fact, any application that takes user input and accesses a database is at risk.

SQL Injection Protection

In theory, it is a simple feat to protect from this massive threat: Sanitize all User Input!

However, in practice it is easy to get wrong.

A common way to introduce this kind of vulnerability is to follow wrong advice. For example, using SQL stored procedures to protect from SQL Injection is one advice you often find online - it is wrong (incomplete) and therefore dangerous.

But even if you are following only good advice, there are still many traps. For example, how many forms of user input can you think of? All forms of user input could lead to SQL Injection vulnerabilities. You have the standard web form that takes user supplied values to build queries accessing the database. However, there are also more subtle forms of user-supplied values. In the case of a web application for example, you do not only have to sanitize values that the user can type in, you also need to sanitize values that come from a drop down (or any form of selectable pre-valued input) as it is easy to manipulate those values in the browser. You even have to sanitize things like cookies and the "User Agent" value if your application is using them.

If you have a desktop application, the same rules apply. Any field that the user can type in directly needs to be sanitized. But, you also need to pay attention to other input channels. For example, if the application has a settings file, values you read from there need to be sanitized too, before they are used to build database queries.

SQL Injection Prophylaxis

Because this type of vulnerability is so easy to create, it is important that the entire development staff is not only aware of the SQL Injection problem, but really understands the underlying causes and the different options an attacker has to exploit this type of vulnerability. SQL Injection training should be mandatory to everyone that can "touch" the code.

In addition, it is important to execute regular SQL Injection Audits of your application. A first step is regular peer-to-peer code reviews. You can also install an "automatic" vulnerability scanner in the build process. One simple and effective way to execute this step is to hire an expert to do a SQL Injection Audit of your application.

The Most Common Database Problems

SQL Injection is one of the most commonly encountered database vulnerabilities. In this series of posts, I discuss 10 of them. Below are the ones that are published so far: