What’s an SQL Injection?

SQL Injection

  1. What is an SQL injection?
  2. URL encoding
  3. Types of SQL injections
  4. How basic SQL injections work


What is an SQL injection?

This code injection technique is used to attack data-driven applications. Attackers can insert SQL statements into an entry field on a vulnerable website for execution. A common reason for using this attack is to dump database contents for the attacker to gather information. This attack is brought to you by programmers who do not practice common security practices. Luckily, application developers have been making the proper changes to this vulnerability however, there are still many undiscovered vulnerable applications out there. Let’s look at how this attack may be conducted.


URL encoding

Before we get into types of SQL injections we must first understand what URL encoding is. You have probably noticed by now that URLs do not contain most special characters such as spaces. Let’s say we wanted to put a space into a URL we would type %<hex value of space> which would be “%20”. This would be translated as a space when decoded. Luckily for us, this process is automated in common web browsers such as google chrome. Try it for yourself, go to a website and after the URL insert “ and 1=2” when you press enter it will likely translate to “%20and%201=2”

There are many tools online to act as a URL decoder/encoder and one that I recommend would be https://meyerweb.com/eric/tools/dencoder/


Types of SQL injections

For this topic, I will be paraphrasing from https://www.acunetix.com/websitesecurity/sql-injection2/ which gives a good overview of the different types of SQL injections (SQLi). I will reword and simplify where I can.

In-band SQLi –
This is the basic SQLi where an attacker can use one platform to launch an attack as well as gather the results from the attack. The two most common examples of an In-band SQLi are Error-based and Union-based SQL injections.

Error-based SQLi –
This is an In-band injection and relies on error messages that are thrown by the database server to gather information about the structure of the database. While this is not a direct attack it is certainly a great method for obtaining helpful information.

Union-based SQLI –
Another In-band injection technique, Union-based SQLi utilizes the UNION SQL operator. This is helpful to combine the results of two or more SELECT statements into one result. Then the result of multiple queries will be returned as part of the HTTP response.

Inferential SQLi (Blind SQLi)
This type of injection attack is a bit more time consuming for an attacker, however it can be just as dangerous as any other SQLi. Instead of the attacker viewing the results and obtaining the information they attempt to reconstruct the database strucuture by sending payloads, observing the web application’s response, and the behavior of the database server after these actions. The two types of blind SQL injections are Blind-boolean based and Blind-time based SQLi.

Boolean-based (content-based) Blind SQLi –
This injection technique relies on sending SQL queries that will return either a TRUE or FALSE result. Depending on the result, the content of the HTTP response will be different or remain the same. This is how the user can determine if the result was true or false. No data is being returned from this injection however an attacker could eventually enumerate a database. This can be very time consuming since this must be done character by character.

Time-based Blind SQLi –
Another technique that relies on SQL queries. This technique forces the database to wait for a specified amount of time in seconds before responding. Depending on the time it takes for the database to respond correlates to if the query is true or false. This gives us the same ability as the Boolean-based Blind SQLi and has the same problem which is that this technique could be very time consuming.

Out-of-band SQLi –
This injection is not very common, this is because for it to work, multiple features must be enabled on the database server being used by the web application. This injection occurs when an attacker is unable to utilize the same channel to launch the attack and father the results. Out-of-band techniques are a great alternative to Inferential or Blind SQLi techniques.  These Out-of-band techniques rely on the database server’s ability to make DNS or HTTP requests to deliver data. The attacker can manipulate the features available on the database server and send the results directly to a server the attacker controls. For example, the xp_dirtree command can be used to make DNS requests to the server owned by the attacker.  DNS requests can  be used to exfiltrate the data and allow the attacker to obtain the information they worked so hard to obtain.

How basic SQL injections work

