Database Security. Database Auditing. Database Caching. Database Masking. Get it nowDisabling Literals
Posted March 29th, 2008 by Thomas
in
Hi,
What about filtering literals of any kind? That would prevent 99% of all SQL injections. Developers would be forced to use prepared statements / parameterized queries. See also:
http://en.wikipedia.org/wiki/SQL_injection#Enforcing_the_Use_of_Parameterized_Statements
http://www.h2database.com/html/advanced.html#sql_injection
Regards,
Thomas
G
Comments
literals filtering
Hi Thomas
I think it is a good aproach but it does not eliminate full the risk of SQL injections.
Another big disadvantage is that it requires to rewrite all applications.
The point of GreenSQL that it work transparently. It provides you with
a good level of database security.
BTW. I have looked at the H2 project. It looks very impressive.
I think it can be still exploited if one can add the following string to SQL query:
or ZERO() = ZERO()It will create an SQL tautology.
literals filtering
> it can be still exploited if one can add the following string to SQL query:
> or ZERO() = ZERO()
No, this is not possible, because the attacker can not disguise the condition as data. Your attack is a 'traditional' SQL injection attack and requires that the application does something like this:
sql1 = "SELECT * FROM LOGIN WHERE PASSWORD='" + password + "'";
When literals are not allowed in SQL statements, this query would be rejected at runtime (by the database for H2, or by GreenSQL if used as a wrapper/filter API). It would be rejected no matter what the password is. The only statement that is allowed is:
sql2 = "SELECT * FROM LOGIN WHERE PASSWORD=?";
And in this case it is not possible to add 'OR ZERO()=ZERO()' to the SQL statement.
> disadvantage is that it requires to rewrite all applications.
Only that part needs to be changed where data is combined with SQL statements (as above). A complete rewrite wouldn't be required. Also, it is possible to disallow text data in SQL statements only, or disallow text and numbers in SQL statements.
> The point of GreenSQL that it work transparently.
Yes. It is possible to add the 'disable literals' feature to GreenSQL as an option. In fact, it would be quite easy to implement. Allowed statements could be white-listed, that means reviewed parts of the application could be allowed.
> it does not eliminate full the risk of SQL injections.
Yes, for example it is not possible to completely eliminate the risk for the following case:
sql = "SELECT * FROM USERS ORDER BY " + sortColumn;
if the sortColumn is a parameter in the web application. This kind of 'order by injection' however is more complex and less common.