----- Original Message -----
Sent: Monday, May 07, 2001 1:28 PM
Subject: RE: Potential Security Flaw in
Struts MVC
You can easily guard against this by using simple JavaBeans in
the presentation layer and having your action class do the persistant
storage from you JavaBean view layer.
-----Original Message-----
From: Jeff
Trent [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 07, 2001 9:50 AM
To: [EMAIL PROTECTED]
Subject: Re: Potential Security Flaw in Struts MVC
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
>
