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
