I usually just lurk on this list, but I think I'll pipe in here.
I think Jeff 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]
