I like it! I second this request totally! I too have been involved with
large scale development projects and I can relate closely to what you are
saying Chris. A simple implementation could be a new derivation off of
Action called SecurityAction with an abstract method called validate (not
like the form validate). This validate checks to see if the action is valid
for the current http request / context. If you want to become more
adventurous, have a default implementation instead which uses the
configuration properties.
- jeff
----- Original Message -----
From: "Christian Cryder" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, May 07, 2001 1:52 PM
Subject: RE: Potential Security Flaw in Struts MVC
> I usually just lurk on this list, but I think I'll pipe in here.
>
> I think Curt raises a valid point, and it's one of my particular gripes
> about the webapp paradigm (certainly not Struts in general): every
"action"
> that is represented by URL is accessible if you know the right information
> (or can guess it).
>
> Here's an example. Let's say I have I have servlets (or JSPs, or whatever)
> that do things like HireEmployee, FireEmployee, AdjustWages, PayBonus,
etc.
> Based on naming convention, if I have access to some of these functions I
> might very well be able to guess the names of others. So I have to build
> security into each of these functions, to ensure that the user is
authorized
> to do the task.
>
> Now, for a simple app, this may not be too bad: just cut and paste the
code
> and you're on your way. As the application grows in complexity, however
> (either in the number of functions that need to be validated, or the code
> that does the validation, or both), it becomes increasingly easy to
> introduce bugs into the system. The developer might miscode a particular
> security check. Or he might forget to add security for a newly created
> function. If you have a system with hundreds or thousands of secure
> functions, the chances of making errors increases significantly if you are
> duplicating code in all those places, and any mistake results in a
security
> hole within your app.
>
> Now, what are some possible strategies for dealing with this?
>
> Well, in JSP's you could probably do includes to reuse the same physical
> piece of code, or in Servlets you could delegate to some kind of common
> security function. Neither of these situations solves the scenario however
> where the developer forgets to invoke the proper security measures (maybe
> they're not aware of the proper security for a task, or maybe they just
made
> a mistake). The point is that even though you're using includes or calling
a
> common authorization method (thereby reducing the amount of lines of
> duplicated code), you are still relying on all of the actions to make the
> call in the first place. If you have a system with hundreds of functions,
> what are the odds that as that systems grows (new functions added,
security
> policies modified, etc) mistakes will creep in? Pretty good, in my
> experience. And in the webapp environment such security holes are often
more
> accessible to the world at large.
>
> What if you could define actions as belonging to a particular master class
> of action. In other words, the example functions I gave above might all be
a
> subset of "MgrActions" or something like that? What would really be nice
> would be for actions to be defined hierarchically, and to allow for
> validations/authorization to be performed on a parent. So for instance,
> rather than duplicating specific authorizations for HireEmployee,
> FireEmployee, AdjustWages, PayBonus, it'd be nice to just write the
> authorization code once for MgrActions, and know that it would
automatically
> get applied to any of the actions that "extend" the MgrAction. Then when
you
> add new actions, they would automatically "inherit" the security policies
of
> all their parent actions. If you need to modify security policies, you'd
> only have to change the logic in one place.
>
> I have no idea how you would implement something like this in Struts (or
if
> its even possible). In Barracuda, we were able to do this in our event
> model. When client requests come in, they are translated to events, and
for
> every event that is dispatched, if that event implements a marker
interface
> called Polymorphic, then all the Event's parent events will be dispatched
> first (since, after all, the target event "is an instance of" each of
those
> parent events). This pattern works extremely well for implementing
policies
> that apply to portions of an application. As the application evolves, you
> only have to make changes to authorization logic in one place; new actions
> automatically inherit their parents' policies; and if you ever need to add
> new policies (like say logging all the MgrAction events plus all the
> SrMgrAction events), all you have to do is change your event hierarchy and
> add new listener code for the newly defined event. This logic would then
> automatically apply to all events further down the chain.
>
> Like I said, this has worked very well for us in Barracuda. I have no idea
> how you'd apply this concept in Struts, but the pattern itself
(hierarchical
> events/actions) should be applicable to just about any web app framework.
> The only limiting factor that I can think of is that in order to implement
> hierarchy, you'd probably have to define your actions or events as real
> objects, not just Strings.
>
> Anyway, I'd be curious to hear thoughts and feedback, and to know how
others
> have approached this particular type of problem...
>
> Christian
> ------------------------------------------------
> Christian Cryder
> [EMAIL PROTECTED]
> Barracuda - Open-source MVC Component Framework for Webapps
> http://barracuda.enhydra.org
> ------------------------------------------------
> "What a great time to be a Geek"
>
> > -----Original Message-----
> > From: Curt Hagenlocher [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, May 07, 2001 10:11 AM
> > To: '[EMAIL PROTECTED]'
> > Subject: RE: Potential Security Flaw in Struts MVC
> >
> >
> > > However, if someone is familiar with the db schema and the
> > > naming convention the developer used, that user could subvert
> > > the application by writing his own version of the UI which
> > > contains an "Administrative User Flag" field (or any other
> > > field for that matter) and the basic form processing in
> > > Struts will kindly honor the request and set the
> > > "Administrative Flag" on the user. Unless, of course, the
> > > developer makes special provisions to prevent this behavior.
> >
> > Creating a secure web application means that *every* HTTP
> > request should be checked for validity. Any data that comes
> > from the client is suspect. This is no more or less true
> > with Struts than without it.
> >
> > --
> > Curt Hagenlocher
> > [EMAIL PROTECTED]
>
>
