CSE643 SQL Injection Lab Megha Jakhotia

Task 1: Get Familiar with SQL Statements

We first login into the MySQL console and switch the database in use to Users:

On listing all the tables, we see that we have a single table named credential:

Printing all the information of the employee ‘Alice’:

Task 2: SQL Injection Attack on SELECT Statement

Task 2.1: SQL Injection Attack from webpage

Entering the username as admin’ # and password as admin:

On clicking on login, we get the following output:

The input here for username results in the following query at the server to be executed:

SELECT id, name, eid, salary, birth, ssn, address, email, nickname, Password
FROM credential
WHERE name= ‘admin’
CSE643 SQL Injection Lab Megha Jakhotia

The password entered here was just for the sake of completion because JavaScript can be used
to check if the field has been filled and in case it is not, it might request for it by causing an alert
or error and hence not launch a successful SQL Injection.

The # sign makes everything after ‘admin’ to be commented out, here the password. Hence, we
were able to get all the information about the employees using the admin ID.

Task 2.2: SQL Injection Attack from command line.

We use the following curl command to place an HTTP request to the website and perform the
login again in the same manner as before and we see that we get the HTML page in the return:
CSE643 SQL Injection Lab Megha Jakhotia

We see that all the employee’s details are returned in an HTML tabular format. Hence, we were
able to perform the same attack as in Task 2.1. The CLI commands can help in automating the
attack, where Web UI don’t. One major change from the web UI was to encode the special
characters in the HTTP request in the curl command. We use the following: Space - %20; Hash
( - %23 and Single Quote (‘) - %27.

Task 2.3: Append a new SQL statement

In order to append a new SQL statement, we enter the following in the username field:
admin'; UPDATE credential SET Name = 'Megha' WHERE Name = 'Alice'; #

The ; separates the two SQL statement at the web server. Here, we try to update the name of the
entry with Name value as Alice to Name value as Megha. On clicking login, we see that an
error is caused while running the query and our attempt to run a second SQL command is
unsuccessful.

Now, we try something similar in order to delete a record from the database table. We enter:
admin'; DELETE FROM credential WHERE Name = 'Alice'; #
CSE643 SQL Injection Lab Megha Jakhotia

We see a similar error with the query changed to the one entered in username.

This SQL injection does not work against MySQL because in PHP’s mysqli extension the
mysqli::query() API does not allow multiple queries to run in the database server. The issue here
is with the extension and not the MySQL server itself; because the server does allow multiple
SQL commands in a single string. This limitation in MySQLi extension can be overcome by
using mysqli -> multiquery(). But for security purposes, we should never use this API and avoid
having multiple commands to be run using the SQL injection.

Task 3: SQL Injection Attack on UPDATE Statement

Task 3.1: Modify your own salary

In order to modify Alice’s salary, we can log into Alice’s account and edit the profile. We enter
the following information in the form:

123’, salary = 80000 WHERE name = ‘Alice’ #

On saving the changes, we can see the profile as:

This shows that we have successfully changed the salary for Alice from 20000 to 80000. This is
possible because the query on the web server becomes:

UPDATE credential SET

Task 3.2: Modify other people’ salary

We see that Boby’s profile before any changes. Now, we try to change Boby’s salary from
Alice’s account using the following string in the Phone number section:
123', salary = 1 WHERE name = 'Boby' #

On saving the changes, we log in into Boby’s profile and check his details now and see that we
have successfully changed his salary. We could enter that string in any of the other fields as
well except password, because it is hashed.
CSE643 SQL Injection Lab Megha Jakhotia

Task 3.3: Modify other people’ password

To modify Boby’s password we do something similar to the previous approach and enter
the following in Alice’s profile field ‘Phone number’ by editing it:
', Password = sha1('Hacked') WHERE name= 'Boby' #

On saving the changes, we log out of Alice’s account and try to sign in into Boby’s account:

Just for demonstration, I’ve used the previously provided password to show that it no more
works, however Alice won’t have this information and hence cannot conduct this step:

Now on logging in with the new password, we see that we are able to successfully log in with
the new password. By using the sha1 function in our input, we are basically performing the same
steps as being performed in the program. This shows that we were successful in performing our
SQL injection attack to change password:
CSE643 SQL Injection Lab Megha Jakhotia

Task 4: Countermeasure — Prepared Statement

Now, in order to fix this vulnerability, we create prepared statements of the previously
exploited SQL statements. The SQL statement used in task 2 in the unsafe_home.php file is
rewritten as the following:

Retrying the attack in task 2.1:

We see that we are no more successful and are no more able to access the admin account. The
error indicates that there was no user with credentials username admin’ # and password admin.

Now, the SQL statement used in task 3 in the unsafe_edit_backend.php file is rewritten as the
following:

On retrying the same as in Task 3.1 and saving the changes, we see that the salary does not
change and hence we are unsuccessful in performing SQL injection with prepared statements:
CSE643 SQL Injection Lab Megha Jakhotia

A prepared statement goes through the compilation step and turns into a pre-compiled query
with empty placeholders for data. To run this pre-compiled query, we need to provide data to it,
but this data will no more go through the compilation step; instead, it will get plugged directly
into the pre-compiled query, and will be 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.