Re: [WEB SECURITY] Known Safe JDBC Drivers

[planetlevel <planetlevel@xxxxxxxxx>]

--0016e6d644f5ccae0f047937832e
Content-Type: text/plain; charset=UTF-8

This isn't true. ESAPI absolutely does recommend that people use
PreparedStatement as the first and best option (it's all over the javadoc
and the swingset sample app).

However, ESAPI does provide database codecs because there are many
situations when remediation is more easily done with an escaping method.
There are also certain types of queries for which using PreparedStatement
will cause significant performance problems (so be careful with those
recommendations folks). Also, in some environments parameterized queries may
not be available, so an escaping option is important.

I looked into this pretty deeply back in 2002/2003 (
http://lists.virus.org/webappsec-0301/msg00003.html). The upshot is that the
JDBC spec doesn't explicitly require that PreparedStatement prevents
injection, so there's certainly some risk in relying exclusively on
them. That's why input validation, escaping, and access reference maps are
important security controls. And of course there are degenerate cases like
PreparedStatement.executeQuery( "exec ?" );

I looked into the MySQL driver back then and decided that it wasn't
obviously vulnerable.  I even took a swing at reversing the Oracle JDBC
drivers, but I didn't get far enough to give anyone any confidence.  This is
exactly the lack of visibility that makes it so difficult to make progress
in application security.

--Jeff

On Wed, Nov 25, 2009 at 11:32 AM, Rohit Sethi <rklists@gmail.com> wrote:

> Common advice in the Java world is to use properly bound variables in
> PreparedStatements to protect against SQL Injection. Many people have
> talked about the fact that the protection provided by
> PreparedStatements is really dependent on how the JDBC drivers are
> coded.
>
> ESAPI takes the approach to not rely on JDBC drivers and instead
> provides its own encoding codecs for MySQL and Oracle. For other
> databases,however, many people rely on the JDBC drivers.
>
> My question is: does anyone know of a study, list or project that
> discusses which JDBC drivers are known to protect against SQL
> Injection (in properly bound variables in prepared statements)?
> Essentially I'm looking for a whitelist of JDBC drivers that, if used
> properly, a developer can feel confident that they're not vulnerable
> to SQL Injection.
>
> Thanks,
>
> --
> Rohit Sethi
> Security Compass
> http://www.securitycompass.com
>
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
>


-- 

--pl

--0016e6d644f5ccae0f047937832e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>This isn&#39;t true. ESAPI absolutely does recommend that people use P=
reparedStatement as the first and best option (it&#39;s all over the javado=
c and the swingset sample app).</div>
<div>=C2=A0</div>
<div>However, ESAPI does provide database codecs because there are many sit=
uations when remediation is more easily done with an escaping method. There=
 are also certain types of queries for which using PreparedStatement will c=
ause significant performance problems (so be careful with those recommendat=
ions folks). Also, in some environments parameterized queries may not be av=
ailable, so an escaping option is important.</div>

<div>=C2=A0</div>
<div>I looked into this pretty deeply back in 2002/2003 (<a href=3D"http://=
lists.virus.org/webappsec-0301/msg00003.html">http://lists.virus.org/webapp=
sec-0301/msg00003.html</a>). The upshot is that the JDBC spec doesn&#39;t e=
xplicitly require that PreparedStatement prevents injection, so there&#39;s=
 certainly some risk in relying exclusively on them.=C2=A0That&#39;s why in=
put validation, escaping, and access reference maps are important security =
controls. And of course there are degenerate cases like PreparedStatement.e=
xecuteQuery( &quot;exec ?&quot; );</div>

<div>=C2=A0</div>
<div>I looked into the MySQL driver back then and decided that it wasn&#39;=
t obviously vulnerable.=C2=A0 I even took a swing at reversing the Oracle J=
DBC drivers, but I didn&#39;t get far enough to give anyone any confidence.=
=C2=A0 This is exactly the lack of visibility that makes it so difficult to=
 make progress in application security.</div>

<div>=C2=A0</div>
<div>--Jeff<br><br></div>
<div class=3D"gmail_quote">On Wed, Nov 25, 2009 at 11:32 AM, Rohit Sethi <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:rklists@gmail.com";>rklists@gmail.com<=
/a>&gt;</span> wrote:<br>
<blockquote style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3D"gmail_quote">Common advice in the Java world =
is to use properly bound variables in<br>PreparedStatements to protect agai=
nst SQL Injection. Many people have<br>
talked about the fact that the protection provided by<br>PreparedStatements=
 is really dependent on how the JDBC drivers are<br>coded.<br><br>ESAPI tak=
es the approach to not rely on JDBC drivers and instead<br>provides its own=
 encoding codecs for MySQL and Oracle. For other<br>
databases,however, many people rely on the JDBC drivers.<br><br>My question=
 is: does anyone know of a study, list or project that<br>discusses which J=
DBC drivers are known to protect against SQL<br>Injection (in properly boun=
d variables in prepared statements)?<br>
Essentially I&#39;m looking for a whitelist of JDBC drivers that, if used<b=
r>properly, a developer can feel confident that they&#39;re not vulnerable<=
br>to SQL Injection.<br><br>Thanks,<br><br>--<br>Rohit Sethi<br>Security Co=
mpass<br>
<a href=3D"http://www.securitycompass.com/"; target=3D"_blank">http://www.se=
curitycompass.com</a><br><br>----------------------------------------------=
------------------------------<br>Join us on IRC: <a href=3D"http://irc.fre=
enode.net/" target=3D"_blank">irc.freenode.net</a> #webappsec<br>
<br>Have a question? Search The Web Security Mailing List Archives:<br><a h=
ref=3D"http://www.webappsec.org/lists/websecurity/archive/"; target=3D"_blan=
k">http://www.webappsec.org/lists/websecurity/archive/</a><br><br>Subscribe=
 via RSS:<br>
<a href=3D"http://www.webappsec.org/rss/websecurity.rss"; target=3D"_blank">=
http://www.webappsec.org/rss/websecurity.rss</a> [RSS Feed]<br><br>Join WAS=
C on LinkedIn<br><a href=3D"http://www.linkedin.com/e/gis/83336/4B20E4374DB=
A" target=3D"_blank">http://www.linkedin.com/e/gis/83336/4B20E4374DBA</a><b=
r>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br><br>--pl<br>

--0016e6d644f5ccae0f047937832e--