SQL INJECTION INTRODUCTION

What are SQL injections?

An SQL injection is a kind of injection vulnerability in which the attacker tries to inject arbitrary pieces of malicious data into the input fields of an application, which, when processed by the application, causes that data to be executed as a piece of code by the back end SQL server, thereby giving undesired results which the developer of the application did not anticipate. The backend server can be any SQL server (MySQL, MSSQL, ORACLE, POSTGRESS, to name a few)

The ability of the attacker to execute code (SQL statements) through vulnerable input parameters empowers him to directly interact with the back end SQL server, thereby leveraging almost a complete compromise of system in most cases.

What are different types of SQL injections?

SQL injections can be classified and categorized in different ways, based on the type of data extraction channel, the response received from server, how server responses aid in leveraging the successful exploitation, impact point, etc.

Based on the data extraction channel

• Inband or inline
• Out-of-band

SQL injections that use the same communication channel as input to dump the information back are called inband or inline SQL Injections. This is one of the most common methods, readily explained on the Internet in different posts. For example, a query parameter, if injectable, leads to the dumping of info on the web page.

Injections that use a secondary or different communication channel to dump the output of queries performed via the input channel are referred to as out-of-band SQL injections. For example, the injection is made to a web application and a secondary channel such as DNS queries is used to dump the data back to the attacker domain.

Based on the response received from the server

• Error-based SQL injections
  • Union query type.
  • Double query Injections.

• Blind SQL Injections
  • Boolean-based blind injections.
  • Time based blind injections.

Error-based SQL injections are primarily those in which the SQL server dumps some errors back to the user via the web application and this error aids in successful exploitation. In the image below, the yellow line displays the error. These will be discussed further in this post and in related posts to come.

Blind SQL injections are those injections in which the back-end database reacts to the input, but somehow the errors are concealed by the web application and not displayed to the end users. Or the output is not dumped directly to the screen. Therefore, the name “blind” comes from the fact that the injector is blindly injected using some calculated assumptions and tries.

Based on how the input is treated in SQL query (what data type)

• String-based
• Numeric- or integer based

Based on how the input parameter would be treated in the back end SQL query, an injection can be classified as string- or integer-based.

Based on the degree/order of injections (where the impact happens)

• First-order injections.
• Second-order injections.

The degree or the order of injection identifies the way in which the injection yields the output. If the injection directly delivers the result, it is considered to be a first-order injection, but if the injection input yields no successful result in extraction, but instead impacts some other result which the attacker can take advantage of on some other place/page, it is called a second-order injection. Consider second-order injections similar to stored XSS injections, where the input is stored in the application and later rendered on some other page, thereby impacting that page indirectly because of initial malicious input.

Based on the injection point location

• Injection through user input form fields.
• Injection through cookies.
• Injection through server variables. (headers-based injections)

Why does SQL injection happen?
Generally when an application is communicating with the backend database, it does so in the form of queries with the help of an underlying database driver. This driver is dependent on the application platform being used and the type of backend database, such as MYSQL, MSSQL, DB2, or ORACLE.

A generic login query would look something like this:

`SELECT Column1, Column2,Column3 FROM table_name WHERE username=’$variable1′ AND password=’$variable2′;`

We can split this query into two parts, code section and the data section. The data section is the $variable1 and $variable2 and quotes are being used around the variable to define the string boundary.

Let us try to walk through the process in a crude way. Say at the login form, the username entered is Admin and password is p@ssw0rd which is collected by application and values of $variable1 and $variable2 are placed at their respective locations in the query, making it something like this.

`SELECT Column1, column2, Column3 FROM table_name WHERE username=’Admin’ AND password=’p@ssw0rd’;`

Now the developer assumes that users of his application will always put a username and password combination to get a valid query for evaluation by database backend. What if the user is malicious and enters some characters which have some special meaning in the query? For example a single quote. So, instead of putting Admin, he puts Admin’, thereby causing an error thrown by the DB driver. Why? Because of the unpaired quote entered by the user breaking the application logic.

We will discuss the process in detail. To summarize: Whenever an attacker is able to escape the data boundaries, he can append data which then gets interpreted as code by the DB Driver and is executed on the SQL back-end, thereby causing SQL injection.

ERROR-based SQL injections

In general, all programming languages give developers a flexibility to debug and fix their applications by using some inbuilt error-handling functions/libraries. These could be some explicit function, classes, or methods that deliver friendly error messages so that the troubleshooting experience can be streamlined and detecting the part of code responsible for raising those exceptions can be easier.

These functions should be controlled before an application goes to production because they can dump a lot of sensitive info about the application and underlying logic, thereby making it easy for a bad guy to exploit the application.

Therefore, those applications where these error-handling functions are available to aid in gaining useful info about the application or in dumping the database info by means of SQL interaction are classified as error-based SQL Injections.

Based on the way data is extracted using helpful errors, the error-based injections can be classified into two main types:

• Union-query type
• Double-query type