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
>