There
are several ways a hacker can target a database, and SQL Injection is
becoming one of the common way. It is used on websites which have been
designed very poorly and which did not anticipate the possibility of
such risks during the design phase. It involves inserting SQL statements
on one of the input boxes of a web form which executes certain commands
on the backend.
SQL injection testing is a technique that can check if a site’s input fields/web form has vulnerabilities that could be used to obtain information.
SQL injection is done in many ways. Data could be extracted on the same channel which was used to inject the SQL code. In this case the extracted data will be presented on the application web page itself. Data could also be extracted by a different channel wherein an email with the results of the query is generated and sent to the tester. A tester could also make inferences regarding the server by sending particular requests to it and observing the resulting behavior.
Manual SQL Injection testing tends to be tedious and quite time consuming. It can only detect the simple vulnerabilities.
Other possibility is using an automated web application vulnerability scanner, such as HP's WebInspect, IBM's AppScan or Cenzic's Hailstorm. These tools all offer easy, automated ways to analyze your web applications for potential SQL Injection vulnerabilities.
Blackbox testing:
First you need to know when the application under consideration connects to a DB Server to access data. Typically, an application needs to talk to a DB in the following cases:
1. Authentication forms: when authentication is done using a web form, most often the user credentials will be checked against a database that contains all usernames and passwords or password hashes
2. Search engines: when a string is submitted by the user, it could be used in a SQL query that would then extract all relevant records from a database.
3. E-Commerce sites: the products and their characteristics (price, description and availability) are very likely to be stored in a relational database.
As owasp.org states, the tester has to make a list of all input fields whose values could be used in making an SQL query and then test them separately. The very first test usually consists of adding a single quote (') or a semicolon (;) to the field which is being tested. The first is used in SQL as a string terminator and would lead to an incorrect query if it is left unfiltered by the application. The second is used to end a SQL statement and, if it is not filtered, it is too would generate an error. The output of a vulnerable field might look like the following (on a Microsoft SQL Server, in this case):
Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]Unclosed quotation mark before the
character string ''.
/target/target.asp, line 113
Other SQL keywords such as 'AND' and 'OR' could be used to try to modify the query. A very simple but sometimes still effective technique is simply to insert a string where a number is expected, as an error like the following could be generated:
Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the
varchar value 'test' to a column of data type int.
/target/target.asp, line 113
A full error message provides a wealth of information to the tester in order to mount a successful injection. However, applications often may not delve into detail: a simple '500 Server Error' or a custom error page might be issued, meaning that tester should now turn to blind injection techniques. In any case, it is very important to test each field separately: meaning only one variable must vary while all the others remain constant, in order to identify the vulnerable parameters.
No comments:
Post a Comment