If you share a bean between two security groups, you
can still have separate actions. Only an authorized
user of the group could access its action. Then the
non-administrative action doesn't save the
administrative only field.
David
--- Jeff Trent <[EMAIL PROTECTED]> wrote:
> That is not what my thinking was. But that could be
> an issue also. My
> concern is someone intentionally and maliciously
> creating a form to supply
> more parameters than originally intented by the
> developer. For instance,
> consider the UserForm fields:
>
> Name (available to enrollment &
> administrative interface)
> Address (available to enrollment & administrative
> interface)
> Phone (available to enrollment & administrative
> interface)
> Email (available to enrollment & administrative
> interface)
> ApprovedUserFlag (available to administrative
> interface only)
> AdministrativeUserFlag (available to administrative
> interface only)
>
> If a user knows your naming concention, they can
> write their own form to
> override the administrative-level fields above.
>
>
> ----- Original Message -----
> From: "Anthony Martin" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, May 07, 2001 11:59 AM
> Subject: RE: Potential Security Flaw in Struts MVC
>
>
> > Jeff,
> >
> > Are you asking if book marking a URL that contains
> query parameters might
> be
> > a security risk?
> >
> >
> > Anthony
> >
> > -----Original Message-----
> > From: Jeff Trent [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, May 07, 2001 8:37 AM
> > To: [EMAIL PROTECTED]
> > Subject: Potential Security Flaw in Struts MVC
> >
> >
> > I may be wrong about this (only been working w/
> Struts for a week now).
> But
> > I do see a potential security flaw in struts that
> I would like to hear
> from
> > others regarding.
> >
> > Consider a simple set of struts classes that
> represent a user in a system.
> > You would probably have classes that look
> something like this:
> > User (the model representing
> the user)
> > UserForm (an enrollment form for a new
> user)
> > UserAction (Saves the UserForm
> information to db, etc)
> >
> > The User class would have accessors and modifiers
> like getFirstName(),
> > setFirstName(), getAdministrativeUserFlag(),
> setAdministrativeUserFlag(),
> > etc. The basic implementation of the UserForm is
> to take the UI form
> data,
> > introspect the beans, and call the correct
> modifier of the UserForm bean
> > based on the fields contained within the UI
> submission/form. A developer
> of
> > course would not expose the "Administrative User
> Flag" option on the UI
> for
> > enrollment (that would be found possibly in some
> other
> administrative-level
> > module). 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.
> However, its not entirely
> > obvious to the struts user (in my opinion) that
> this is even a concern.
> Am
> > I making sense here?
> >
> > - jeff
> >
>
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
