Oliver Jowett wrote:
>On Mon, Jul 21, 2003 at 10:18:19AM -0400, Dmitry Tkach wrote:
>
>
>
>>You can't possibly hope that JDBC driver will take care of alll of the
>>security risks for you. If you don't know how to write safe code, you'll
>>be doomed. If you do, then you do not need help from jdbc driver. JDBC
>>driver's whole purpose is to provide an abstraction layer between a
>>database and an application program.
>>It has nothing to do with security whatsoever.
>>
>>
>
>This is only true if all DBs use identical SQL syntax, which they don't.
>Tried embedding a NUL into a query lately?
>
If you use standard SQL, and standard compliant database, you should be ok.
If you use certain db-specific extensions, you'll still benefit from
JDBC, abstracting *most* of your sql for you.
My point was that it has nothing to do with security anyway. :-)
I was not planning to start discussing how much abstraction it provides.
I agree, that it could be better.
>Even if it was true, it's still better to have one piece of code that does
>the escaping, rather than N different ones. With escaping in the JDBC
>driver, you've reduced the scope of the code you need to audit for syntax
>from "all query strings and all parameters" to "the JDBC driver's
>parameter-escaping code and all query strings".
>
>
>
Sure. And that's good.
That's precisely the point - if you guys start taking functionality
away, so that I am not longer able to do things with it that I used to
be able to do, then I will not be able to benefit from it as much as I
used to - I'll have to switch from PreparedStatements to Statements and
do all that escaping/parsing on my own.
That's exactly what I am trying to avoid
Dima
