Hello everyone and welcome!
In today’s blog, we will be exploring the topic of SQL Injection, and what tools we can use in order to automate that process of attacking web applications. I learned many different topics last week about different ways to attack web applications, but SQL injection was something that I felt would be the most interesting to talk about in today’s blog.
The topics we will be exploring are:
- What is SQL injection and how does it work?
- How can we check if a website is prone to SQL injection?
- Union Operator and its requirements
What is SQL Injection and How does it Work?
SQL injection is a technique that hackers utilize to gain unauthorized access of SQL databases. Once they gain access to the database – and depending on the type of access they have, they can do whatever they like to it. If it is a database that is used to store login credentials, hackers can insert their own username and password to the database and login to the application with that. Even worse, if they can alter the privileges of the new user they create – granting them access to the whole application.
When performing SQL injection, the hacker has to look for any element of the website that allows the client to input some text that will be sent back to the server. For example, a search bar can be an access point for a hacker if it does not properly sanitize the input that goes back to the server.
How Can We Check If A Website Is Prone to SQL Injection?
Well, there are two main methods of checking for SQLi:
- Checking by hand every element that allows the client to input data
- Use a tool that automates the whole process
Checking by Hand
You may rarely use this method compared to the automated method, but it is definitely crucial to learn the process of identifying this type of vulnerability. Just like how I stated earlier, you need to find every single element on the website, on every page of that domain that you can access, that allows you to input a string. The following places are the most common places you can input data to send back to the server:
- The URL query
- Username and password fields
- Quantities of products
- Search bar
The list goes on and on. Use your imagination to see what input fields you can manipulate. Once you have written down all of the user input fields the website contains, its time to test these fields to see if the input is properly sanitized.
Note:
For those who are not familiar with what “sanitizing the user input”, it means that the server that receives the input from the client; scans the input and modifies any special characters that can be used in a malicious manner.
How Do We Test These Input Fields We Just Recorded?
Let me explain one last concept to you before we start actually injecting our own SQL. Let’s say on the server side code (the code that the server runs on to process the input from the client), it uses the following statement to process the username and password of an account:
SELECT * FROM admins WHERE username = 'usernameFromClient' AND password = 'passwordFromClient'
There is a big issue with the statement above. The variable usernameFromClient, as well as passwordFromClient, are both gateways for the hacker to inject their own SQL code. Here is a great example, let’s say on the website I enter my username as admin’ # – yes I meant to keep the single apostrophe as well as the pound-sign. This is what happens to the statement now:
SELECT * FROM admins WHERE username = 'admin' #' AND password = 'passwordFromClient'
Pay close attention! Do you see why the text color is red and green? The text in red is the active code that is still being run on the server from what we said before, BUT we entered an extra single quote – remember in code (depending on the language) we put strings into either single or double-quotes. What happened here is that the single quote we entered closed the string off – now the characters after that are being read in as code for the server! The reason I put a pound-sign is that it will comment out the rest of the code that the server had: #' AND password = 'passwordFromClient'
so it doesn’t even validate the password. In some cases, you can log into the application – and you didn’t even enter a password! The concept behind this type of attack is easy to understand: write a string to the server that will disrupt the code it is running on and once you disrupt it you can inject your own code.
Great question! First, lets talk about what we want to find:
- The website spitting an error message regarding the query we input for SQL
- Somehow bypassing an access controlled session or authentication section
Now, what we want do is enter the following statements into the input to see if we can get an error message from the server:
- admin’
- 1=1–
- 1=1 #
- Using the UNION operator to send your own query
Note:
The examples above have some sort of symbol that represents commenting out a line of code. Some symbols might not work like others – Try all these at the end of your injection to see what works:
—
#
/*
The symbols that don’t send you an error message back are usually the ones to use for your injection.
Union Operator and its Requirements
The UNION operator in SQL is an operator that combines two or more SELECT statements. This can be very useful with SQLi (SQL injection) because we can use the UNION statement to fetch data from the database and find out what we are working with. Before we show an example of how to use it let us first explain the requirements when using UNION:
- The two result sets MUST have the same structure – meaning it mus have the same number of fields and the same data types to match
- The attacker must know the name of the table of interest and its column names
If you use the wrong number of columns the web application will output an error message that is usually structured with the following format:
The used SELECT statements have a different number of columns
Here is an example of using the UNION operator:
Here we see in the name query the username: Herp Derper’ is used followed by the UNION statement. Which in short, fetches the columns “isadmin” from the table “sqlol.users”. The sql statement then returns the table from the database and displays onto the screen.
Note:
You will be put in some situations where you will successfully inject an SQL query into a web application, but there will be no output. This is called Blind SQLi.
Steps to finding out the number of columns and what values it accepts
We can find out the number of columns by entering in this pattern for the injection query:' UNION SELECT NULL--
' UNION SELECT NULL, NULL--
' UNION SELECT NULL, NULL
, NULL--
Every time you do this it will fail UNTIL you get the number of columns correct. Remember that NULL matches any data type so here we can avoid the problem of inputting the wrong data type. We just only want to deal with one error at a time.
Now that we found the number of columns we want to find the string datatypes of those columns as well:' UNION SELECT 'd', NULL, NULL--
' UNION SELECT NULL, 'd', NULL--
' UNION SELECT NULL, NULL, 'd'--
For every query that succeeds in the position that the inputted string is in, then that specific column has a string field.
Another quick note we can do while using the UNION statement is finding out the version of SQL we are working with. Here is an example of using the keyword @@version (which returns the version):
Peter' UNION select @@version--
Which will then output the version.
Conclusion
We explored many, but not even close to all the topics of SQLi. It is always important to understand the concept of how SQLi works even if you have automated tools to get the job done for you. This type of injection can be very advanced and difficult to understand but with practice on CTFs, you’ll be able to pick it up in no time.
Thanks again for reading and I will catch you all next week!
Peter