True, the security realm validates if the request is legal. However, if the
uderlying model objects are shared (User and UserForm objects in my example)
for both admin and user level forms, then the request could be manipulated
to set other fields beyond what was exposed for the normal user because
struts takes each name, value pair in the request and calls the appropriate
setter in the form for that name.
Listen, it doesn't really matter. Its highly unlikely anybody can exploit
this so I'm going to drop the issue. I don't want to appear to be a flame
here.
- jeff
----- Original Message -----
From: "Peter Alfors" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, May 07, 2001 4:14 PM
Subject: Re: Potential Security Flaw in Struts MVC
> Sure. You could create a jsp page that had the fields you would like, and
even
> call off a remote action from your own page.
> However, if I route my actions through a security realm, then the
requested
> action will be denied because the current user is not logged in. Or.. If
the
> would be hacker is actualy a valid user on the system and has a
> username/passsword, and he trys send his own page (along with additional
fields)
> it will still be caught by the secuirty realm.
> The danger would exist if either form fields, or query string parameters
were
> being used as an action flag.
> If the view, update, add, delete are different actions, then the user will
be
> required to have a valid login before the action will even be executed.
>
> Pete
>
>
> Jeff Trent wrote:
>
> > No, I can write a form locaally and have the action run on your
server...
> >
> > ----- Original Message -----
> > From: "Peter Alfors" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, May 07, 2001 1:56 PM
> > Subject: Re: Potential Security Flaw in Struts MVC
> >
> > > Wouldn't the hacker have to get the new form class into the classpath
of
> > the
> > > server since all of the code runs server side?
> > >
> > >
> > >
> > > Jeff Trent 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
> > > > >
> > >
>
