Carl,
I think you're right except that you also need:
3. A custom tag that uses the same security model as the Action which
is only required if a .JSP is accessed directly.
Personally, I pre-populate a lot of my views, so most of the time I'm
hitting the Action first.
Anthony
-----Original Message-----
From: George, Carl [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 07, 2001 1:01 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Potential Security Flaw in Struts MVC
I think you are trying to make things too hard, you could handle this
relatively simple in two different ways:
1. You could inherit your actions from a super class that simple check
to see if the user is logged our has sufficient privileges. And add a
super(request) method as the first line of the action.
2. Have a security class that is called in the first line, maybe from
an action interface, and check the login and privs that way. The security
class could have a call to a session bean that holds all the security info.
-----Original Message-----
From: Jeff Trent [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 07, 2001 2:47 PM
To: [EMAIL PROTECTED]
Subject: Re: Potential Security Flaw in Struts MVC
Beyond the scope of my brain container class (maybe in a week or so I'll
know how to translate what you just said in terms of what I know) :^>
----- Original Message -----
From: Jason Chaffee <mailto:[EMAIL PROTECTED]>
To: '[EMAIL PROTECTED]'
<mailto:'[EMAIL PROTECTED]'>
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]
<mailto:[EMAIL PROTECTED]> ]
Sent: Monday, May 07, 2001 9:50 AM
To: [EMAIL PROTECTED] <mailto:[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]
<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
>
