Without proper safeguards,
applications are vulnerable to various forms of security attack. One
particularly pathetic method of attack
is called SQL injection. Using this method, a hacker can pass string input to
an application with the hope of gaining unauthorized access to a database.
SQL injection is a technique to
maliciously exploit applications that use client-supplied data in SQL
statements. Attackers trick the SQL engine into executing unintended commands
by supplying specially crafted string input, thereby gaining unauthorized
access to a database in order to view or manipulate restricted data.
SQL injection techniques may
differ, but they all exploit a single vulnerability in the application.
The following things might
result from SQL injection:
- The user could log in to the application as another user, even as an administrator.
- The user could view private information belonging to other users e.g. details of other users’ profiles, their transaction details etc.
- The user could change application configuration information and the data of the other users.
- The user could modify the structure of the database; even delete tables in the application database.
- The user could take control of the database server and execute commands on it at will.
Since, the SQL Injection
consequences is severe, The SQL Injection testing must be done during the
security testing of an application.
The
SQL injection problem should be tested only in the test environment.
If the application has a log in
page, it is possible that the application uses a dynamic SQL statement s
in the Inputbox or any text box that gives an input to the
application to access the Database user details etc .
If
the tester would enter John as the UserName (in the textbox for user name) and
Smith as strPassword (in the textbox for password), the SQL statement would
become:
SELECT *
FROM Users WHERE User_Name = ‘John’ AND Password = ‘Smith’;
If
the tester would enter John’– as UserName
and ‘smith’ as Password, the SQL statement would become:
SELECT *
FROM Users WHERE User_Name = ‘John’– AND Password = ‘Smith’;
Note
that the part of the SQL statement after John is turned into a comment. If
there were any user with the user name of John in the Users table, the
application could allow the tester to log in as the user John. The tester could
now view the private information of the user John.
Q)What if
the tester does not know the name of any existing user of the application?
In
such a case, the tester could try common user names like admin, administrator
and sysadmin. If none of these users exist in the database, the tester could
enter John’
or ‘x’=’x as UserName and Smith’ or
‘x’=’x as Password. This
would cause the SQL statement to become like the one below.
SELECT *
FROM Users WHERE User_Name = ‘John’ or ‘x’='x’ AND Password = ‘Smith’ or
‘x’=’x’;
Since
‘x’=’x’ condition is always true, the result set would consist of all the rows
in the Users table. The application could allow the tester to log in as the
first user in the Users table.
If
the tester would enter John’; DROP table users_details;’—as
strUserName and anything as strPassword, the SQL statement would become like
the one below.
SELECT *
FROM Users WHERE User_Name = ‘John’; DROP table users_details;’ –‘ AND Password
= ‘Smith’;
This
statement could cause the table “users_details” to be permanently deleted from
the database.
Though the above examples deal
with using the SQL injection technique only the log in page, the tester should
test this technique on all the pages of the application that accept user input
in textual format e.g. search pages, feedback pages etc.
Some of the other login bypassing
queries are:-
- admin' --
- admin' #
- admin'/*
- ' or 1=1--
- ' or 1=1#
- ' or 1=1/*
- ') or '1'='1--
- ') or ('1'='1--
