Relational Database Management Systems (RDBMS) such as Oracle, MySQL and Microsoft SQL Server belong according to the current DB Engines ranking one of the most popular on the market. Considered highly reliable and avoiding inconsistencies in data records, they have been the established standard for databases in most companies for decades.
The Structured Query Language (SQL) database language is most commonly used to query and process the data in it. For example, users communicate through a product search mask in a web shop with a server, which in turn searches a database and returns the results to the web shop as search results.
In this way, the information stored is susceptible to what is known as SQL Injection (SQLi), which injects arbitrary code into database queries. This makes it possible to read or change information without permission. In the worst case, the intruders gain control of the entire database.
The attack method was discovered in 1998 and has been considered one of the most persistent threats ever since. below the Top 10 Web Application Security RisksRegularly published by the independent Open Web Application Security Project (OWASP), SQLi has consistently ranked in the top three since 2010.
Not wrong. So in March 2019 there was one Vulnerability in the online shopping software Magento discovered and closed, allowing customer data to be read from dealer databases. In 2018, the website of the Canadian internet provider Altima . stated a glitch (a software or programming bug that causes computer programs to malfunction) that made it possible to access an extensive customer database through a so-called blind SQL injection (more on this later).
One of the reasons SQL Injection is so popular with hackers may be that it is a very simple attack. At the 26th DEF CON hacker conference held in Las Vegas in 2018, an 11-year-old child was able to obtain a copy of the Florida state election results website hack and manipulate in just ten minutes via SQLi.
On the other hand, defensive measures are as simple as they are effective. Different types of SQLi are described below and ways to defend against them are presented.
Regardless of the type of SQL injection, the attacker injects arbitrary SQL code into a web application’s database query. This can be done in several ways.
The simplest form of attack is via a user input. Web applications typically accept input through a form. The frontend then forwards the input to the database in the backend for processing. If the web application does not clean up the input, it is possible to delete, copy or modify database contents via injected SQL input.
Attackers can do that too change cookies, so that they infect the web application’s query. Cookies store customer status information on the local hard drive. Web applications typically load cookies to process this information. A malicious user or malware can modify them to inject SQL commands into the backend database. the same is over Server variables such as HTTP header possible. False headers containing arbitrary SQL can inject this code into the database if the web application doesn’t clean up this input as well.
Under the type of blind sql injection There are attacks on web applications that do not actively defend against SQLi, but do not show the results of the injection visibly. Instead, they either show no obvious response, or, for example, general error messages that the SQL query syntax is incorrect. In this case, the page will not return any data, but it will look slightly different depending on the results of a logical statement injected into the legitimate SQL.
With this method, the information is not identified directly, but through a series of true-or-false queries and extracted from the database. This method is considered very time consuming. However, once the vulnerability and the desired information are found, the attack can be automated using a range of tools.
SQL Injection Attacks second order are among the most devious, as they do not spring into action immediately, but at a later date. Such malicious but inactive SQL commands can be properly encoded by the application and stored as valid SQL in the database. If another part of the application, which may not be protected from SQLi, then executes the stored SQL statement in a different context, the delayed attack starts.
Suppose a company has built a web application where customers can view their profile by entering their customer number. The frontend of the app forwards the entered number to the backend. The database makes 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 might look something like this:
WHERE customer id = ‘1234567’
For example, 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’;
TRUE ‘x’ = ‘x’
Databases execute multiple SQL statements in succession if they are separated by a semicolon (;). If the input is not cleaned up before the single quote (‘), attackers can delete the whole table.
This is an intentionally simple example, but every SQLi works on the same principle: raw input from a web application executes arbitrary SQL code in the database.
Because SQLi attacks are relatively simple, it didn’t take long for them to become automated. Tools such as SQLninja, SQLmap or Havij are available to both attackers and defenders and allow 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 major operating systems and detects the most common loopholes in web applications. This makes it possible to quickly determine whether the measures to purge the imports are also effective.
There are two ways to detect SQL injection attacks. A web application firewall (WAF) can examine incoming traffic according to predefined rules for manipulative input and, if necessary, reject it. When it comes to monitoring the database itself, an intrusion detection system (IDS) comes in handy. A network-based IDS monitors all connections to the database and warns of suspicious activity. A host-based IDS monitors the web server’s log files and reports irregularities.
A comprehensive and detailed description of all relevant protective measures can be found in the: SQL Injection Prevention Cheatsheet by OWASP. Below we present a selection of the most important.
As with most enterprise IT attack surfaces, the same is true here: good patch hygiene solves many problems. Application and database vulnerabilities that hackers can use for SQL injection are regularly discovered and fixed. It is therefore important to always keep patches and updates up-to-date.
For the basic protection It is important to arrange database access through SQL so that all entries are cleaned before they are executed. This means no unusual characters indicating tampering are allowed and measures such as escape sequences are used to ensure inputs are not accidentally accepted as a command. It’s also a good idea to filter all input by context. For example, a phone number should only allow numeric entry. So-called prepared statements prevent the target of a search from being changed, even if an attacker enters several commands.
If, despite the cleaning, there is still a loophole, then the following applies: Account rights of database users. The principle of least privilege must be applied. The application has just enough room for maneuver to fulfill its task – nothing more than that. For example, the web application may only have read permissions, but no write permissions. In addition, commands like “DROP TABLES“, which deletes the entire database, may not be executable.
Also stored procedures, functions that execute a series of stored commands in the database with a single call, make SQLi more difficult – but not completely impossible. If the web application only needs to run a few SQL queries, then stored procedures must be written for them. Usually only the database administrator has permission to create and edit them. It is important to note that many databases already have out-of-the-box stored procedures that the attackers are likely to be aware of. If they are not absolutely necessary, they should be removed.
SQL Injection is one of the simplest attack vectors on corporate data, and so even inexperienced attackers can exploit it to wreak havoc. But it is just as easy for companies to close this open flank. All you need to do is set up the communication between the web application and the database with a little care and take some protective measures.