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