Testing SQL Injection Attacks
Many applications use some type of a database. An application under test might
have a user interface that accepts user input that is used to perform the
Show the relevant stored data to the user e.g.
the application checks the credentials of the user using the log in information
entered by the user and exposes only the relevant functionality and data to the
Save the data entered by the user to the database
e.g. once the user fills up a form and submits it, the application proceeds to
save the data to the database; this data is then made available to the user in
the same session as well as in subsequent sessions
Some of the user inputs might be used in framing SQL statements that are then
executed by the application on the database. It is possible for an application
NOT to handle the inputs given by the user properly. If this is the case, a
malicious user could provide unexpected inputs to the application that are then
used to frame and execute SQL statements on the database. This is called SQL
injection. The consequences of such an action could be alarming.
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
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 consequences of allowing the SQL injection technique could be severe,
it follows that SQL injection should be tested during the security testing of an
application. Now with an overview of the SQL injection technique, let us
understand a few practical examples of SQL injection.
Important: The SQL injection problem should be tested only in the test
If the application has a log in page, it is possible that the application uses a
dynamic SQL such as statement below. This statement is expected to return at
least a single row with the user details from the Users table as the result set
when there is a row with the user name and password entered in the SQL
SELECT * FROM Users WHERE User_Name = ‘” & strUserName & “‘ AND Password = ‘” &
strPassword & “’;”
If the tester would enter John as the strUserName (in the textbox for user name)
and Smith as strPassword (in the textbox for password), the above SQL statement
SELECT * FROM Users WHERE User_Name = ‘John’ AND Password = ‘Smith’;
If the tester would enter John’– as strUserName and no strPassword, 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.
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 strUserName and Smith’ or ‘x’=’x as
strPassword. 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’
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.
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
SQL injection might be possible in applications that use SSL. Even a firewall
might not be able to protect the application against the SQL injection
I have tried to explain the SQL injection technique in a simple form. I would
like to re-iterate that SQL injection should be tested only in a test
environment and not in the development environment, production environment or
any other environment. Instead of manually testing whether the application is
vulnerable to SQL injection or not, one could use a web vulnerability scanner
that checks for SQL injection.