By Josh Brown
SQL injection vulnerabilities occur when any given user is able to access and manipulate data entry that is connected to SQL queries within an uncontrolled space. Given certain inputs, an attacker is able to bypass query validation and obtain unprivileged access to sensitive information. The existence of this vulnerability allows for multiple different attacks on a target, such as privilege escalation, data modification, table destruction, and taking full control of the database server itself.
I was able to replicate an SQL injection on a DVWA to prove this methodology, then I was able to, through research, show how the existence of this vulnerability allowed me to obtain sensitive information quickly and easily through the use of the program Burp Suite. Burp Suite allows the user to (in this use case) modify packet requests to modify and execute commands on the SQL database table, which is used and abused.
SQL, also known as Structured Query Language, is a language that allows you to access and manipulate databases that store data. Developed by Donald Chamberlin and Raymond Boyce in IBM in 1970, SQL (originally created as Structured English Query Language (SEQUEL)) was created in order to interact with IBM’s System R, which was a primitive version of the types of databases that we see today.1
Over time, there have been many forms of SQL that have developed over the years, such as MySQL, NoSQL, SQL Server, etc. Even though each was designed with a unique purpose in mind, all forms allow you to execute queries, retrieve data, and update records within a database setting. Because of this, SQL injection was considered to be one of the top 10 web application vulnerabilities of both 2007 and 2010 by OWASP, making it a severe security threat that could be universally applied.2
The first SQL injection attack documented was by “rain.forest.puppy,” also known as Jeff Forristal in 1998. Forristal documented a Microsoft SQL server in which he was able to gain access to previously protected user information, such as names, phone numbers, addresses, and more through the use of normal user inputs within the data fields. Though this was the first documented attack, however, it didn’t attract much attention until the threat examination of the U.S. in 2002.3
Previously, SQL injection was exploited using a set of guesses and checks, where the attacker would use certain pass phrases to see whether or not they would be able to bypass any input validation or get a unique response from the server. This allowed a very primitive line of defense, but that only lasted until newer tools, such as BurpSuite, were created that allow packet manipulation and response parsing.
To start, here is a list of the software that I used to perform a basic SQL injection attack and the links to download it:
Quick Notes for the installation guide on DVWA:
In the directory of /etc/php/(version)/(web service), two options need to be enabled:
allow_url_fopen = On
allow_url_include = On
These two options are crucial because they allow both the treatments of URLs as files and include/require to open URLS as files.
There are multiple types of SQL injections, however the one that I was able to perform was a boolean-based blind SQL injection attack. In order to replicate my experiment, you need to visit your DVWA hosted on your local network. For both exercises, I used the “medium” difficulty of the website, which is the highest level of security that you can have in order to perform the attack on this website. After you have selected the proper difficulty, visit the SQL Injection (Blind) tab, as seen below:
From here, you need to configure your Burp Suite to a proper proxy in order to start capturing information from your browser’s requests. After your proxy is configured, you need to enable “Intercept is on” in the Proxy tab of Burp Suite, shown below. This setting will allow us to manage and manipulate every single request and response that is sent to and from our target, which is exactly what we want from this kind of attack.
So, if we use an id of “1” as our entry into the allowed field with our Burp Suite configurations posted, this is what the content of the message looks like. We have a standard http POST request, with different headers such as Content-Length, Cache-control, Origin, Referrer, and many more, which are not unordinary. However, at the bottom, we can see 2 potential parameters that we can manipulate: “id” and “Submit.” The “submit” parameter in this case just means that we are submitting a request to the SQL database, which is essentially a true/false flag, so we shouldn’t manipulate it. However, the “id” parameter is a user-entered parameter that is checked by the table for validity of some sort.
The “id” parameter is exactly what we’re looking for when we want to perform this kind of attack. The parameter is checked so that it can perform a table look-up, or in other words it is executing a table query with a given parameter, so here we know that SQL injection can potentially be abused.
If we modify the “id” parameter (either by modifying the raw packet or by using BurpSuite’s Inspector tool) from “1” to “1 or 1 = 1” we can conduct a preliminary examination of what the field returns if we try to execute commands from it.
Note: Most tables cannot interpret a “space,” so if you’re modifying the raw packet you need to use the hex character for the table.
The return from this command is everything that the table has in it with an “id” identifier, because what we are essentially doing is we are requesting all data that has “id” set to “True.” (meaning they have an id) Given this output from our command, it is feasible that we can perform some more advanced SQL injection to see if we can possibly obtain even more sensitive information.
Shown in the image below, you can see that you can simply execute whatever normal SQL command you desire on the table on DVWA. In this example, I requested both the username and password from the table, “users”. The return of this command should output the names of the users, followed by their passwords.
As you can see, the table query returns 2 separate query results. This is because we’re actually performing 2 separate queries. The first one is simply asking the table “what is true?” and the second one is the select statement that we added to the request. This is evidence of a wildly successful Blind SQL injection attack.
SQL injection both has been and currently is a very dangerous vulnerability that can be exploited very easily given the right techniques and the wrong steps to prevent this type of attack. As shown in my example of basic blind SQL injection, using simple packet modification using Burp Suite has made obtaining passwords easier than ever, to the point where you don’t even need to understand what you’re exploiting to understand what’s happening. This is a dangerous shift to the modern day where we see more and more companies and businesses using databases to store confidential information, which is why it was in the top 10 most dangerous vulnerabilities labeled by OWASP in 2007 and 2010.
- Not Allowing User Based Input:
Escaping all user input allows for no room for error, because the user would not be able to input any command what-so-ever, so there is no vulnerability.
- Preparing Input:
You could prepare input in the form of a certain format to where the user could only input data in a certain way, so if it doesn’t meet the criteria of the validation, no data is fetched, so no commands are executed on the table.
- “Database SQL Reference.” Moved, 10 July 2005, docs.oracle.com/cd/B19306_01/server.102/b14200/intro001.htm.
- Foundation, O., 2021. [online] Owasp.org. Available at: https://owasp.org/www-pdf-archive/OWASP_Top_10_2007.pdf [Accessed 2 May 2021].