Relational database management systems (RDBMS) such as Oracle, MySQL and Microsoft SQL Server are among the most popular in the market, according to the current DB Engines ranking. Since they are considered to be very reliable and avoid inconsistencies in the data records, they have been an established standard for databases in most companies for decades.
The Structured Query Language (SQL) database language is usually used to query and edit the data in it. For example, users communicate with a server using a product search mask in a web shop, which in turn queries a database and feeds the results back to the web shop as a search result.
In this way, the stored information is susceptible to so-called SQL injection (SQLi), which injects arbitrary code into database queries. This makes it possible to read out or change information without permission. In the worst case, the intruders gain control of the entire database.
The attack was discovered in 1998 and has been one of the most persistent threats ever since. Since 2010, SQLi has consistently ranked first among the top 10 security risks for web applications that are regularly published by the independent Open Web Application Security Project (OWASP). In August 2019, the exploit ranked top of the most exploited vulnerabilities in the monthly Global Threat Index of the Israeli security provider Checkpoint for the fourth time in a row.
Not without reason. In March 2019, a hole in the Magento online shop software was discovered and closed, which could be used to read customer data from the dealers’ databases. In 2018 there was a glitch on the website of the Canadian internet service provider Altima (a software or programming error that leads to computer program malfunctions), which was possible with a so-called blind SQL injection (more on this later) access extensive customer database.
One reason why SQLi is so popular with hackers could be that it is a very simple attack. At the 26th DEF CON hacker conference, which took place in Las Vegas in 2018, an eleven-year-old child was able to hack and manipulate a copy of the website for the presentation of the election results in the US state of Florida via SQLi in just ten minutes.
On the other hand, defense measures are as simple as they are effective. In the following, different types of SQLi are described and options for defense are presented.
No matter what type of SQL injection it is, the attacker infiltrates any SQL code into the database query of a web application. This can happen in different ways.
The simplest form of attack is a User input. Web applications usually accept input through a form. The front end then forwards the input to the database in the back end for processing. If the web application does not clean up the input, it is possible to delete, copy or change database contents using injected SQL inputs.
Attackers can too Change cookiesso that they infect the query of the web application. Cookies store information about the client status on the local hard drive. Web applications usually load cookies to process this information. A malicious user or malware can modify them to inject SQL commands into the backend database. Same thing is over Server variables like HTTP header possible. Fake headers that contain any SQL can inject this code into the database if the web application does not clean this input either.
Among the type of blind SQL injection There are attacks on web applications which, while not actively repelling SQLi, do not display the results of the injection visibly. Instead, they either show no obvious reaction or, for example, general error messages that the syntax of the SQL query is incorrect. In this case, the page does not provide any data, but it presents itself in a slightly different way depending on the results of a logical statement injected into the legitimate SQL.
With this method, the information is therefore not identified directly, but rather by means of a series of true or false queries and extracted from the database. This method is considered very time consuming. As soon as the weak point and the desired information are found, the attack can be automated using a number of tools.
SQL injection attacks second order are among the sneakiest, as they do not act immediately, but at a later time. Such harmful but inactive SQL commands can be correctly coded by the application and saved as valid SQL in the database. If another part of the application that is possibly not protected against SQLi then executes the saved SQL statement in a different context, the delayed attack starts.
Assume that a company has built a web application in which customers can access their profile by entering their customer number. The front end of the app routes the number entered into the back end. The database executes an SQL call there and returns the result to the application, which displays it to the user.
So our user enters his number 1234567 in the frontend.
The query in the backend could look something like this:
WHERE customer_id = ‘1234567’
Suppose the user enters the following customer number in a field of the web form instead:
1234567; DELETE * customers WHERE ‘1’ = ‘1
The database in the backend would then run this SQL:
WHERE customer_id = ‘1234567’;
WHERE ‘x’ = ‘x’
Databases execute several SQL statements in sequence if they are separated by a semicolon (;). If the input is not cleaned up with regard to the single quotation mark (‘), attackers can delete the entire table.
This is a deliberately simple example, but every SQLi works on the same principle: Uncleaned input via a web application executes any SQL code in the database.
Since SQLi attacks are fairly straightforward, it didn’t take long for them to be automated. Tools like SQLninja, SQLmap or Havij are available to attackers as well as defenders and enable companies to test their web applications for vulnerabilities against SQLi.
For example, SQLmap is a good option because it supports almost every major database, including MySQL, Oracle, PostgreSQL, Microsoft SQL Server, Microsoft Access, IBM DB2, and SAP MaxDB. It is available for all common operating systems and recognizes the most popular injection loopholes in web applications. This allows you to quickly determine whether the measures to clean the input actually work.
There are two ways to detect SQL injection attacks. A web application firewall (WAF) can examine incoming traffic for manipulative inputs in accordance with previously defined rules and, if necessary, ward them off. An intrusion detection system (IDS) is useful for monitoring the database itself. A network-based IDS monitors all connections to the database and raises the alarm in the event of suspicious activity. A host-based IDS keeps an eye on the log files of the web server and reports irregularities.
A comprehensive and detailed description of all relevant protective measures can be found in the SQL Injection Prevention Cheat Sheet by OWASP. Below we present a selection of the most important ones.
As with most of the areas of attack on corporate IT, the same applies here: good patch hygiene solves many problems. Vulnerabilities in applications and databases that hackers can use for SQL injection are regularly discovered and corrected. It is therefore important to keep patches and updates up to date.
For the basic protection It is important to regulate database access via SQL in such a way that all entries are cleaned up before execution. This means that unusual characters that indicate manipulation are not allowed and measures such as escape sequences are used to ensure that inputs are not accidentally accepted as commands. It is also advisable to filter all entries by context. For example, a phone number should only allow numeric entries. So-called prepared statements prevent the purpose of a query from being changed, even if an attacker enters different commands.
In the event that there is a loophole despite the cleaning, the Account privileges restrict from database users. The principle of minimum authorizations should be applied. The application has just enough room to maneuver that it fulfills its task – none other than that. For example, the web application can only have read and no write access. In addition, commands such as “DROP TABLES”, which deletes the entire database, should not be executable.
Also Stored procedures, functions that execute a sequence of stored commands in the database with a single call, make SQLi more difficult – if not entirely impossible. Stored procedures should be written for this if the web application only has to execute a few SQL queries. As a rule, only the database administrator is authorized to create and edit them. It is important to ensure that many databases already have predefined stored procedures that are likely to be known to the attackers. If these are not absolutely necessary, they should be removed.
SQL injection is one of the simplest attack vectors on corporate data and therefore even inexperienced attackers can use it to cause great damage. But it is just as easy for companies to close this open flank. All that is required is to set up the communication between the web application and the database with a little care and to implement a few protective measures.