Injection flaws is the number one kind of vulnerability in the OWASP top 10 list from 2013; included, among others, the one that we will test in this recipe: SQL Injection (SQLi).
Most modern web applications implement some kind of database, be it local or remote. SQL is the most popular language. In a SQLi attack, the attacker seeks to abuse the communication between application and database by making the application send altered queries by injecting SQL commands in forms' inputs or any other parameter in the request that is used to build a SQL statement in the server.
In this recipe, we will test the inputs of a web application to see if it is vulnerable to SQL Injection.
Log into DVWA and then perform the following steps:
- Go to SQL Injection.
- Similar to the previous recipe, let's test the normal behavior of the application by introducing a number. Set User ID as 1 and click on Submit.
By interpreting the result, we can say that the application first queried a database whether there is a user with ID equal to 1 and then returned the result.
- Next, we must test what happens if we send something unexpected by the application. Introduce
1'in the text box and submit that ID.
This error message tells us that we altered a well-formed query. This doesn't mean we can be sure that there is an SQLi here, but it's a step further.
- Return to the DVWA/SQL Injection page.
- To be sure if there is an error-based SQL Injection, we try another input:
1''(two apostrophes this time):
No error this time. This means, there is a SQL Injection in that application.
- Now, we will perform a very basic SQL Injection attack, introduce
'or'1'='1in the text box and submit it.
It looks like we just got all the users registered in the database.
SQL Injection occurs when the input is not validated and sanitized before it is used to form a query to the database. Let's imagine that the server-side code (in PHP) in the application composes a query, such as:
$query = "SELECT * FROM users WHERE id='".$_GET['id']. "'";
This means that the data sent in the id parameter will be integrated, as it is in the query. Replacing the parameter reference by its value, we have:
$query = "SELECT * FROM users WHERE id='"."1". "'";
So, when we send a malicious input, like we did, the line of code is read by the PHP interpreter, as:
$query = "SELECT * FROM users WHERE id='"."' or '1'='1"."'";
And concatenating:
$query = "SELECT * FROM users WHERE id='' or '1'='1'";
This means that "select everything from the table called users if the user id equals nothing or if 1 equals 1"; and 1 always equals 1, this means that all users are going to meet such a criteria. The first apostrophe we send closes the one opened in the original code, after that we can introduce some SQL code and the last 1 without a closing apostrophe uses the one already set in the server's code.
A SQL attack may cause much more damage than showing the usernames of an application. By exploiting these vulnerabilities, an attacker may compromise the whole server by being able to execute commands and escalate privileges in it. He may also be able to extract all the information present in the database, including system usernames and passwords. Depending on the server and internal network configuration, a SQL Injection vulnerability may be the port of entry for a full network and internal infrastructure compromise.