but if i use external security mechanism, will it be dynamic? i mean to say,
if the admin wants to change his/her password from the application
(using admin interface), how can he/she do that without restarting the
server?
> -----Original Message-----
> From: Martin Duffy [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, May 07, 2001 5:57 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Potential Security Flaw in Struts MVC
>
> A basic problem with most web development is that people are building
> security into their applications. It should be handled outside of the
> application. You can have your application work in conjunction with an
> external security mechanism for more granular control but I the security
> mechanism should be external to the application for the most part.
>
> You could use for example one of the authorization and access modules for
> apache. Then when you create your application you can create specific
> *protected* URLs for say an admin area. Then only the person that is
> logged into the security mechanism with the proper *authorization* can
> access that URL (or one that contains that URL and parameters being passed
> to it in the URL). Security needs to be considered when building the
> applications but trying to build it into the application is a big mistake.
>
>
> A big reason to not build it into the app is that as your security
> requirements change you invariably have to make code changes to your
> application. By using an external mechanism you just change the rules
> governing the authorization and access control usually without any code
> changes to your app.
>
>
>
>
>
> ----- Original Message -----
> From: Jeff Trent <mailto:[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>
> Sent: Monday, May 07, 2001 6:37 PM
> 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
>
>
