ibatis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brice Ruth <bdr...@gmail.com>
Subject Fwd: Security Extension?
Date Wed, 21 Sep 2005 01:31:14 GMT
A plug-in would certainly be my preferred implementation. I agree that 
validation can take place in the service layer, but this suggestion came up 
in a discussion of "security in depth", i.e. the more checks that are being 
done, the less likely a vulnerability will compromise much of the system.

The discussions have revolved largely around various regulations that are 
being imposed and what can be done at all layers, and at all stages of 
development, to secure applications, or isolate vulnerabilities. Of 
particular interest are the types of things that don't touch existing code 
(like a front-end filter, or something that sits between the application and 
the database, like an iBATIS plugin). AOP is an option in this realm, too, 
of course.

I'll keep this in mind as the 3.x development proceeds!

Thanks for the feedback, Brandon.


On 9/20/05, Brandon Goodin <brandon.goodin@gmail.com> wrote:
> I am not a fan of Validator whatsoever. But, apart from that and I
> think a rules engine would already fit that bill. A rules engine would
> rest in your service layer. By the time your objects reach your DAO
> layer the assumption should be made that they are valid. If your 
> validation issues can't be handled in your service layer then you
> should think about taking up stored procedures. Personally, I would
> not be on board with this kind of functionality in iBatis.
> But, we have tossed around the idea of making iBatis 3.x configs more
> pluggable. Maybe you can take up the initiative then as a plugin.
> Brandon
> On 9/20/05, Brice Ruth <bdruth@gmail.com> wrote:
> > Hi guys,
> >
> > I've been involved in various "secure application" efforts in the past
> > couple months and one idea that surfaced is securing database 
> interaction
> > from the application that's accessing the database. So, basically 
> preventing 
> > parameters from being passed into the database that are invalid or 
> crafted
> > in such a way as to expose vulnerabilities in the underlying database.
> >
> > Obviously SQL-injection is one such vulnerability, but this is easily 
> > managed by using parameters. What I'm proposing is a validation 
> framework
> > for iBATIS that works similarly to Struts Validator (and uses
> > Commons-Validator, as Struts does). So, in addition to having a SqlMap 
> file, 
> > you might have a validation file that could be configured by id or class
> > name (much like Struts allows an action path or an ActionForm to be
> > specified) - and the iBATIS infrastructure would run the incoming data 
> > through the necessary validations, via commons-validator, before 
> attempting
> > any database access.
> >
> > Obviously this is still a pretty rough idea, but it seemed like it had 
> some
> > potential. What say ye? 
> >
> > --
> > Brice Ruth
> > Software Engineer, Madison WI

View raw message