SQL Injection is a common type of web database related vulnerability. SQL injection is common to web site applications that interact with a database backend. These sites construct SQL commands or queries based on user input. For example they might search a product database based on a description a user typed in a web form. An application is vulnerable to SQL injection when it builds SQL queries without filtering the user's input, without using store procedure, or without binding parameters variables. This can lead to an attacker adding additional clauses, conditions, or even commands that execute along the original query. Attackers can use SQL Injection bugs to execute different types of attacks such as data theft and tampering, authentication bypass, information disclosure, and elevation of privileges.
Below is a summary of steps needed for testing for SQL injection bugs
- Step 1: Understand SQL injection attack scenarios
- Step 2: List high risk components and entry points
- Step 3: Start testing and exploring
- Step 4: Tune of test data
Step 3: Start Testing and Exploring
The following step is to start supplying input to the application that gives hints of possible SQL injection bugs. With the list made during step 2, you can systematically walk through all variables and start exploring how the test input is handled. In this step, we recommend to execute a first pass using fuzz strings and basic conditions.
Start with a simple fuzz string
The first recommended test is to add some string and a single quote or parenthesis at the end of it. In most SQL Injection cases this kind of string will generate a server side error that will be displayed back in the client's browser:
xyz') "]
Then see how the server reacts to it. In some cases it will strip out the special characters: this is a sign that it protects against injection. However, in other cases the application may return a SQL related error messages because a special character such as the single quote unexpectedly closed a statement. It then can be deduced that the statement was being built dynamically. This is a clear indication that you need to keep looking to see whether a SQL injection bug actually exists.
Continue with simple true and false conditions
The next step is to try to add a simple SQL statement. The simplest you can try is an integer comparison such as 1=1 or 2>1 or a character comparison such as 'a'='a' proceeded by an OR. For instance:
xyz' OR 1=1 --
Then observe the results. Look for any indication that the o injected true statement returned all rows of a table. Then try a false statement and look at the difference.
xyz' OR 1>2 --
If the results are visibly different in quantity or in server behavior, then the possibility for a SQL injection bugs is high. Even if no information about the database structure or no other serious attack is possible, you can determine SQL injection by observing basic server and error messages.
Consider the following scenario. The string "xyz' OR 1=1" -is submitted and the server returns a 500 error that says:
"Results Buffer too Large" and when "xyz' OR 1>2 -"
is submitted the server returns a valid page saying that there were no matches. So when the condition is true the server chokes with results. When it's false it returns no results. In this case, the processing of the injected condition is evident and means that there is a SQL injection bug. It might not be exploitable but it exists and this simple difference in server behavior is enough to prove that it does.
NOTE: Be careful with valid numerical results
Make sure that when using numerical comparisons the results are different because of the comparison and not because of the content. For example, if when using 1=1 the server returns phone numbers with "11" and when 1>2 returns "21" numbers or matches then it means that is not processing the actual comparison. The results are different because the application is querying over the numbers 1 and 2. The server is not executing the extra conditions as separate statements; it is correctly including them as part of the data to search, and there is no evidence of a SQL injection vulnerability. You need to be careful about this scenario and realize when the extra condition is actually being executed separately or not.
