db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Monroe" <Greg.Mon...@DukeCE.com>
Subject RE: Proposal for Automatic text escaping and overflow checking
Date Tue, 04 Oct 2005 15:00:09 GMT
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:fischer@seitenbau.net] 
 
> 
> 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 <thomas.vandahl@tewisoft.de> 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: torque-dev-unsubscribe@db.apache.org
> > For additional commands, e-mail: torque-dev-help@db.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
> 
> 

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: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org


Mime
View raw message