SQL injection is one of the most common web vulnerabilities exploited. This method allows an attacker to read or modify crucial information in a web application database. The severity of damage from SQL injections can range from information disclosure (such as user information, passwords, CC info, etc) to complete system compromise and code execution.

A few previously vulnerable open source applications:
PHPNuke, MyBB, Mambo CMS, ZenCart, osCommerce

While this attack applies to any database, some databases are preferred by attackers because they yield more useful information or allow for greater control once exploited. For example, MS SQL has the “extended stored procedure call” feature which allows any system level command to be executed via the MS SQL server. This is obviously very powerful but can also be very dangerous.
Also, error messages displayed by the MS SQL server tend to reveal more information than a comparable MySQL server. There are steps which can be taken to limit the useful error information MS SQL divulges to would-be attackers and these precautions should be taken by anyone using MS SQL in a production environment.

SQL injections basically work because programmers are either not security minded or too lazy to implement certain safeguards. When an application creates SQL queries based on direct user input that has not been “sanitized”, there is the possibility of an SQL injection.
Here is an example of some vulnerable code in which the user-supplied input is directly used in a SQL query:


<form action="sql.php" method="POST" />
<p>Name:
<input type="text" name="name" /><br />
<input type="submit" value="Add Comment" />
</p> </form>

<?php
$query = "SELECT * FROM users WHERE username = '{$_POST['username']}"; $result = mysql_query($query);
?>


The script will work normally when the username doesn’t contain any malicious characters. In other words, when submitting a non-malicious username (robert) the query becomes:


$query = "SELECT * FROM users WHERE username = 'robert'";


However, a malicious SQL injection query will result in the following attempt:


$query = "SELECT * FROM users WHERE username = '' or '1=1'";


As the “or” condition (1=1) is always true, the mysql_query function returns all records from the database.

Similarly, AND conditions (which would be crafted to intentionally fail) can yield error messages which may reveal table, database or column names, software versions, etc.
It is obvious that these error messages help an attacker to get a hold of the information which they are looking for, making their attack possible. Displaying customized error messages will limit the useful information an attacker can learn from this type of probing. However, this is not the be-all end-all solution as some “blind” SQL injection attacks can still succeed without this useful information.

SQL Injection Countermeasures:

1. Never connect to the database in your application as the database owner or superuser. Always use specifically created database users with the minimum required privileges required to perform the assigned task.

2. Turn on the PHP “magic_quotes_gpc” function. This will escape all POST, GET, COOKIE data automatically.

3. Utilize the PHP function “mysql_real_escape_string” (PHP >= 4.3.0). MySQL_real_escape_string prepends backslashes to the following characters: \x00, \n, \r, \, ‘, “and \x1a.

4. Update all open-source web applications to their latest versions. This will stop many “script kiddies” looking to exploit random sites using known exploits.