SQL Injection

SQL injection is a technique often used to attack data driven applications. This is done by including portions of SQL statements in an entry field in an attempt to get the website to pass a newly formed SQL command to the database. SQL injection is a code injection technique that exploits a security vulnerability in an application’s software. The vulnerability happens when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed.

As per Wikipedia, different class of SQL Injection attack (SQLIA) are as follows:

• Classic SQLIA
• Inference SQL injection
• Interacting with SQL injection
• Database management system-specific SQLIA
• Compounded SQLIA
• SQL injection + insufficient authentication
• SQL injection + DDoS attacks
• SQL injection + DNS hijacking
• SQL injection + XSS

SQL Injection types are as follows:

Incorrectly filtered escape characters

This form of SQL injection occurs when user input is not filtered for escape characters and is then passed into a SQL statement. These results in the potential manipulation of the statements performed on the database by the end-user of the application.

Following example explains this vulnerability:

statement = "SELECT * FROM users WHERE name = '" + userName + "';"

This SQL code gets details of specified username from users table. A hacker or malicious user can modify the userName variable to execute some unintended SQL queries.  For example setting the user name variable as

' or '1'='1

or

' or '1'='1' -- '

On using above in userName field, it will render following SQL queries:

SELECT * FROM users WHERE name = '' OR '1'='1';
SELECT * FROM users WHERE name= '' OR '1'='1' -- ';

This example could be used to force the selection of a valid username because the evaluation of ‘1’=’1′ is always true.

Consider another example:

Following value in userName field will cause deletion of users table as well as select data from users for all users.

 

Incorrect type handling 

This form of SQL injection occurs when a user-supplied field is not strongly typed or is not checked for type constraints. This could take place when a numeric field is to be used in a SQL statement, but the programmer makes no checks to validate that the user supplied input is numeric.

e.g. statement := "SELECT * FROM userinfo WHERE id = " + a_variable + ";"

It is clear from this statement that the author intended a_variable to be a number correlating to the “id” field. However, if it is in fact a string then the end-user may manipulate the statement as they choose, thereby bypassing the need for escape characters. For example, setting a_variable to

1;DROP TABLE users

will drop (delete) the “users” table from the database, since the SQL would be rendered as follows:

SELECT * FROM userinfo WHERE id=1;DROP TABLE users;

 

Blind SQL injection

Blind SQL Injection is used when a web application is vulnerable to an SQL injection but the results of the injection are not visible to the attacker. The page with the vulnerability may not be one that displays data but will display differently depending on the results of a logical statement injected into the legitimate SQL statement called for that page

One type of blind SQL injection forces the database to evaluate a logical statement on an ordinary application screen.

For example if a website uses query string to determine the user data to display like

http://users.test.com/showuserdetails.axpx?ID=1001

This may run following query in the server

SELECT * FROM users WHERE ID = '1001';

A hacker can load following urls

http://users.test.com/showuserdetails.axpx?ID=1001  AND 1=1 and

http://users.test.com/showuserdetails.axpx?ID=1001  AND 1=2

these may result in following queries

SELECT * FROM bookreviews WHERE ID = '5' AND '1'='1';

SELECT * FROM bookreviews WHERE ID = '5' AND '1'='2';

A hacker may make similar changes to get more and more information.

 

Manual SQL Injection testing checklist

1. Test the size and data type of input and make sure appropriate limits is enforced. This can help prevent deliberate buffer overruns.
2. Test the content of string variables and make sure only expected values are accepted.Binary data, escape sequences, and comment characters should be rejected. This can help prevent script injection and can protect against some buffer overrun exploits.
3. When testing XML documents, validate that all data against its schema as it is entered.
4. Test that Transact-SQL statements are never directly built from user input.
5. Make sure following input characters are rejected wherever possible

Input character	Meaning in Transact-SQL
;	Query delimiter.
‘	Character data string delimiter.
—	Comment delimiter.
/* … */	Comment delimiters. Text between /* and */ is not evaluated by the server.
xp_	Used at the start of the name of catalog-extended stored procedures, such as xp_cmdshell.