Bug #3164 prepared statement query validation ant task
Submitted: 13 Mar 2004 1:01 Modified: 11 Nov 2009 2:35
Reporter: Ralf Hauser Email Updates:
Status: Won't fix Impact on me:
None 
Category:Connector / J Severity:S4 (Feature request)
Version:any OS:Any (any)
Assigned to: Mark Matthews CPU Architecture:Any

[13 Mar 2004 1:01] Ralf Hauser
Description:
As per http://lists.mysql.com/java/6094 prepared statements will be beneficial for everybody who eventually migrates to MySQL-4.1 or newer for performance reasons. Also, it should help against sql-injection attacks (see also http://prdownloads.sourceforge.net/owasp/OWASPGuideV1.1.1.pdf?download, chapt 11, p . 44 or 37).

One problem, that costs me quite some time is that by tearing the SQL statement apart, this is yet another source of errors - for example the number of array elements doesn't match the number of "?".

Since all my DB activities are in one servlet class, it doesn't appear to be too hard to analyze this class at build time.

It appears to be a great time saver because otherwise, one will only notice such errors at runtime, possibly after lengthy testing!

If this doesn't exist, in a related effort, I got nice results combining net.sf.cglib.transform and org.objectweb.asm into an ant task (see also http://mail-archive.objectweb.org/asm/2003-09/msg00030.html)!

Before trying to use those tools for this purpose, I'll also ask the http://lists.mysql.com/java mailing list whether this already has been done!

How to repeat:
typo

Suggested fix:
run ant task at build time (from build.xml)
[10 May 2004 17:39] Ralf Hauser
maybe also eclipse's Java Editor GUI could do this? (See https://bugs.eclipse.org/bugs/show_bug.cgi?id=61614)
[2 Oct 2005 19:51] Ralf Hauser
Another feature of this validator task could be to ensure the "sql" string of 
PreparedStatement java.sql.Connection.prepareStatement(String sql) is used in a  way resistant to injection attacks - i.e. no "..." + variable + "..." concatenations, but all variables bound via "?"

see also: http://www.integrigy.com/info/IntegrigyRethinkingSQLInjectionAttacks.pdf