This is a bit off subject but since I'm in commentary-mode today I'll also
mention it.
I need to give some background here first:
As I mentioned in an earlier message, I worked on a fairly large web project
(several million hits per day, tens of thousand user sessions per day). The
app runs on 7 iPlanet web servers (Sun 420R) and 3 application servers (Sun
4500s) (formerly called Netscape Application Server - aka NAS). NAS load
balances sessions & requests between the app servers in real time. As a
result, Netscape advocates small as possible sessions sizes since session
information is constantly being i/o'ed across the app servers.
What led me to Struts initially was the belief that Struts can help me take
the drudgery out of creating multi-page wizards (very prevalent in the app).
However, I was a little dismayed to learn that in order to accomplish this I
need to rely heavily on session scoped (not request) beans. This would
cause the app servers to spend an enormous amount of time communicating with
one another.
Therefore, if I haven't reached my quota today, I'd like to suggest to
management that there is a bean property (or something) that results in form
fields being propogated accross multiple pages of my request/form and are
managed using hidden variables alone. This would be an alternative to using
session scope but would accomplish the same thing. Again, all comments are
welcome...
-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
> 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]
>
>
