There are various SQLIA techniques which can be used by an attacker depending on the desired outcome. The different techniques are usually not used in isolation but rather in differing combinations with one another.
Possibly the most common technique is tautology which works by injecting code into a conditional statement so that it always evaluates to true, for example “ ' OR 1=1 --”. This closes the first string and using an 'OR' operator bypasses it's argument allowing the tautology statement (1=1), which will always return true, to override it. The double dash at the end of the injected code will comment out any remaining SQL in the statement. This technique is commonly used to bypass pages requiring authentication in order to extract data (Heydari, et al., 2010).
Vulnerable SQL statement:
SELECT *
FROM users
WHERE username='$username'
AND password='$password';
$username and $password are user submitted
Altered SQL statement:
SELECT *
FROM users
WHERE username='admin'
AND password='' OR '1'='1';
Example adapted from Luong 2010 , p.11
The tautology attack example illustrated above would authenticate the attacker access under the admin account, provided there is an account with user 'admin', on the basis that although the password is unlikely to be blank, '1'='1' will always return true.
Attacks utilising the UNION SQL operator, known as union-query attacks, allow complete control of a secondary SQL query which is combined to the result set of the original. For example an attacker could input “' UNION SELECT <> --” which would close the first string and comment out the rest of the first query and then combine the empty results returned with the result's of the second query, created by the attacker (Balasundaram and Ramaraj, 2011).
Another type of attack attempts to execute stored procedures which come as standard with many database packages. These procedures are capable of interacting with the operating system and once an attacker has discovered the DBMS in use, SQLIA's can be implemented to execute them. Further to these are extended stored procedures, such as 'xp_cmdshell' which allows the execution of arbitrary command lines. For example “'exec master..xp_cmdshell 'dir'” will return a directory listing from the system (Balasundaram and Ramaraj, 2011).
A technique used in conjunction with others in a bid to bypass methods of prevention is the obscuring of the injected string. By using character encoding such as ASCII, hexadecimal, Unicode, etc. or breaking up SQL operators with comment blocks (/**/), scripts designed to search for injection, known as signature based detection, are less likely to succeed. For example the string “' OR 1=1; --” can be encoded using ASCII to become “' OR 1-1; --” or UNION can be replaced with UN/**/ION. String concatenation can also be used for this technique to join together parts of strings to create the malicious code using “+”, “||” or the SQL function “CONCAT”. For example 'UNI' + 'ON A' + 'LL' would become 'UNION ALL' but would not be detected by a script searching user input for the string 'UNION ALL'. (Luong, 2010).
Databases are not only targeted for the data they hold but the operation of the database can also be a target. A common technique used to deny database services is executing a SHUTDOWN command. This will prevent any systems using the database from functioning correctly until the database is manually restarted by the administrator (Balasundaram and Ramaraj, 2011).
The threats posed by SQL injection are obvious with an insecure system vulnerable to unauthorised access, manipulation, data loss, corruption etc. According to a report by information security and forensics company 7Safe, as can be seen in figure 1, SQL Injection accounted for 40% of online attacks in 2010 and contributed to a further 20% as part of a combined attack (2010).
Figure 1: Vulnerability leading to data compromise (7Safe 2010, p.18)
In these cases of data compromise monetary loss is a real threat with payment card information accounting for 85% of data loss in 2010 (7Safe, 2010). In 2009 credit card processor Heartland Payment Systems, along with four other companies were the target of an SQL Injection attack. This sophisticated operation resulted in the loss of data for 130 million credit and debit cards and the biggest identity theft case ever prosecuted in the US (Goodin, 2009). By mid 2010 Heartland Payment Systems had been forced to pay over $100 million in damages to credit card companies Mastercard, Visa and American Express (Leyden, 2010).
Defending against SQL injection should be a high priority when designing an online system. Although it is impossible to implement a 100% secure system without removing all user interaction there are steps that can be followed to minimise vulnerability. Any techniques implemented should be consistently re-evaluated and updated as it is likely only a matter of time until methods to over come them are found (Brown and Ragan, 2010).
SQL injection is made possible when user input is implemented as part of an SQL statement, therefore all user input should be kept to an absolute minimum and user input used should be scrutinised to the fullest extent. Characters used in any input should be limited to only those necessary. For example a name field will not require the hash character, a common SQL comment syntax. Unconventional strings of common characters should also be checked, for example another common SQL comment syntax the double hyphen. In most cases the only non-alphanumeric characters which will be required is a single hyphen, a single apostrophe and the '@' sign. A limitation can also be set on the types of operators allowed in SQL statements. For example if a statement is designed only to read data from a database then allowing only the use of the 'SELECT' operator with in the query would prevent data manipulation or deletion (Razvan, 2009).
There are some automated tools which can help prevent SQLIA such as the open source MySQL firewall GreenSQL, which works by evaluating SQL commands using a scoring matrix and blocking known administrative commands. Another firewall available is Applicure's dotDefender which works at application level using a set of security rules. A tool for use at development level is available from CodeScan Lab and works by scanning source code and generating a report highlighting vulnerabilities (Luong, 2010).
References:
7Safe. 2010. UK security breach investigations report: An analysis of data compromise cases. [online] Available from: http://7safe.com/breach_report/Breach_report_2010.pdf
Balasundaram, I. And Ramaraj, E. 2011. An approach to detect and prevent sql injection attacks in database using web service. International Journal of Computer Science and Network Security. 11(1), pp. 197-205. [online]. Available From:http://paper.ijcsns.org/07_book/201101/20110130.pdf
Brown, F. and Ragan, R. 2010. INFOSEC world conference 2010: Google and beyond. [online]. Available from: http://www.stachliu.com/slides/googleandbeyond.pdf
Goodin, D. 2009. The Register: TJX suspect indicted in Heartland, Hannaford breaches. [online] Available from: http://www.theregister.co.uk/2009/08/17/heartland_payment_suspect/
Heydari, M. Z., Massrum, M and Tajpour, A. 2010. 2nd International conforence on education technology and computer: Comparison of SQL injection detection and prevention techniques. [online] Available from: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5529788
Leyden, J. 2010. The Register: Heartland coughs $41m to settle MasterCard claims. [online] Available from: http://www.theregister.co.uk/2010/05/20/heartland_mastercard_settlement/
Luong, V. 2010. Intrusion detection and prevention system: SQL-Injection attacks. [online] Available from: http://www.cs.sjsu.edu/faculty/stamp/students/luong_varian.pdf
Razvan, R. 2009. Proceedings of the 3rd international conference on communications and information technology: Over the SQL injection hacking method. [online] Available from: http://www.wseas.us/e-library/conferences/2009/vouliagmeni2/CIT/CIT-19.pdf
