Prepared Statements and SQL injections

Published: 2007-02-24
Last Updated: 2007-02-26 15:23:27 UTC
by Jason Lam (Version: 1)
0 comment(s)
In the previous few days, I had numerous discussion with different people about the use of prepared statements to mitigate SQL injection vulnerabilities. Prepared statements definitely works well as part of the mitigation strategy for SQL injection if implemented properly. I still remember 4-5 years ago when SQL injection just started to become popular, the common mitigation suggested is to use prepared statement as if it is a magic bullet. As we understand the SQL injection problem better, we realize that even prepared statement can be vulnerable to SQL injection as well.

The fundamental problem in SQL injection is concatenation of untrusted data (raw user input) to trusted data and the whole strings is being sent to the backend database for execution. The moment you merge the raw untrusted data to other trusted data for execution, you got a problem.

Look at this prepared statement (Java)

PreparedStatement Stment = con.prepareStatement("SELECT * FROM table WHERE cond = ' + UserInput + ' ");

The UserInput which is raw input from the user is concatenated with the other string to form SQL statement then it is "prepared" for execution in the database. What's wrong here?  Untrusted data is concatenated with static strings and sent to database to execution, no validation whatsoever.... BOOM... SQL injection for ya.

Let's look at another version of this statement

Stment = "SELECT * FROM table WHERE cond = ? ";
PreparedStatement prepSQL = con.prepareStatement(Stment);
prepSQL.setString (1, UserInput);
ResultSet rs = prepSQL.executeQuery();


See the question mark in the first line? That's the character to tell prepared statement mechanism that there are more data coming into this space. Think "fill in the blanks" exercise here, question mark is an empty spot for filling, the setString function just fill a string into that spot. When statement is prepared, validation is performed on the user input, in the case of Java, the JDBC driver escapes the user input properly. Untrusted user input go through validation and become validated input. This type of passing user input to the statement as a parameter is sometimes referred to as parameterized queries.

One risk still remains here.... The implementation of the database driver (or data access mechanism) has to accurately escape the potentially offensive user input. So far, the track record of such mechanism across multiple languages are pretty good.

Extra note here about stored procedures which was regarded as another potential mitigations for SQL injection as well; Both prepared statement and stored procedures can be vulnerable to SQL injection if it is not done properly. Similar to prepared statement, stored procedure can be done in parameterized form to mitigate SQL injection.

Shameless plug - To get more info on web related security issues, SANS offers SEC 519 course on web application security.
Keywords: SQL Injection
0 comment(s)

SupportSoft Active X fixed

Published: 2007-02-24
Last Updated: 2007-02-25 16:49:25 UTC
by Swa Frantzen (Version: 4)
0 comment(s)
SupportSoft's ActiveX control that allows a.o. remote assistance has been updated fixing a security issue leading to remote code execution.
Security products affected:
But do note there are many more sources for these controls to sneak in through.

Therefore we highly recommend to future proof it by using the workarounds to prevent it from being used even if something would reinstall it at some point in the future.

Consider disabling ActiveX for all but windowsupdate and/or this list of killbits:
    {01010200-5e80-11d8-9e86-0007e96c65ae}
    {01010e00-5e80-11d8-9e86-0007e96c65ae}
    {01011300-5e80-11d8-9e86-0007e96c65ae}
    {01013A00-5E80-11D8-9E86-0007E96C65AE}
    {01013B00-5E80-11D8-9E86-0007E96C65AE}
    {01013C00-5E80-11D8-9E86-0007E96C65AE}
    {01013D00-5E80-11D8-9E86-0007E96C65AE}
    {01013F00-5E80-11D8-9E86-0007E96C65AE}
    {01014000-5E80-11D8-9E86-0007E96C65AE}
    {01014100-5E80-11D8-9E86-0007E96C65AE}
    {01014B00-5E80-11D8-9E86-0007E96C65AE}
    {01111c00-3e00-11d2-8470-0060089874ed}
    {01111e00-3e00-11d2-8470-0060089874ed}
    {01111f00-3e00-11d2-8470-0060089874ed}
    {01112500-3e00-11d2-8470-0060089874ed}
    {01112800-3e00-11d2-8470-0060089874ed}
    {01113300-3e00-11d2-8470-0060089874ed}
    {01114200-3e00-11d2-8470-0060089874ed}
    {01114300-3e00-11d2-8470-0060089874ed}
    {01114400-3e00-11d2-8470-0060089874ed}
    {01114500-3e00-11d2-8470-0060089874ed}
    {01114600-3e00-11d2-8470-0060089874ed}
    {01114700-3e00-11d2-8470-0060089874ed}
    {01114800-3e00-11d2-8470-0060089874ed}
    {01116e00-3e00-11d2-8470-0060089874ed}
A .reg file for setting these killbits can be downloaded, use at your own risk.

--
Swa Frantzen -- NET2S
Keywords:
0 comment(s)

Kernel malware paper from F-Secure

Published: 2007-02-24
Last Updated: 2007-02-24 17:57:23 UTC
by Jason Lam (Version: 1)
0 comment(s)
Kimmo Kasslin from F-Secure has released a paper on Kernel malware. In the paper, a brief overview of kernel malware is provided followed by detailed analysis of the kernel malware and case studies. If you ever wonder how kernel rootkit and other kernel level malware works, this is a good paper to read.

Follow this link to the paper. Together with the paper, Kimmo's slides for AVAR 2006 conference talk on the same topic is also released.
Keywords:
0 comment(s)

Comments


Diary Archives