SQL Injection – A Primer

**Warning:

This post is part of our educational program. It is not an encouragement for any malicious activities on the internet. Readers of this post are expected to understand the technical steps behind a SQL injection attack. This will help them to avoid falling prey to such attacks. Ethical Securities shall not be held responsible for any misuse of these contents. Stay safe, keep safe.

SQL injection (SQLi) is a server side attack that targets to exploit a specific vulnerability in a Web Application. Almost every web application has a backed function database, used to store the data.

In a SQLi attack, the attacker deploys mechanisms to identify if any parameter in the web application URL (Uniform Resource Locator) can be used as an injection point to inject SQL queries / statements. Such injected queries may retrieve some hidden information stored in the backend database.

What is an injection point?

In simple terms, an injection point is any parameter in a URL that can be exploited to launch an SQL injection attack.

Example:

Say we have a website www.yourstore.com.

This website has a page Articles, which has a list of articles that this company sells. These articles are identified by a parameter ‘article_id’.

So when one clicks on any article on this page, the URL string changes to something like:

http://www.yourstore.com/articles.php?article_id=1

If an attacker can communicate with the back end database of the web application by modifying this parameter article_id, then article_id can be considered as a potential injection point for the vulnerable webpage located at the URL http://www.yourstore.com/articles.php

Using the Injection Point

Now that we know their is an injection point, we can use some basic assumptions based on a basic knowledge of SQL query statements and try to write Boolean Conditions to retrieve more information from the database.

We can modify the SQL string http://www.yourstore.com/articles.php?article_id=1 to

http://www.yourstore.com/articles.php?article_id=99′ OR a=a; — –

Anatomy of the input string

article_id=1′ OR a=a actually translates to a SQL condition like below:

SELECT Article_Name, Description FROM Articles WHERE article_id = 99 OR a=a

Here, Article_Name and Description are columns in the database table Articles. These columns are being retrieved from the table Articles based on the condition article_id=99′ or a=a.

Now we have put 2 conditions here:

1. article_id = 99 (99 is a random guess. This could be anything)

2. a=a (This is a Boolean Condition which is always TRUE.)

If one of these conditions is TRUE, then our SQL query will retrieve some information from the backed database.

Note: OR is a logical operator that is often used with BOOLEAN conditions. This tests if one of the 2 conditions is TRUE.

You can also use AND operator to test if both the conditions are TRUE.

Remember, at this point we are only trying to check the validity of the conditions and what error is displayed on the page. It is not necessary to make the correct guess for article_id number. We will use a tool during automated attack that will try all possible values for this parameter. Right now, we are only trying to be sure, if article_id is actually vulnerable to SQLi attacks.

UNION based Query

Often, Boolean based attacks may not be sufficient to steal valuable data from the backend database. So our next step will be to look for UNION based injection points.

For this we can modify our original URL http://www.yourstore.com/articles.php?article_id=1 to http://www.yourstore.com/articles.php?article_id=1‘ UNION SELECT username, password;– –

Here we specify another SELECT query:

SELECT username, password;– –

Note, username and password are 2 columns that were chosen based on assumptions. These names are not important. You could have chosen any names here. The actual intention is to see the type of error we see in the webpage. From the error displayed on the webpage we can understand if the page is vulnerable to UNION based SQL injection attacks.

Once you are fully certain, that the webpage has an injection point that can be used to launch a UNION based SQL Injection attack, you can move on to the next level to use the sqlmap tool to automate this attack.

Important things to note

  • The above steps are part of the manual testing of SQL Injection vulnerabilities
  • By testing out the vulnerabilities manually and then targeting your automated attack, you can reduce the amount of noise (false alarms)
  • This is a primer meant to explain the basics of SQLi. There are advanced types of SQLi which are out of the scope of this post.

We have purposefully left out any screenshots for this post.

We expect you to understand the SQLi concepts first. For detailed white-papers on various types of attacks deployed during any penetration testing exercise, please contact us here.

Share and Subscribe!

Please do not forget to share this post with your peers. For all future posts, please subscribe to our website. We consider your support as one of the driving factors that help us to keep up our good and honest efforts.

How was that?