SQL stands for Structured Query Language and it is a domain-specific language designed to manipulate data in a Relational Database Management System (RDMS) and for stream processing in a Relational Data Stream Management System (RDSMS). The two main advantages of the language is that it was the introduction of accessing multiple records with one command and it discarded the need for administrators to express how to reach a record. At the point in time, the language revolutionized read/write operations for databases and became the popular choice for RDMSs and RDSMSs.

With that in mind, an SQL Injection is a type of attack which takes advantage of the language by using a code injection technique on data-driven applications. The attack inserts malicious SQL statements into such applications through a security vulnerability in the application which could allow the attacker to spoof their identity, tamper with the database’s data, allow disclosure of the database’s data, destroy or corrupt the database’s data, or even make themselves an administrator of the database. As such, depending on the type of data these applications revolve around, the severity of these attacks can be medium to high.

Types of SQL Injections

There are four main types of security vulnerabilities which can lead to an SQL Injection attack. One of these vulnerabilities is the incorrect filtering of escape characters of user input which is then passed into an SQL statement. This means that the affected SQL statement can potentially be manipulated on the database by the end-user of the application.

Incorrect type handling is another security vulnerability which gives an opportunity for SQL injection attacks to strike. This is when a user-supplied field is not strongly typed or checked for type constraints. What is meant by this, is that the field might be intended for a specific type of data; such as, an integer, but the programmer itself has made no checks to actually confirm that what a user enters into the field is actually an integer.

A Blind SQL Injection occurs when a vulnerable web application is targeted by an SQL Injection attack where the results are not visible to the attacker. The web page of the application may not even be the one with the vulnerability but it will display differently depending on the SQL statement and accompanying injection called for the page. Usually, this attack is very time-exhausting because a new statement is required to be made for each bit recovered and depending on the attack’s structure, there could be many unsuccessful requests caused in the statement. Recently, there have been improvements to recover multiple bits from each request when there was no successful request for the attack. In response to this, however, there have also been tools created which can automate these attacks once the vulnerability’s location and target information has been confirmed.

Second Order SQL Injection, the fourth type, is achieved when values which have been submitted contain malicious commands that are stored instead of immediately executed. These attacks require a deeper understanding of submitted values and how they are later used to work. This is because in some cases, the application could correctly encode an SQL statement and store it as if it was valid SQL while another part of the application without protection against these types of attacks might execute the stored statement.

Mitigation

Despite the possible severity of an SQL Injection attack, it is still a very common type of code injection that is easy to mitigate and prevent the right practices.

Parameterized statements are common with most development platforms and can be used instead of embedding user input into statements directly. This means that the placeholder in the statement can only store a value of a given type and therefore; any attempts of SQL Injection will simply result in a strange or invalid parameter entered.

Escaping is another method; albeit an error-prone one, which escapes characters that have some kind of special meaning in SQL. The SQL Database Management System (DBMS) manual actually provides developers with a list of these characters which allows this to be possible.

Pattern checking can be done to check integer, float, boolean, and string parameters to ensure their value is valid for their type. Even strings which must follow some strict pattern (UUID, date, etc) can use this to check if their value matches the pattern.

Database permissions can also be limited when logging into a web application can also be done to mitigate the effects of an SQL Injection as well.