SQL Injection Attack Lab

Overview
SQL injection is a code injection technique that exploits the vulnerabilities in the interface
between web applications and database servers. The vulnerability is present when user’s
inputs are not correctly checked within the web applications before being sent to the back-
end database servers.
Many web applications take inputs from users, and then use these inputs to construct SQL
queries, so the web applications can get information from the database. Web applications
also use SQL queries to store information in the database. These are common practices in
the development of web applications. When SQL queries are not carefully constructed,
SQL injection vulnerabilities can occur. The SQL injection attack is one of the most
common attacks on web applications.
In this lab, we have a web application that is vulnerable to the SQL injection attack. The
web application includes the common mistakes made by many web developers. The main
goal is to find ways to exploit the SQL injection vulnerabilities, demonstrate the damage
that can be achieved by the attack, and master the techniques that can help defend
against such type of attacks.

Lab Environment Configuaration

In this lab, we will need three things: (1) the Firefox web browser, (2) the apache web server,
and (3) the phpBB2 message board web application. For the browser, we need to use
several Firefox add-ons to inspect and/or modify the HTTP requests and responses.

Starting the Apache Server

The apache web server is also included in the pre-built Ubuntu image. However, the web
server is not started by default. We have to first start the web server using the following
command:
% sudo service apache2 start
The phpBB2 Web Application. The phpBB2 web application is already set up in the pre-built
Ubuntu VM image. The password information can be obtained from the posts on the front
page. We can access the phpBB2 server using the following URL (the apache server needs
to be started first):
http://www.sqllabmysqlphpbb.com
The source code of web application is located at /var/www/SQL/SQLLabMysqlPhpbb/.

Configuring DNS
This URL is only accessible from inside of the virtual machine, because we have modified
the /etc/hosts file to map the domain name (www.sqllabmysqlphpbb.com) to the virtual
machine’s local IP address (127.0.0.1). We may map any domain name to a particular IP
address using the /etc/hosts. For example you can map http://www.example.com to the
local IP address by appending the following entry to /etc/hosts file:
127.0.0.1 www.example.com

Apache Configuring
The name-based virtual hosting feature in Apache could be used to host several web sites
(or URLs) on the same machine. A configuration file named default in the directory "/etc/
apache2/sites-available" contains the necessary directives for the configuration:
1. The directive "NameVirtualHost *" instructs the web server to use all IP addresses in
the machine (some machines may have multiple IP addresses)
2. Each web site has a VirtualHost block that specifies the URL for the web site and
directory in the file system that contains the sources for the web site. For example,
to configure a web site with URL http://www.example1.com with sources in
directory /var/www/Example_1/, and to configure a web site with URL
http://www.example2.com with sources in directory /var/www/Example_2/, we use
the following blocks:

<VirtualHost *>
ServerName http://www.example1.com
DocumentRoot /var/www/Example_1/
</VirtualHost>

<VirtualHost *>
ServerName http://www.example2.com
DocumentRoot /var/www/Example_2/
</VirtualHost>

We can modify the web application by accessing the source in the mentioned
directories. For example, with the above configuration, the web application
http://www.example1.com can be changed by modifying the sources in the
directory /var/www/Example_1/.
SQL Injection Attack on SELECT Statements
SQL injection is basically a technique through which attackers can execute their own
malicious SQL statements generally referred as malicious payload. Through the malicious
SQL statements, attackers can steal information from the victim database; even worse,
they may be able to make changes to the database. Our employee management web
application has SQL injection vulnerabilities, which mimic the mistakes frequently made by
developers.
We will use the login page from www.SEEDLabSQLInjection.com for this task. The login
page is shown in Figure 1. It asks users to provide a user name and a password. The web
application authenticate users based on these two pieces of data, so only employees who
know their passwords are allowed to log in. our job, as an attacker, is to log into the web
application without knowing any employee’s credential.

$input_uname = $_GET[’username’];
$input_pwd = $_GET[’Password’];
$hashed_pwd = sha1($input_pwd);
...
$sql = "SELECT id, name, eid, salary, birth, ssn, address, email,
nickname, Password
FROM credential
WHERE name= ’$input_uname’ and Password=’$hashed_pwd’";
$result = $conn -> query($sql);
// The following is Pseudo Code
if(id != NULL) {
if(name==’admin’) {
return All employees information;
} else if (name !=NULL){
return employee information;
}
} else {
Authentication Fails;
}
The above SQL statement selects personal employee information such as id, name, salary,
ssn etc from the credential table. The SQL statement uses two variables input uname and
hashed pwd, where input uname holds the string typed by users in the username field of
the login page, while hashed pwd holds the sha1 hash of the password typed by the user.
The program checks whether any record matches with the provided username and
password; if there is a match, the user is successfully authenticated, and is given the
corresponding employee information. If there is no match, the authentication fails.

SQL Injection Attack from webpage

Our task is to log into the web application as the administrator from the login page, so we
can see the information of all the employees. We assume that you do know the
administrator’s account name which is admin, but you do not the password. You need to
decide what to type in the Username and Password fields to succeed in the attack.

SQL Injection Attack from command line

Using command line tools, such as curl, which can send HTTP requests. One thing that is
worth mentioning is that if we want to include multiple parameters in HTTP requests, we
need to put the URL and the parameters between a pair of single quotes; otherwise, the
special characters used to separate parameters (such as &) will be interpreted by the shell
program, changing the meaning of the command. The following example shows how to
send an HTTP GET request to our web application, with two parameters (username and
Password)
$ curl
’www.SeedLabSQLInjection.com/index.php?username=alice&Password=111’

