Hi Geoff.
I deal with these regularly, and have stepped through JDBC drivers
from the client side java all the way through to a server's (buggy)
C++ driver in assembler.
Basically there are 2 reasons to use PreparedStatement.
1 - efficiency, since they're compiled, and the server can cache them
and just stuff new parameters in for the next query. (Also batch them.)
2 - safety, as mentioned it escapes the parameters, though the driver
I deal with often has problems with parameter handling of Japanese
characters when using PreparedStatement. The solution in this case is
to use Statement and escape parameters yourself, which sucks!
Anyway, quick Google search:
http://www.oracle.com/technology/oramag/oracle/02-sep/o52jdbc.html
http://www.onjava.com/pub/a/onjava/2001/12/19/oraclejdbc.html?page=last
Cheers,
Nick.
Geoff Longman wrote:
Cool. Is there a reference somewhere that describes why prepared
statements are safe?
Not that I don't trust you all, but the info isn't for me and I will
have no credibility without a link or something I can pass along.
Thanks!
Geoff
On 8/8/05, Viktor Szathmary <[EMAIL PROTECTED]> wrote:
hi,
On 8/8/05, Geoff Longman <[EMAIL PROTECTED]> wrote:
Has anyone out there given any serious thought towards a strategy for
preventing these kinds of attacks in Tapestry forms?
using PreparedStatements with bound variables is a good enough
solution for SQL insertion (plus throw in the usual basic data
validation for good measure).
regards,
viktor
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
