RE: JDBC PreparedStatements, Java Data Objects/O-R mapping, and SQL Injection

I've lost track of how many times I've said this, but I'll say it again!! :-) the issue is one trusting input, if you don't check the input data, and in some instances, the output data is correct and well-formatted, then not amount of 'wizardry' is gonna help... Use prepared statements, but do so after checking the data is well-formed.

Cheers, Michael
Secure Windows Initiative
Writing Secure Code 2nd Edition
http://www.microsoft.com/mspress/books/5957.asp -----Original Message-----
From: Jeff Williams @ Aspect [mailto:jeff.williams@aspectsecurity.com] Sent: Monday, December 30, 2002 7:37 PM
To: Kevin Spett; Dave Aitel; webappsec@securityfocus.com

I think there's a very important point here about specifications and security guarantees.

Not to rehash the whole discussion from the old PreparedStatement thread, but nothing in the JDBC spec precludes SQL injection from working with a PreparedStatement. That means that it depends on how the JDBC driver is implemented and what support is provided in the database for pre-compiling queries. I've checked the source for a few open-source JDBC drivers, and there is definitely room for security improvements. Who knows what's going on under the covers in a proprietary JDBC driver.

Excellent question about OR mapping technologies and what I'll call "OQL injection." For those who don't know, OQL is a subset of SQL used to query objects from an object store that is generally backed by a relational database. I checked the Castor JDO implementation, and it uses a PreparedStatement under the hood, so it appears to be resistant to these attacks (depending on your JDBC driver and database). The translation from OQL to SQL is done with a *very* simple parser based on StringTokenizer. The JDO spec is silent on use of PreparedStatements and SQL injection, so there are no guarantees that your JDO implementation is resistant to OQL injection.

In both of your questions, the specs don't detail the security guarantees -- meaning that if you want security you have to build it yourself. Even if you are currently not susceptible because your code is running with a strong driver/database, you have a latent flaw waiting to bite you.

Bottom line -- if the spec doesn't guarantee it, you should protect your app against it. Using PreparedStatement *may* help, but that protection may disappear when you change platforms a few years out. In my opinion, the right approach here is to very carefully validate parameters yourself before they are used in any kind of JDBC query.

--Jeff

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

Jeff Williams
Aspect Security, Inc.
http://www.aspectsecurity.com

• Original Message ----- From: Kevin Spett To: Dave Aitel ; webappsec@securityfocus.com Sent: Monday, December 30, 2002 6:48 PM Subject: Re: JDBC PreparedStatements, Java Data Objects/O-R mapping, and SQL Injection

Stored procedures by themselves do not provide protection, sorry if I worded that poorly. Prepared statements, *combined* with prepared statements do, which is how I meant that statement to be interpereted. Of course, "impossible" should be taken with a grain of salt.

Kevin Spett
SPI Labs
http://www.spidynamics.com/

• Original Message ----- From: "Dave Aitel" <dave@immunitysec.com> To: <webappsec@securityfocus.com> Sent: Monday, December 30, 2002 6:14 PM Subject: Re: JDBC PreparedStatements, Java Data Objects/O-R mapping, and SQL Injection

> I dunno about that. Impossible is such a big word, and I've seen SQL
SQL
> Injection even more fun than usual!)
http://archives.neohapsis.com/archives/sf/www-mobile/2002-q3/0105.html
> >
> > Have a fun and securely programmed new year, everyone.
> >
> > Kevin Spett
> > SPI Labs
> > http://www.spidynamics.com
> >
> >
> > ----- Original Message -----
> > From: "Christopher Todd" <chris@christophertodd.com>
> > To: <webappsec@securityfocus.com>
> > Sent: Monday, December 30, 2002 3:29 PM
> > Subject: JDBC PreparedStatements, Java Data Objects/O-R mapping, and

> > SQL Injection
> >
> >
> > > I am working on the Java language section of the OWASP Guide to
> > > Securing

> > > elite
JDBC
> > > PreparedStatements? Are any of you aware of a theoretical reason
to
> > > perform SQL injection on an example app I coded up, but then
again,
> > > I am not the
> > world's
it
> > > theoretically impossible to execute SQL injection against apps
coded
> > > using these techniques and tools?
> > >
> > > I ask these questions because I think these two techniques can be
> > > used effectively to thwart (or at least make more difficult) SQL
> > > injection attacks against Java-based web apps, but I want to
> > > validate that belief to the best extent I can prior to putting
such
> > > statements into the Guide. Thanks in advance for any help you can
> > > provide, as it will improve the quality and usefullness of the
> > > Guide.
> > >
> > > Chris
> > >
> > >
> >
> >
>
Received on Tue Dec 31 15:08:49 2002