SQL INJECTION

            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--