Good points all. This is why I proposed before coding. I have to admit that in 7 years of Java coding I never knew that prepared statements do automatic escaping! Always new tricks to be found...
But then, I went looking for information about it. I found lots of third party info about it, but in Sun's documents (Java API docs, JDBC Spec 3.0, General search of Developer references on Sun's site) I didn't find it specified as a REQUIREMENT for JDBC drivers. I looked especially hard at the JDBC 3.0 specs too. The one area that was not well documented was the specific tests that the JDBC Certification tests do... it may be hard coded in these. Anyway, it seems that despite not being written as a formal part of the standard (may be in upcoming JDBC 4.0?), it's a defacto standard.. but I'll be checking my JDBC drivers to make sure. As to delegating buffer overflow checking to the database engine... well, I'll just say that I have to deal with MS SQL servers (some are still 7.0 systems)and I have some...errr.. scheptisizm... about this. But that's is a personal "trust but verify" call to code for this. I'll except that Torque's current philosophy is generally OK. So, bottom line is... code doesn't need to be added to protect against overflow and code injection attacks. But people should validate that their drivers handle quoting properly for prepared statements and that their server engines are patched against any overflow problems. (Or if they want to trust but verify... add the code outside Torque). Thanks for the feedback and clairification on this. Greg > -----Original Message----- > From: Thomas Fischer [mailto:[EMAIL PROTECTED] > > I was also under the impression that Torque has no problems > with these vulnerabilities. String escaping is definitely > handled by the DB driver because prepared statements are used > for the inserts and updates. My understanding is that range > checks are also handled either by the db driver or the database. > > Greg, do you have an example where you have actually seen > anything problematic ? > > Thomas > > > Thomas Vandahl <[EMAIL PROTECTED]> schrieb am > 04.10.2005 08:34:00: > > > Greg Monroe wrote: > > > limited length strings like SQL does. Java has no concept of > > > special characters in strings that need to be delimited like SQL > > > does. How can > > > > ensuring that this mapping is done properly NOT be part > of the O/R > > > layer's responsiblities? > > > > AFAICS, Torque does the quoting of special SQL chars just > fine. I see > > no real need for an extension here. > > > > IMO, range checks are not an O/R layer issue, you can even > rely on the > > database throwing an error to get this. Keep it simple. > > > > Bye, Thomas. > > > > > > > --------------------------------------------------------------------- > > 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] > > Duke CE Privacy Statement Please be advised that this e-mail and any files transmitted with it are confidential communication or may otherwise be privileged or confidential and are intended solely for the individual or entity to whom they are addressed. If you are not the intended recipient you may not rely on the contents of this email or any attachments, and we ask that you please not read, copy or retransmit this communication, but reply to the sender and destroy the email, its contents, and all copies thereof immediately. Any unauthorized dissemination, distribution or copying of this communication is strictly prohibited. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
