Well, it all boils down to using PreparedStatements really - use Hibernate or OJB or whatever persistence framework you choose and you are save, cause they are using PreparedStatements internally, use PreparedStatements yourself and you are save, too...
regards, Martin On Thu, 24 Mar 2005 22:10:32 +0100, Werner Punz <[EMAIL PROTECTED]> wrote: > Jonathan Eric Miller wrote: > > If you are using direct SQL, I would recommend using PreparedStatements > > instead of Statements. As far as I know, PreparedStatements pretty much > > rule out SQL injection attacks. If anyone knows otherwise, please let me > > know... > > > > Others have mentioned using Object/Relational mapping software. I would > > recommend this too. Personally, I'm using Hibernate which I like a lot. > > I think Hibernate uses PreparedStatements internally. Hibernate also has > > what it calls a "Criteria API" which you can use to build up queries > > programatically. I use this a lot when I have a Web form that has > > several fields and depending which fields are filled in it adds filter > > criteria to the query. Hibernate is one of the best new software > > packages that I've used. That and JSF of course! ;-) > > > > > I second that recommendation, I implicitely thought about Hibernate > when I sent the last mail down this list describing the situation. > > Criteria APIs are pretty resistent against SQL injection because no SQL > is used just POJOs to build the query. > > But in my opinion the abstracted query language of Hibernate should give > enough protection against pure SQL injection since it is transformed > through several layers before hitting SQL. > > You also can use programmatic interceptors in Hibernate, classes which > basically are triggered at certain ops (see it as AOP sort of). That > means you can put some kinde of event trigger on the save methods which > can check the query for possible injection. > There are various other routes, like doing this with a real AOP > framework like Spring. > > But in my opinion Hibernate alone and bypassing SQL totally by using > either the Hibernate query language and/or Criteria objects should give > enough protection against SQL injection. If a case arises where you need > more protection. Hibernate allows prepared statements on ORM level using > its own query language and if you even need more, go the interceptor / > AOP route to cover that stuff. > > For me currently Hibernate alone and not using plain SQL is security > enough (I wish anyone good luck in sending a plain SQL down a Hibernated > query). If I need more I always can use aspects and interceptors to do a > real coverage on my DAO objects. > >