An example of a vulnerability for a username search input field on a website could be:

  • Attacker understands that the application utilizes SQL to compare and authenticate user information.
  • A common vulnerable username query would be for example:
    SELECT * FROM users WHERE name = ‘ “ + username + “’;”
    as we can see the query takes in the input from the application and simply appends it to the executed function. If a person enters “myUsername” the query will be
    SELECT * FROM users WHERE name=’myUsername’;
    This will search the database for a name “myUsername” inside the users table and returns that username
  • So now imagine what the attacker can do here. Let’s say he wants to see all the usernames in the name table. He can type the following: “ ‘ OR ‘1’=’1 “ which will give us
    SELECT * FROM users WHERE name=’’ OR ‘1’=’1’
    Now the “OR ‘1’=’1’” is going to result to TRUE therefore it will reveal all the usernames from users.
  • Let’s say the function doesn’t just end there. A common trick is to block the remainder of the query by appending any of the three SQL comment initializers. These are “–”, “({“, and “/*”.

So, an attacker could input something such as:
‘ OR ‘1’=’1’ /*

And it will complete the query adding the OR statement to return the vulnerable data as well as ending any additional code that is meant to execute along with the query.

The issue doesn’t end with simply revealing data. Attackers can manipulate and even add or delete data if the vulnerability is severe enough. Let’s look at an example where an attacker removes the users data from an application:

  • Malicious user enters into the username input field as we did in the previous example
    a’; DROP TABLE users;

This inputted into the input field will execute
SELECT * FROM users WHERE name=’a’; DROP TABLE users;

You can see here that we are searching for a name ‘a’ but right after that we are going to execute our malicious command “DROP TABLE users” which will delete the users table. This could cause major issues especially if the data is not backed up.

  • Most SQL server implementations allow multiple statements to be executed in one line as we do here however, certain SQL APIs do not allow this. This is a feature that prevents attackers from injecting separate queries although it still does not stop them from modifying pre-existing queries.


Blind SQL injection –

So, we have a web application that is vulnerable to an SQL injection. However, when we try the attack the results of the injection are not visible to the attacker. A common scenario of this is when programmers show generic error messages when an input is invalid but does not mitigate the vulnerable code.

A common way to test if this vulnerability is apparent on a web application you can follow this example:

  • User conducts a query, such as selecting an item listed for sale online. Let’s say the item id is 62 and the website is “http://www.shopExample.com”
  • Going to item 62 will present us with the URL “http://www.shopExample.com/item.php?id=62” There are many other ways this URL could be written but this is a common example. As we now know this is simply an SQL query for item id 62 from a table that we will call “Shop_table”.
    SELECT * FROM Shop_table WHERE id = 62
  • The attacker can now attempt to see if this web application is vulnerable by creating a false search by changing the URL to conduct a specific query such as
    http://www.shopExample.com/item.php?id=62 and 1=2
  • This will cause the query to return false and if so then we will try to alter the URL again to see if we can have it return the items information again by doing
    http://www.shopExample.com/item.php?id=62 and 1=1
  • If the result is once again true then we know the web application is vulnerable to SQL injection


Time Based Blind SQL injection

  • Another way to test if an application is vulnerable is to use a time based SQL injection
  • To do this we utilize the various delay methods depending on the applications API
  • An Example of how this might work would be to input in the URL
    http://www.shopExample.com/item.php?id=62’ and sleep(10)#
    This will delay the query for id=62 for 10seconds.
  • As you can probably guess we can now most likely append other SQL injection techniques after this delay. We also now know that the comment character for this API is ‘#’ which an attacker could also use for future attacks on the application.
  • A common attack would be utilizing a delay after attempting a comparison. For example an attacker could input “unknown_value = test_value and sleep(10)#” which will provide a delay for when the test_value is equal to the unkown_value which would then provide the malicious user the unknown_value.


Now that you have a basic understanding of what an SQL injection is and what it does, I strongly recommend you get some hands on experience! This can be done easily using a virtual lab environment which can be as simple as installing the virtual machine file from a distributor. A list of 15 good practice resources can be found here: https://www.checkmarx.com/2015/04/16/15-vulnerable-sites-to-legally-practice-your-hacking-skills/

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Create a website or blog at WordPress.com

Up ↑

%d bloggers like this: