Security implications of SQL

As we've seen, SQL allows us to perform a very large set of instructions, making interacting with the whole database possible at many different levels. We can do this by modifying its structure too. With such a powerful language that can be used to perform any sort of operation on a database, it is natural to start wondering, what could go wrong? With a vast array of possible statements and operations, of course, a malicious attacker could have a wide selection of tools that could be used to damage databases, stored data, and applications using such data, in different ways. One simple instruction, such as DROP DATABASE <database name>, for example, could entirely compromise the functionality of an application that relies on databases to query data or even authentication data (that is, usernames and passwords).

For this reason, SQL code is never, at least directly, conceived to be interacted with inside an application. Instead, it is the application that, given user input, prepares the SQL code needed to be sent to the database to extract (or modify) the data requested.

However, there are ways for potential attackers to abuse SQL syntax and insert arbitrary instructions. This way of attacking is, in general, called code injection, and involves inserting code of a language recognized by a computer or a system into existing code, making it possible to perform otherwise not envisioned tasks.

Being a simple (yet very powerful) language, injecting code within SQL statements is relatively easy and can also produce quite damaging results, varying from granting authenticated access to anybody to utterly destroying a web application relying on databases. The preceding example is just one of many destructive commands that could be injected.

The main issue behind the use of SQL is that code is evaluated by the application while it's running: if no controls are in place, the program itself, which has already started, does not evaluate the statements in terms of content or correctness. A malicious attacker could exploit this by inserting arbitrary commands within user-provided input, such as in authentication forms or string fields that are evaluated by the application by inserting those within running code.

In the following section, we will see how this is possible in a vulnerable application.