Re: Potential Security Flaw in Struts MVC

[Peter Alfors]

I think I must be missing something...  I don't see how a user/hacker is going
to gain access to the system if one is using security.
If you route each request through a security check (realm) then you should be
able to determine if the current user has access to the requested page/action.

Each task should be a different action, rather than using, say, query string
parameters to define an action.
Then the security realm can authenticate the user before allowing the action to
take place.

The code is being run server side, therefore, users cannot introduce their own
classes to over-ride the current form classes or actions.

Am I missing something?

Thanks,
    Pete




Christian Cryder wrote:

> 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]

begin:vcard 
n:;
x-mozilla-html:FALSE
org:<BR><IMG SRC="http://www.irista.com/logo/irista.gif";><BR><BR><FONT Color=#000080><FONT SIZE=2><B>Bringing Vision to Your Supply Chain
adr:;;;;;;
version:2.1
end:vcard