Append a new SQL statement

In the above two attacks, we can only steal information from the database; it will be better
if we can modify the database using the same vulnerability in the login page. An idea is to
use the SQL injection attack to turn one SQL statement into two, with the second one being
the update or delete statement. In SQL, semicolon (;) is used to separate two SQL
statements. Please describe how you can use the login page to get the server run two SQL
statements. Try the attack to delete a record from the database, and describe your
observation.

SQL Injection Attack on UPDATE Statement

If a SQL injection vulnerability happens to an UPDATE statement, the damage will be more
severe, because attackers can use the vulnerability to modify databases. In our Employee
Management application, there is an Edit Profile page (Figure 2) that allows employees to
update their profile information, including nickname, email, address, phone number, and
password. To go to this page, employees need to log in first. When employees update their
information through the Edit Profile page, the following SQL UPDATE query will be
executed. The PHP code implemented in unsafe edit backend.php file is used to update
employee’s profile information. The PHP file is located in the /var/www/SQLInjection
directory.
$hashed_pwd = sha1($input_pwd);
$sql = "UPDATE credential SET
nickname=’$input_nickname’,
email=’$input_email’,
address=’$input_address’,
Password=’$hashed_pwd’,
PhoneNumber=’$input_phonenumber’
WHERE ID=$id;";
$conn->query($sql);

Modify your own salary

As shown in the Edit Profile page, employees can only update their nicknames, emails,
addresses, phone numbers, and passwords; they are not authorized to change their
salaries. Assume that you (Alice) are a disgruntled employee, and your boss Boby did not
increase your salary this year. You want to increase your own salary by exploiting the SQL
injection vulnerability in the Edit-Profile page. Please demonstrate how you can achieve
that. We assume that you do know that salaries are stored in a column called ’salary’.

Modify other people’ password

After changing Boby’s salary, we are still disgruntled, so we want to change Boby’s
password to something that we know, and then we can log into his account and do further
damage.one thing worth mentioning here is that the database stores the hash value of
passwords instead of the plaintext password string. You can again look at the unsafe edit
backend.php code to see how password is being stored. It uses SHA1 hash function to
generate the hash value of password.
To make sure our injection string does not contain any syntax error, we can test our
injection string on MySQL console before launching the real attack on our web application.

Countermeasure — Prepared Statement

The fundamental problem of the SQL injection vulnerability is the failure to separate code
from data. When constructing a SQL statement, the program (e.g. PHP program) knows
which part is data and which part is code. Unfortunately, when the SQL statement is sent to
the database, the boundary has disappeared; the boundaries that the SQL interpreter sees
may be different from the original boundaries that was set by the developers. To solve this
problem, it is important to ensure that the view of the boundaries are consistent in the
server-side code and in the database. The most secure way is to use prepared statement.
To understand how prepared statement prevents SQL injection, we need to understand
what happens when SQL server receives a query. The high-level workflow of how queries
are executed is shown in Figure . In the compilation step, queries first go through the
parsing and normalization phase, where a query is checked against the syntax and
semantics. The next phase is the compilation phase where keywords (e.g. SELECT, FROM,
UPDATE, etc.) are converted into a format understandable to machines. Basically, in this
phase, query is interpreted. In the query optimization phase, the number of different plans
are considered to execute the query, out of which the best optimized plan is chosen. The
chosen plan is store in the cache, so whenever the next query comes in, it will be checked
against the content in the cache; if it’s already present in the cache, the parsing,
compilation and query optimization phases will be skipped. The compiled query is then
passed to the execution phase where it is actually executed.
Prepared statement comes into the picture after the compilation but before the execution
step. A prepared statement will go through the compilation step, and be turned into a pre-
compiled query with empty placeholders for data. To run this pre-compiled query, data
need to be provided, but these data will not go through the compilation step; instead, they
are plugged directly into the pre-compiled query, and are sent to the execution engine.
Therefore, even if there is SQL code inside the data, without going through the compilation
step, the code will be simply treated as part of data, without any special meaning. This is
how prepared statement prevents SQL injection attacks.
Here is an example of how to write a prepared statement in PHP. We use a SELECT
statment in the following example. We show how to use prepared statement to rewrite the
code that is vulnerable to SQL injection attacks.
$sql = "SELECT name, local, gender
FROM USER_TABLE
WHERE id = $id AND password =’$pwd’ ";
$result = $conn->query($sql))
The above code is vulnerable to SQL injection attacks. It can be rewritten to the following
$stmt = $conn->prepare("SELECT name, local, gender
FROM USER_TABLE
WHERE id = ? and password = ? ");
// Bind parameters to the query
$stmt->bind_param("is", $id, $pwd);
$stmt->execute();
$stmt->bind_result($bind_name, $bind_local, $bind_gender);
$stmt->fetch();
Using the prepared statement mechanism, we divide the process of sending a SQL
statement to the database into two steps. The first step is to only send the code part, i.e., a
SQL statement without the actual the data. This is the prepare step. As we can see from the
above code snippet, the actual data are replaced by question marks (?). After this step, we
then send the data to the database using bind param(). The database will treat everything
sent in this step only as data, not as code anymore. It binds the data to the corresponding
question marks of the prepared statement. In the bind param() method, the first argument
"is" indicates the types of the parameters: "i" means that the data in $id has the integer
type, and "s" means that the data in $pwd has the string type.