If your User bean is constructed from data in a database ONLY, via the
constructor and not by set() methods, then the object can only contain info
it was constructed with. This means that you cant guess and pass whatever
parameters because they were obtained from the database. So unless someone
knew the user name and password for that type of user , you could not get a
User object filled with the flag that enables you to have that level of
security.
IHMO, I thought that the comment someone made about keeping security ouside
of the application was the best idea anyway. If someone has a good reason
for implementing security IN THE APPLICATION rather than or in addition to
using".htaccess" type security than I would like to hear what they have to
say.
Christian.......are you lurking about?
----- Original Message -----
From: "Sean Pritchard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 09, 2001 9:40 AM
Subject: RE: Potential Security Flaw in Struts MVC
>
>
> The way I usually handle this sort of problem is to delegate the security
> back towards the model layer of code. I will usually have some sort of
User
> class and each web session has an associated instance of the class. The
> User class has information on whether the user is authenticated as well as
> the user's permissions. Functions I want to protect are either performed
> through the user object, or the user object serves as a factory for the
> object I want to protect, or the object I want to protect takes a user in
> the constructor and then uses that user object to check permissions on
> methods.
>
> Sean
>
> -----Original Message-----
> From: Christian Cryder [mailto:[EMAIL PROTECTED]]
> Sent: Monday, May 07, 2001 11:15 AM
> To: Struts-User
> 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 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]
>
