RE: Potential Security Flaw in Struts MVC
Hi Kumera, If you want to check at the form level, have you considered using a custom tag, such as the app:checkLogon tag used in the example app provided with struts. It's perhaps not the best way as others have pointed out on this list, but it seems to fit your requirements. Jon. -Original Message- From: Jim Richards [mailto:[EMAIL PROTECTED]] Sent: 31 May 2001 09:21 To: [EMAIL PROTECTED] Subject: Re: Potential Security Flaw in Struts MVC At 11:53 PM 30/05/01 -0700, you wrote: A good way of removing the bucketloads :-} from your Action classes is to subclass ActionServlet and implement processActionPerform to do the logon check. It's not just for login though, that was the example I used, every action that generates a form needs to do this. Mostly it is checking against URL hacking. -- Kumera - a new Open Source Content Management System for small to medium web sites written in Perl and using XML http://www.cyber4.org/kumera/index.html
Re: Potential Security Flaw in Struts MVC
please remove me from this list.
Re: Potential Security Flaw in Struts MVC
In the case at hand, nothing stops your user from logging on (so your security checks won't catch anything) and then hand typing a URL with query string parameters that maliciously or accidentally try to change things in the system. If the user is successful at doing this, it's shame on the app developer for listening to request parameters that you shouldn't. This is a good point. I'm finding my Actions and Forms have bucketloads (and that's the technical term for it) of User user; if ((user = (User) request.getSession().getAttribute(user) == null) return mapping.getMapping(index); and on, and on and on. I'd like to try and find a good way to simplify this as best that I can. (This example is required if the session times out, other examples appear when a browser auto-fills in a URL and the user submits it without the form fields. etc. Very bad karma in that case.) Of course, you need to take other defensive measures as well (like using the transaction control support to avoid accidental or malicious resubmits of the same data). I've seen this in the example application, is there any documentation on using it (as best as possible). Thanks. -- Kumera - a new Open Source Content Management System for small to medium web sites written in Perl and using XML http://www.cyber4.org/kumera/index.html
Re: Potential Security Flaw in Struts MVC
A good way of removing the bucketloads :-} from your Action classes is to subclass ActionServlet and implement processActionPerform to do the logon check. -- Martin Cooper - Original Message - From: Jim Richards [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 30, 2001 11:08 PM Subject: Re: Potential Security Flaw in Struts MVC In the case at hand, nothing stops your user from logging on (so your security checks won't catch anything) and then hand typing a URL with query string parameters that maliciously or accidentally try to change things in the system. If the user is successful at doing this, it's shame on the app developer for listening to request parameters that you shouldn't. This is a good point. I'm finding my Actions and Forms have bucketloads (and that's the technical term for it) of User user; if ((user = (User) request.getSession().getAttribute(user) == null) return mapping.getMapping(index); and on, and on and on. I'd like to try and find a good way to simplify this as best that I can. (This example is required if the session times out, other examples appear when a browser auto-fills in a URL and the user submits it without the form fields. etc. Very bad karma in that case.) Of course, you need to take other defensive measures as well (like using the transaction control support to avoid accidental or malicious resubmits of the same data). I've seen this in the example application, is there any documentation on using it (as best as possible). Thanks. -- Kumera - a new Open Source Content Management System for small to medium web sites written in Perl and using XML http://www.cyber4.org/kumera/index.html
Re: Potential Security Flaw in Struts MVC
At 11:53 PM 30/05/01 -0700, you wrote: A good way of removing the bucketloads :-} from your Action classes is to subclass ActionServlet and implement processActionPerform to do the logon check. It's not just for login though, that was the example I used, every action that generates a form needs to do this. Mostly it is checking against URL hacking. -- Kumera - a new Open Source Content Management System for small to medium web sites written in Perl and using XML http://www.cyber4.org/kumera/index.html
Re: Potential Security Flaw in Struts MVC
On Mon, 7 May 2001, Jeff Trent wrote:
Ah, this maybe a problem in the way I've adapted Struts. I reflect all UserForm
method calls directly into the contained User object owned by the UserForm. So for
instance, I have
public class UserForm extends ActionsForm
{
protected User user;
...
public String getName()
{
return user.getName();
}
public void setName(String name)
{
user.setName(name);
}
...
}
Now can you begin to see my original concern? Maybe I need to
separate the model from the form a little more than what I have.
This is where I can step in (better late than never :-) and point out that
this is *not* the recommended design pattern for form beans. They really
should be independent, and you really should decide what properties should
be copied from UserForm to User in your Action (or the business logic that
it calls).
The important issue here -- and it's not unique to Struts, the issue is
common to all web application environments -- is that you have absolutely
zero control over what the client decides to send you. For example, if
you rely on client side JavaScript for field validation, what happens when
your client turns JavaScript off? You get garbage input, so you should
always be paranoid and validate (again) on the server side.
In the case at hand, nothing stops your user from logging on (so your
security checks won't catch anything) and then hand typing a URL with
query string parameters that maliciously or accidentally try to change
things in the system. If the user is successful at doing this, it's shame
on the app developer for listening to request parameters that you
shouldn't.
Of course, you need to take other defensive measures as well (like using
the transaction control support to avoid accidental or malicious resubmits
of the same data).
For those of you going to JavaOne, I'm hosting a BOF on Thursday night at
7pm (BOF #1291) called Approaches to User Authentication and Access
Control in Web Applications. This discussion has given me some
additional topical material to make sure that we cover.
- jeff
Craig McClanahan
RE: Potential Security Flaw in Struts MVC
On Tue, 8 May 2001, Manabendra Sarkar wrote: 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? There is no global answer to that question, because it depends on how your security information is looked up. Just as an example of what's possible, consider how Tomcat 4.0 implements container managed security. The default mechanism is a simple XML file that is read once when the app starts up, so any changes require an application restart. However, you can easily configure Tomcat to look up users and roles in a database (via JDBC) or a directory server (via JNDI). In these cases, changes you make to the usernames, their passwords, and their security roles *are* dynamically recognized, because they are looked up every time the user logs on. Craig McClanahan
Re: Potential Security Flaw in Struts MVC
I've sure my ears will be ringing at home that night :^)
- Original Message -
From: Craig R. McClanahan [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, May 31, 2001 1:01 AM
Subject: Re: Potential Security Flaw in Struts MVC
On Mon, 7 May 2001, Jeff Trent wrote:
Ah, this maybe a problem in the way I've adapted Struts. I reflect all
UserForm method calls directly into the contained User object owned by the
UserForm. So for instance, I have
public class UserForm extends ActionsForm
{
protected User user;
...
public String getName()
{
return user.getName();
}
public void setName(String name)
{
user.setName(name);
}
...
}
Now can you begin to see my original concern? Maybe I need to
separate the model from the form a little more than what I have.
This is where I can step in (better late than never :-) and point out that
this is *not* the recommended design pattern for form beans. They really
should be independent, and you really should decide what properties should
be copied from UserForm to User in your Action (or the business logic that
it calls).
The important issue here -- and it's not unique to Struts, the issue is
common to all web application environments -- is that you have absolutely
zero control over what the client decides to send you. For example, if
you rely on client side JavaScript for field validation, what happens when
your client turns JavaScript off? You get garbage input, so you should
always be paranoid and validate (again) on the server side.
In the case at hand, nothing stops your user from logging on (so your
security checks won't catch anything) and then hand typing a URL with
query string parameters that maliciously or accidentally try to change
things in the system. If the user is successful at doing this, it's shame
on the app developer for listening to request parameters that you
shouldn't.
Of course, you need to take other defensive measures as well (like using
the transaction control support to avoid accidental or malicious resubmits
of the same data).
For those of you going to JavaOne, I'm hosting a BOF on Thursday night at
7pm (BOF #1291) called Approaches to User Authentication and Access
Control in Web Applications. This discussion has given me some
additional topical material to make sure that we cover.
- jeff
Craig McClanahan
Re: Potential Security Flaw in Struts MVC....Christian.......are you lurking about?
If your User bean is constructed from data in a database ONLY, via the constructor and not by set() methods, then the object can only contain info it was constructed with. This means that you cant guess and pass whatever parameters because they were obtained from the database. So unless someone knew the user name and password for that type of user , you could not get a User object filled with the flag that enables you to have that level of security. IHMO, I thought that the comment someone made about keeping security ouside of the application was the best idea anyway. If someone has a good reason for implementing security IN THE APPLICATION rather than or in addition to using.htaccess type security than I would like to hear what they have to say. Christian...are you lurking about? - Original Message - From: Sean Pritchard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 09, 2001 9:40 AM Subject: RE: Potential Security Flaw in Struts MVC The way I usually handle this sort of problem is to delegate the security back towards the model layer of code. I will usually have some sort of User class and each web session has an associated instance of the class. The User class has information on whether the user is authenticated as well as the user's permissions. Functions I want to protect are either performed through the user object, or the user object serves as a factory for the object I want to protect, or the object I want to protect takes a user in the constructor and then uses that user object to check permissions on methods. Sean -Original Message- From: Christian Cryder [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 11:15 AM To: Struts-User Subject: RE: Potential Security Flaw in Struts MVC I usually just lurk on this list, but I think I'll pipe in here. I think Jeff raises a valid point, and it's one of my particular gripes about the webapp paradigm (certainly not Struts in general): every action that is represented by URL is accessible if you know the right information (or can guess it). Here's an example. Let's say I have I have servlets (or JSPs, or whatever) that do things like HireEmployee, FireEmployee, AdjustWages, PayBonus, etc. Based on naming convention, if I have access to some of these functions I might very well be able to guess the names of others. So I have to build security into each of these functions, to ensure that the user is authorized to do the task. Now, for a simple app, this may not be too bad: just cut and paste the code and you're on your way. As the application grows in complexity, however (either in the number of functions that need to be validated, or the code that does the validation, or both), it becomes increasingly easy to introduce bugs into the system. The developer might miscode a particular security check. Or he might forget to add security for a newly created function. If you have a system with hundreds or thousands of secure functions, the chances of making errors increases significantly if you are duplicating code in all those places, and any mistake results in a security hole within your app. Now, what are some possible strategies for dealing with this? Well, in JSP's you could probably do includes to reuse the same physical piece of code, or in Servlets you could delegate to some kind of common security function. Neither of these situations solves the scenario however where the developer forgets to invoke the proper security measures (maybe they're not aware of the proper security for a task, or maybe they just made a mistake). The point is that even though you're using includes or calling a common authorization method (thereby reducing the amount of lines of duplicated code), you are still relying on all of the actions to make the call in the first place. If you have a system with hundreds of functions, what are the odds that as that systems grows (new functions added, security policies modified, etc) mistakes will creep in? Pretty good, in my experience. And in the webapp environment such security holes are often more accessible to the world at large. What if you could define actions as belonging to a particular master class of action. In other words, the example functions I gave above might all be a subset of MgrActions or something like that? What would really be nice would be for actions to be defined hierarchically, and to allow for validations/authorization to be performed on a parent. So for instance, rather than duplicating specific authorizations for HireEmployee, FireEmployee, AdjustWages, PayBonus, it'd be nice to just write the authorization code once for MgrActions, and know that it would automatically get applied to any of the actions that extend the MgrAction. Then when you add new actions, they would automatically inherit the security policies of all their parent actions. If you need to modify security policies, you'd only
RE: Potential Security Flaw in Struts MVC....Christian.......are you lurking about?
Christian...are you lurking about? Yeah, but I'm really behind on my reading. :-) IHMO, I thought that the comment someone made about keeping security ouside of the application was the best idea anyway. If someone has a good reason for implementing security IN THE APPLICATION rather than or in addition to using.htaccess type security than I would like to hear what they have to say. Well I would certainly say that handling security outside the app is the EASIEST way of doing it, but I can think of lots of scenarios where its not the BEST way of doing it (and in many cases, may not even be an option at all). For instance, what happens when you're trying to write a web front end to a system where user/group info is stored in a preexisting legacy database? What about the scenario where you have parts of a screen accessible/visible depending on who the user is (admin/non-admin)? I'm sure others can through out a ton of other examples. From my perspective, yes, you always try and handle security as far from the app as possible, but you also need to recognize that there are occasions (and valid biz reasons) for pushing aspects of security down into the app. As such, a good framework should always support the range of possibilities. The question then from my perspective is not should there be security in the application? (of course there will be times when that's necessary), but rather how do we best handle security within an application? (when we have to). I still think the original poster had a valid point. What we don't want to do is have to code separate views/handlers for screens that vary slightly on account of security (ie. fields that are there for one person but not for another). Now obviously, a smart programmer should be checking when handling these kinds of situations. The point of my orginal email was that merely relying on the programmer to be smart and not make mistakes is an approach that doesn't scale real well as application complexity grows (because programmers are human and forget or don't know things). So the question I was raising is Is there a pattern for applying security to groups of actions?. In the case of Barracuda (dealing with events, rather than actions), the solution was to create a hierarchical structure where installing handlers on a particular event automatically causes that policy to be applied to any events the live further down the hierarchy. This particular approach seems very effective in a) facilitating maintenance and b) allowing for mistakes/forgetfulness, both of which work to make a system more secure by helping prevent security holes that tend to creep into systems over the lifecyle of app development. At any rate...I digress again. Does that help at all? Just my .02... Christian Christian Cryder [EMAIL PROTECTED] Barracuda - Open-source MVC Component Framework for Webapps http://barracuda.enhydra.org What a great time to be a Geek -Original Message- From: Jonathan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 09, 2001 8:11 AM To: [EMAIL PROTECTED] Subject: Re: Potential Security Flaw in Struts MVCChristian...are you lurking about? If your User bean is constructed from data in a database ONLY, via the constructor and not by set() methods, then the object can only contain info it was constructed with. This means that you cant guess and pass whatever parameters because they were obtained from the database. So unless someone knew the user name and password for that type of user , you could not get a User object filled with the flag that enables you to have that level of security. IHMO, I thought that the comment someone made about keeping security ouside of the application was the best idea anyway. If someone has a good reason for implementing security IN THE APPLICATION rather than or in addition to using.htaccess type security than I would like to hear what they have to say. Christian...are you lurking about? - Original Message - From: Sean Pritchard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 09, 2001 9:40 AM Subject: RE: Potential Security Flaw in Struts MVC The way I usually handle this sort of problem is to delegate the security back towards the model layer of code. I will usually have some sort of User class and each web session has an associated instance of the class. The User class has information on whether the user is authenticated as well as the user's permissions. Functions I want to protect are either performed through the user object, or the user object serves as a factory for the object I want to protect, or the object I want to protect takes a user in the constructor and then uses that user object to check permissions on methods. Sean -Original Message- From: Christian Cryder [mailto:[EMAIL
Re: Potential Security Flaw in Struts MVC
Here's a quick write up. Let me know if you have problems with it. I tried to use an example that is as real world as possible and that cannot necessarily be fixed with some user realm/role solution. Calvin --- Ted Husted [EMAIL PROTECTED] wrote: Feel free. If you would like to document it, I'd be happy to find a place for it in the users guide. Calvin Yu wrote: I think that this potential exploit should probably be thoroughly documented, along with potential workarounds. Last thing we want is to have Struts being tagged as being unsecure. __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ Security considerations when reusing ActionForms and Actions Because Struts will blindly copy fields from an HTML form to a ActionForm object, developers should take caution when reusing ActionForms and Actions. For example, suppose you have a subclass of ActionForm called UserForm which allows a user to update their profile information. This form has common user related attributes like 'password', 'firstName', and 'lastName'. Now if your web application is a co-branded application, a common occurence is to have users of one brand have features that are not available to users of other brands. To accommodate this, you add attributes to the UserForm such as 'wirelessAccess' and 'emailReports', and have your Action determine that these fields are disabled if null. Well, what can happen now is that a very knowlegdeable user of any brand can submit a custom HTML form that has those attributes and enable them. Note that this problem does not exist only for co-branded web applications but can occur for other web application as well. Workarounds * Perform validation in the ActionForm or Action that makes sure that you are getting the values you are expecting to get in the given context. * Create separate forms for the different contexts.
RE: Potential Security Flaw in Struts MVC
Is it just me or has the list received this message well over 10 times? Chris -Original Message- From: Jeff Trent [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 12:51 PM To: [EMAIL PROTECTED] Subject: Re: Potential Security Flaw in Struts MVC Curt, I don't dispute what your saying. However, to the casual struts user this fact may be easily overlooked and exploited by a hacker. - jeff - Original Message - From: Curt Hagenlocher [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 12:10 PM Subject: RE: Potential Security Flaw in Struts MVC 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. Creating a secure web application means that *every* HTTP request should be checked for validity. Any data that comes from the client is suspect. This is no more or less true with Struts than without it. -- Curt Hagenlocher [EMAIL PROTECTED]
RE: Potential Security Flaw in Struts MVC
How can I am receiving this message again and again in two days? I have received over 10 copies of this message, at the rate of once every 3 hours. Is this a mail bomb? Yi-Xiong -Original Message- From: Christian Cryder [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 11:15 AM To: Struts-User Subject: RE: Potential Security Flaw in Struts MVC I usually just lurk on this list, but I think I'll pipe in here. I think Jeff raises a valid point, and it's one of my particular gripes about the webapp paradigm (certainly not Struts in general): every action that is represented by URL is accessible if you know the right information (or can guess it). Here's an example. Let's say I have I have servlets (or JSPs, or whatever) that do things like HireEmployee, FireEmployee, AdjustWages, PayBonus, etc. Based on naming convention, if I have access to some of these functions I might very well be able to guess the names of others. So I have to build security into each of these functions, to ensure that the user is authorized to do the task. Now, for a simple app, this may not be too bad: just cut and paste the code and you're on your way. As the application grows in complexity, however (either in the number of functions that need to be validated, or the code that does the validation, or both), it becomes increasingly easy to introduce bugs into the system. The developer might miscode a particular security check. Or he might forget to add security for a newly created function. If you have a system with hundreds or thousands of secure functions, the chances of making errors increases significantly if you are duplicating code in all those places, and any mistake results in a security hole within your app. Now, what are some possible strategies for dealing with this? Well, in JSP's you could probably do includes to reuse the same physical piece of code, or in Servlets you could delegate to some kind of common security function. Neither of these situations solves the scenario however where the developer forgets to invoke the proper security measures (maybe they're not aware of the proper security for a task, or maybe they just made a mistake). The point is that even though you're using includes or calling a common authorization method (thereby reducing the amount of lines of duplicated code), you are still relying on all of the actions to make the call in the first place. If you have a system with hundreds of functions, what are the odds that as that systems grows (new functions added, security policies modified, etc) mistakes will creep in? Pretty good, in my experience. And in the webapp environment such security holes are often more accessible to the world at large. What if you could define actions as belonging to a particular master class of action. In other words, the example functions I gave above might all be a subset of MgrActions or something like that? What would really be nice would be for actions to be defined hierarchically, and to allow for validations/authorization to be performed on a parent. So for instance, rather than duplicating specific authorizations for HireEmployee, FireEmployee, AdjustWages, PayBonus, it'd be nice to just write the authorization code once for MgrActions, and know that it would automatically get applied to any of the actions that extend the MgrAction. Then when you add new actions, they would automatically inherit the security policies of all their parent actions. If you need to modify security policies, you'd only have to change the logic in one place. I have no idea how you would implement something like this in Struts (or if its even possible). In Barracuda, we were able to do this in our event model. When client requests come in, they are translated to events, and for every event that is dispatched, if that event implements a marker interface called Polymorphic, then all the Event's parent events will be dispatched first (since, after all, the target event is an instance of each of those parent events). This pattern works extremely well for implementing policies that apply to portions of an application. As the application evolves, you only have to make changes to authorization logic in one place; new actions automatically inherit their parents' policies; and if you ever need to add new policies (like say logging all the MgrAction events plus all the SrMgrAction events), all you have to do is change your event hierarchy and add new listener code for the newly defined event. This logic would then automatically apply to all events further down the chain. Like I said, this has worked very well for us in Barracuda. I have no idea how you'd apply this concept in Struts, but the pattern itself (hierarchical events/actions) should be applicable to just about any web app framework. The only limiting factor that I can think of is that in order to implement hierarchy, you'd probably have to define your actions or events as real objects, not just Strings. Anyway
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
RE: Potential Security Flaw in Struts MVC
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. Creating a secure web application means that *every* HTTP request should be checked for validity. Any data that comes from the client is suspect. This is no more or less true with Struts than without it. -- Curt Hagenlocher [EMAIL PROTECTED]
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
Re: Potential Security Flaw in Struts MVC
Curt, I don't dispute what your saying. However, to the casual struts user this fact may be easily overlooked and exploited by a hacker. - jeff - Original Message - From: Curt Hagenlocher [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 12:10 PM Subject: RE: Potential Security Flaw in Struts MVC 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. Creating a secure web application means that *every* HTTP request should be checked for validity. Any data that comes from the client is suspect. This is no more or less true with Struts than without it. -- Curt Hagenlocher [EMAIL PROTECTED]
RE: Potential Security Flaw in Struts MVC
Wouldn't this not be a concern because the user would never be in the session on the target server? -Original Message-From: Jeff Trent [mailto:[EMAIL PROTECTED]]Sent: Monday, May 07, 2001 11:37 AMTo: [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
Re: Potential Security Flaw in Struts MVC
There is a security risk here as you describe, if (and only if) you are using a generic introspection-based function (like Struts' PropertyUtils.copyBean) to copy the values from the UserForm object to the User object. There are several ways to avoid this -- 1. Don't put an admin flag "setter" method in your User class. 2. In UserAction, don't use the generic bean copy utility -- instead, manually copy the values, excluding the admin flag. 3. As a smarter alternative to #2, don't use a generic bean copy utility -- instead, write an intelligent copy function in the User class, which "knows" that it's copying FROM a UserForm, TO a User, and therefore, skip the copying of the Admin flag. Bryan Jeff Trent wrote: 002501c0d70b$9df009a0$6401a8c0@PROVIDENCE"> 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
RE: Potential Security Flaw in Struts MVC
Title: 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
RE: Potential Security Flaw in Struts MVC
What a great time to be a Geek -Original Message- From: Curt Hagenlocher [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 10:11 AM To: '[EMAIL PROTECTED]' Subject: RE: Potential Security Flaw in Struts MVC 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. Creating a secure web application means that *every* HTTP request should be checked for validity. Any data that comes from the client is suspect. This is no more or less true with Struts than without it. -- Curt Hagenlocher [EMAIL PROTECTED]
Re: Potential Security Flaw in Struts MVC
Wouldn't the hacker have to get the new form class into the classpath of the server since all of the code runs server side? Jeff Trent wrote: 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 begin:vcard n:; x-mozilla-html:FALSE org:BRIMG SRC=http://www.irista.com/logo/irista.gif;BRBRFONT Color=#80FONT SIZE=2BBringing Vision to Your Supply Chain adr:;; version:2.1 end:vcard
RE: Potential Security Flaw in Struts MVC
Any thing dealing with security, (including security validation) keep it in the request scope. That way no other developer (at runtime) can access the security data. [Nanduri, Amarnath]-Original Message-From: Hogan, John [mailto:[EMAIL PROTECTED]]Sent: Monday, May 07, 2001 1:10 PMTo: '[EMAIL PROTECTED]'Subject: RE: Potential Security Flaw in Struts MVC Wouldn't this not be a concern because the user would never be in the session on the target server? -Original Message-From: Jeff Trent [mailto:[EMAIL PROTECTED]]Sent: Monday, May 07, 2001 11:37 AMTo: [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
Re: Potential Security Flaw in Struts MVC
I can appreciate your concern. And it's always good to emphasize security concerns. But you are suggesting that I (or any developer) would write some Action that would accept this UserForm, including the sensitive admin flag, without checking as to whether the admin flag is acceptable in the application's current state. This would indeed be a casual and naive web application developer. For example, the app shouldn't pay attention to the admin flag unless the current user is already in some kind of administrative role. There are many security concerns related to web applications. I haven't actually ever found a good, consise and reasonably complete article on them. Will - Original Message - From: Jeff Trent [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 12:51 PM Subject: Re: Potential Security Flaw in Struts MVC Curt, I don't dispute what your saying. However, to the casual struts user this fact may be easily overlooked and exploited by a hacker. - jeff - Original Message - From: Curt Hagenlocher [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 12:10 PM Subject: RE: Potential Security Flaw in Struts MVC 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. Creating a secure web application means that *every* HTTP request should be checked for validity. Any data that comes from the client is suspect. This is no more or less true with Struts than without it. -- Curt Hagenlocher [EMAIL PROTECTED]
Re: Potential Security Flaw in Struts MVC
depends. He would have a session if he has enrolled already... - Original Message - From: Hogan, John To: '[EMAIL PROTECTED]' Sent: Monday, May 07, 2001 1:09 PM Subject: RE: Potential Security Flaw in Struts MVC Wouldn't this not be a concern because the user would never be in the session on the target server? -Original Message-From: Jeff Trent [mailto:[EMAIL PROTECTED]]Sent: Monday, May 07, 2001 11:37 AMTo: [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
Re: Potential Security Flaw in Struts MVC
Title: 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 To: '[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]] 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 MVCI 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
Re: Potential Security Flaw in Struts MVC
I think that this potential exploit should probably be thoroughly documented, along with potential workarounds. Last thing we want is to have Struts being tagged as being unsecure. Calvin --- David Winterfeldt [EMAIL PROTECTED] wrote: If you share a bean between two security groups, you can still have separate actions. Only an authorized user of the group could access its action. Then the non-administrative action doesn't save the administrative only field. David --- Jeff Trent [EMAIL PROTECTED] wrote: 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 __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Re: Potential Security Flaw in Struts MVC
Christian, You kick ass! Apologies to the sensitive but that was a great explanation of a very obscure but important problem. Bryan Christian Cryder wrote: I usually just lurk on this list, but I think I'll pipe in here.
Re: Potential Security Flaw in Struts MVC
I like it! I second this request totally! I too have been involved with large scale development projects and I can relate closely to what you are saying Chris. A simple implementation could be a new derivation off of Action called SecurityAction with an abstract method called validate (not like the form validate). This validate checks to see if the action is valid for the current http request / context. If you want to become more adventurous, have a default implementation instead which uses the configuration properties. - jeff - Original Message - From: Christian Cryder [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 1:52 PM Subject: RE: Potential Security Flaw in Struts MVC I usually just lurk on this list, but I think I'll pipe in here. I think Curt raises a valid point, and it's one of my particular gripes about the webapp paradigm (certainly not Struts in general): every action that is represented by URL is accessible if you know the right information (or can guess it). Here's an example. Let's say I have I have servlets (or JSPs, or whatever) that do things like HireEmployee, FireEmployee, AdjustWages, PayBonus, etc. Based on naming convention, if I have access to some of these functions I might very well be able to guess the names of others. So I have to build security into each of these functions, to ensure that the user is authorized to do the task. Now, for a simple app, this may not be too bad: just cut and paste the code and you're on your way. As the application grows in complexity, however (either in the number of functions that need to be validated, or the code that does the validation, or both), it becomes increasingly easy to introduce bugs into the system. The developer might miscode a particular security check. Or he might forget to add security for a newly created function. If you have a system with hundreds or thousands of secure functions, the chances of making errors increases significantly if you are duplicating code in all those places, and any mistake results in a security hole within your app. Now, what are some possible strategies for dealing with this? Well, in JSP's you could probably do includes to reuse the same physical piece of code, or in Servlets you could delegate to some kind of common security function. Neither of these situations solves the scenario however where the developer forgets to invoke the proper security measures (maybe they're not aware of the proper security for a task, or maybe they just made a mistake). The point is that even though you're using includes or calling a common authorization method (thereby reducing the amount of lines of duplicated code), you are still relying on all of the actions to make the call in the first place. If you have a system with hundreds of functions, what are the odds that as that systems grows (new functions added, security policies modified, etc) mistakes will creep in? Pretty good, in my experience. And in the webapp environment such security holes are often more accessible to the world at large. What if you could define actions as belonging to a particular master class of action. In other words, the example functions I gave above might all be a subset of MgrActions or something like that? What would really be nice would be for actions to be defined hierarchically, and to allow for validations/authorization to be performed on a parent. So for instance, rather than duplicating specific authorizations for HireEmployee, FireEmployee, AdjustWages, PayBonus, it'd be nice to just write the authorization code once for MgrActions, and know that it would automatically get applied to any of the actions that extend the MgrAction. Then when you add new actions, they would automatically inherit the security policies of all their parent actions. If you need to modify security policies, you'd only have to change the logic in one place. I have no idea how you would implement something like this in Struts (or if its even possible). In Barracuda, we were able to do this in our event model. When client requests come in, they are translated to events, and for every event that is dispatched, if that event implements a marker interface called Polymorphic, then all the Event's parent events will be dispatched first (since, after all, the target event is an instance of each of those parent events). This pattern works extremely well for implementing policies that apply to portions of an application. As the application evolves, you only have to make changes to authorization logic in one place; new actions automatically inherit their parents' policies; and if you ever need to add new policies (like say logging all the MgrAction events plus all the SrMgrAction events), all you have to do is change your event hierarchy and add new listener code for the newly defined event. This logic would then automatically apply to all events further down
Re: Potential Security Flaw in Struts MVC
No, I can write a form locaally and have the action run on your server... - Original Message - From: Peter Alfors [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 1:56 PM Subject: Re: Potential Security Flaw in Struts MVC Wouldn't the hacker have to get the new form class into the classpath of the server since all of the code runs server side? Jeff Trent wrote: 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
Re: Potential Security Flaw in Struts MVC
said, this has worked very well for us in Barracuda. I have no idea how you'd apply this concept in Struts, but the pattern itself (hierarchical events/actions) should be applicable to just about any web app framework. The only limiting factor that I can think of is that in order to implement hierarchy, you'd probably have to define your actions or events as real objects, not just Strings. Anyway, I'd be curious to hear thoughts and feedback, and to know how others have approached this particular type of problem... Christian Christian Cryder [EMAIL PROTECTED] Barracuda - Open-source MVC Component Framework for Webapps http://barracuda.enhydra.org What a great time to be a Geek -Original Message- From: Curt Hagenlocher [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 10:11 AM To: '[EMAIL PROTECTED]' Subject: RE: Potential Security Flaw in Struts MVC 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. Creating a secure web application means that *every* HTTP request should be checked for validity. Any data that comes from the client is suspect. This is no more or less true with Struts than without it. -- Curt Hagenlocher [EMAIL PROTECTED] begin:vcard n:; x-mozilla-html:FALSE org:BRIMG SRC=http://www.irista.com/logo/irista.gif;BRBRFONT Color=#80FONT SIZE=2BBringing Vision to Your Supply Chain adr:;; version:2.1 end:vcard
RE: Potential Security Flaw in Struts MVC
hierarchy and add new listener code for the newly defined event. This logic would then automatically apply to all events further down the chain. Like I said, this has worked very well for us in Barracuda. I have no idea how you'd apply this concept in Struts, but the pattern itself (hierarchical events/actions) should be applicable to just about any web app framework. The only limiting factor that I can think of is that in order to implement hierarchy, you'd probably have to define your actions or events as real objects, not just Strings. Anyway, I'd be curious to hear thoughts and feedback, and to know how others have approached this particular type of problem... Christian Christian Cryder [EMAIL PROTECTED] Barracuda - Open-source MVC Component Framework for Webapps http://barracuda.enhydra.org What a great time to be a Geek -Original Message- From: Curt Hagenlocher [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 10:11 AM To: '[EMAIL PROTECTED]' Subject: RE: Potential Security Flaw in Struts MVC 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. Creating a secure web application means that *every* HTTP request should be checked for validity. Any data that comes from the client is suspect. This is no more or less true with Str __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Re: Potential Security Flaw in Struts MVC
This is a bit off subject but since I'm in commentary-mode today I'll also mention it. I need to give some background here first: As I mentioned in an earlier message, I worked on a fairly large web project (several million hits per day, tens of thousand user sessions per day). The app runs on 7 iPlanet web servers (Sun 420R) and 3 application servers (Sun 4500s) (formerly called Netscape Application Server - aka NAS). NAS load balances sessions requests between the app servers in real time. As a result, Netscape advocates small as possible sessions sizes since session information is constantly being i/o'ed across the app servers. What led me to Struts initially was the belief that Struts can help me take the drudgery out of creating multi-page wizards (very prevalent in the app). However, I was a little dismayed to learn that in order to accomplish this I need to rely heavily on session scoped (not request) beans. This would cause the app servers to spend an enormous amount of time communicating with one another. Therefore, if I haven't reached my quota today, I'd like to suggest to management that there is a bean property (or something) that results in form fields being propogated accross multiple pages of my request/form and are managed using hidden variables alone. This would be an alternative to using session scope but would accomplish the same thing. Again, all comments are welcome... -jeff - Original Message - From: Christian Cryder [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 1:52 PM Subject: RE: Potential Security Flaw in Struts MVC I usually just lurk on this list, but I think I'll pipe in here. I think Curt raises a valid point, and it's one of my particular gripes about the webapp paradigm (certainly not Struts in general): every action that is represented by URL is accessible if you know the right information (or can guess it). Here's an example. Let's say I have I have servlets (or JSPs, or whatever) that do things like HireEmployee, FireEmployee, AdjustWages, PayBonus, etc. Based on naming convention, if I have access to some of these functions might very well be able to guess the names of others. So I have to build security into each of these functions, to ensure that the user is authorized to do the task. Now, for a simple app, this may not be too bad: just cut and paste the code and you're on your way. As the application grows in complexity, however (either in the number of functions that need to be validated, or the code that does the validation, or both), it becomes increasingly easy to introduce bugs into the system. The developer might miscode a particular security check. Or he might forget to add security for a newly created function. If you have a system with hundreds or thousands of secure functions, the chances of making errors increases significantly if you are duplicating code in all those places, and any mistake results in a security hole within your app. Now, what are some possible strategies for dealing with this? Well, in JSP's you could probably do includes to reuse the same physical piece of code, or in Servlets you could delegate to some kind of common security function. Neither of these situations solves the scenario however where the developer forgets to invoke the proper security measures (maybe they're not aware of the proper security for a task, or maybe they just made a mistake). The point is that even though you're using includes or calling a common authorization method (thereby reducing the amount of lines of duplicated code), you are still relying on all of the actions to make the call in the first place. If you have a system with hundreds of functions, what are the odds that as that systems grows (new functions added, security policies modified, etc) mistakes will creep in? Pretty good, in my experience. And in the webapp environment such security holes are often more accessible to the world at large. What if you could define actions as belonging to a particular master class of action. In other words, the example functions I gave above might all be a subset of MgrActions or something like that? What would really be nice would be for actions to be defined hierarchically, and to allow for validations/authorization to be performed on a parent. So for instance, rather than duplicating specific authorizations for HireEmployee, FireEmployee, AdjustWages, PayBonus, it'd be nice to just write the authorization code once for MgrActions, and know that it would automatically get applied to any of the actions that extend the MgrAction. Then when you add new actions, they would automatically inherit the security policies of all their parent actions. If you need to modify security policies, you'd only have to change the logic in one place. I have no idea how you would implement something like this in Struts (or if its even possible). In Barracuda, we were able to do
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
Re: Potential Security Flaw in Struts MVC
Sure. You could create a jsp page that had the fields you would like, and even call off a remote action from your own page. However, if I route my actions through a security realm, then the requested action will be denied because the current user is not logged in. Or.. If the would be hacker is actualy a valid user on the system and has a username/passsword, and he trys send his own page (along with additional fields) it will still be caught by the secuirty realm. The danger would exist if either form fields, or query string parameters were being used as an action flag. If the view, update, add, delete are different actions, then the user will be required to have a valid login before the action will even be executed. Pete Jeff Trent wrote: No, I can write a form locaally and have the action run on your server... - Original Message - From: Peter Alfors [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 1:56 PM Subject: Re: Potential Security Flaw in Struts MVC Wouldn't the hacker have to get the new form class into the classpath of the server since all of the code runs server side? Jeff Trent wrote: 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 begin:vcard n:; x-mozilla-html:FALSE org:BRIMG SRC=http://www.irista.com/logo/irista.gif;BRBRFONT Color=#80FONT SIZE=2BBringing Vision to Your Supply Chain adr:;; version:2.1 end:vcard
RE: Potential Security Flaw in Struts MVC
At 12:17 PM 5/7/2001 -0700, you wrote: Role-Based Action Execution. Add the ability to require the current user to be in a particular security role before they can execute a particular action. I just wanted to pipe in here because we're integrating Struts into our stuff (Slowly!) The Expresso Framework http://www.jcorporate.com/ tackled this problem by creating a DB Security matrix. Each action in the controller is automatically registered with a security table and the admin can declare which user groups can access which action, as well as which permissions to access which database tables. It's done pretty transparently to the programmer. Hopefully, we'll actually have Struts integrated within the next .1 release. [People are building bridge classes as I speak], so maybe the security model in there can help somebody. -Mike
RE: Potential Security Flaw in Struts MVC
I think I must be missing something... I don't see how a user/hacker is going to gain access to the system if one is using security. If you route each request through a security check (realm) then you should be able to determine if the current user has access to the requested page/action. Am I missing something? Not really. Except that a lot of applications may implement a finer level of security for which the realm check is inconvenient. For instance, I've got a query screen on an inventory management app that allows a user to report on transactions for inventory belonging to that user. The administrator can run the query for any user in the system. I don't want two separate screens for this capability. My solution: The form has an Owner field that is only visible for administrative users. The value is submitted as an HTTP request parameter. In order to prevent non- administrative users from submitting this parameter, I simply don't read its value from the HTTP request if the user doesn't have that right. When thinking about security, it's much more important to think in terms of HTTP requests than Struts forms. Assume that the request can contain anything -- legal or not. -- Curt Hagenlocher [EMAIL PROTECTED]
Re: Potential Security Flaw in Struts MVC
A basic problem with most web development is that people arebuilding 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 usefor example one of the authorization and access modules for apache. Then when you create your applicationyou 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 To: [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
Re: Potential Security Flaw in Struts MVC
Either you are misunderstanding Struts, or I am misunderstanding you. Struts will populate your UserForm for you, prior to your UserAction being called. However, it is your responsibility to, within UserAction, copy the values from UserForm to User. Bryan Jeff Trent wrote: 00bd01c0d728$40864960$6401a8c0@PROVIDENCE"> Bryan, This is good advice. However, I thought the beans are populated off of the request outside of the control of my Action class derivation. Therefore, copyProperties() doesn't pertain. - jeff - Original Message - From: BryanField-Elliot To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 1:14 PM Subject: Re: Potential Security Flaw in Struts MVC There is a security risk here as you describe, if (and only if)you are using a generic introspection-based function (like Struts'PropertyUtils.copyBean) to copy the values from the UserForm object to theUser object. There are several ways to avoid this -- 1. Don't put anadmin flag "setter" method in your User class. 2. In UserAction, don't usethe generic bean copy utility -- instead, manually copy the values, excludingthe admin flag. 3. As a smarter alternative to #2, don't use a generic beancopy utility -- instead, write an intelligent copy function in the User class,which "knows" that it's copying FROM a UserForm, TO a User, and therefore,skip the copying of the Admin flag. Bryan Jeff Trentwrote: 002501c0d70b$9df009a0$6401a8c0@PROVIDENCE" type="cite"> 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
Re: Potential Security Flaw in Struts MVC
True, the security realm validates if the request is legal. However, if the uderlying model objects are shared (User and UserForm objects in my example) for both admin and user level forms, then the request could be manipulated to set other fields beyond what was exposed for the normal user because struts takes each name, value pair in the request and calls the appropriate setter in the form for that name. Listen, it doesn't really matter. Its highly unlikely anybody can exploit this so I'm going to drop the issue. I don't want to appear to be a flame here. - jeff - Original Message - From: Peter Alfors [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 4:14 PM Subject: Re: Potential Security Flaw in Struts MVC Sure. You could create a jsp page that had the fields you would like, and even call off a remote action from your own page. However, if I route my actions through a security realm, then the requested action will be denied because the current user is not logged in. Or.. If the would be hacker is actualy a valid user on the system and has a username/passsword, and he trys send his own page (along with additional fields) it will still be caught by the secuirty realm. The danger would exist if either form fields, or query string parameters were being used as an action flag. If the view, update, add, delete are different actions, then the user will be required to have a valid login before the action will even be executed. Pete Jeff Trent wrote: No, I can write a form locaally and have the action run on your server... - Original Message - From: Peter Alfors [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 1:56 PM Subject: Re: Potential Security Flaw in Struts MVC Wouldn't the hacker have to get the new form class into the classpath of the server since all of the code runs server side? Jeff Trent wrote: 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
Re: Potential Security Flaw in Struts MVC
We are doing something very similar. We are using the jaas security to map each action to a permission. This way, each user is mapped to the actions that he/she is allowed to perform. Each request is routed through a security check to verify that the currently logged in user has permissions to this action. Pete Michael Rimov wrote: At 12:17 PM 5/7/2001 -0700, you wrote: Role-Based Action Execution. Add the ability to require the current user to be in a particular security role before they can execute a particular action. I just wanted to pipe in here because we're integrating Struts into our stuff (Slowly!) The Expresso Framework http://www.jcorporate.com/ tackled this problem by creating a DB Security matrix. Each action in the controller is automatically registered with a security table and the admin can declare which user groups can access which action, as well as which permissions to access which database tables. It's done pretty transparently to the programmer. Hopefully, we'll actually have Struts integrated within the next .1 release. [People are building bridge classes as I speak], so maybe the security model in there can help somebody. -Mike begin:vcard n:; x-mozilla-html:FALSE org:BRIMG SRC=http://www.irista.com/logo/irista.gif;BRBRFONT Color=#80FONT SIZE=2BBringing Vision to Your Supply Chain adr:;; version:2.1 end:vcard
Re: Potential Security Flaw in Struts MVC
Ah, this maybe a problem in the way I've adapted
Struts. I reflect all UserForm method calls directly into the contained
User object owned by the UserForm. So for instance, I have
public class UserForm extends
ActionsForm
{
protected User
user;
...
public String
getName()
{
return
user.getName();
}
public void setName(String
name)
{
user.setName(name);
}
...
}
Now can you begin to see my original concern?
Maybe I need to separate the model from the form a little more than what I
have.
- jeff
- Original Message -
From:
Bryan
Field-Elliot
To: [EMAIL PROTECTED]
Sent: Monday, May 07, 2001 4:38 PM
Subject: Re: Potential Security Flaw in
Struts MVC
Either you are misunderstanding Struts, or I am
misunderstanding you.Struts will populate your UserForm for you, prior
to your UserAction being called. However, it is your responsibility to, within
UserAction, copy the values from UserForm to
User.BryanJeff Trent wrote:
00bd01c0d728$40864960$6401a8c0@PROVIDENCE"
type="cite">
Bryan,
This is good advice. However, I thought
the beans are populated off of the request outside of the control of my
Action class derivation. Therefore, copyProperties() doesn't
pertain.
- jeff
-
Original Message -
From: Bryan
Field-Elliot
To:
[EMAIL PROTECTED]
Sent:
Monday, May 07, 2001 1:14 PM
Subject:
Re: Potential Security Flaw in Struts MVC
There is a security risk here as you describe, if (and only
if) you are using a generic introspection-based function (like Struts'
PropertyUtils.copyBean) to copy the values from the UserForm object to the
User object. There are several ways to avoid this --1. Don't put
an admin flag "setter" method in your User class.2. In UserAction,
don't use the generic bean copy utility -- instead, manually copy the
values, excluding the admin flag.3. As a smarter alternative to #2,
don't use a generic bean copy utility -- instead, write an intelligent
copy function in the User class, which "knows" that it's copying FROM a
UserForm, TO a User, and therefore, skip the copying of the Admin
flag.BryanJeff Trent wrote:
002501c0d70b$9df009a0$6401a8c0@PROVIDENCE"
type="cite">
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
RE: Potential Security Flaw in Struts MVC
I want to second Martin's opinion. Secrurity (e.g, authentication and authorization) should be outside of the application, if possible. In our company, we are using Entrust's getAccess in combination with Apache. It can easily protect resources (most likely defined by URL) after the application is developed. That being said, to protect on a more granular level (e.g., certain fields should be read only, or certain memus should not show up) still seems to be part of the application. But I do think it is the right direction. Shunhui -Original Message-From: Martin Duffy [mailto:[EMAIL PROTECTED]]Sent: Monday, May 07, 2001 5:27 AMTo: [EMAIL PROTECTED]Subject: Re: Potential Security Flaw in Struts MVC A basic problem with most web development is that people arebuilding 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 usefor example one of the authorization and access modules for apache. Then when you create your applicationyou 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 To: [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
Re: Potential Security Flaw in Struts MVC
Jeff Trent wrote: True, the security realm validates if the request is legal. However, if the uderlying model objects are shared (User and UserForm objects in my example) for both admin and user level forms, then the request could be manipulated to set other fields beyond what was exposed for the normal user because struts takes each name, value pair in the request and calls the appropriate setter in the form for that name. Listen, it doesn't really matter. Its highly unlikely anybody can exploit this so I'm going to drop the issue. I don't want to appear to be a flame here. Actually, I just wanted to make sure that I understood what the possible security hole was. :) Now I understand what you are doing. We haven't run across this because we haven't implemented any admin screens that differ from user screens (yet). Im glad you brought the issue up, because it is something that could be overlooked. :) - jeff - Original Message - From: Peter Alfors [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 4:14 PM Subject: Re: Potential Security Flaw in Struts MVC Sure. You could create a jsp page that had the fields you would like, and even call off a remote action from your own page. However, if I route my actions through a security realm, then the requested action will be denied because the current user is not logged in. Or.. If the would be hacker is actualy a valid user on the system and has a username/passsword, and he trys send his own page (along with additional fields) it will still be caught by the secuirty realm. The danger would exist if either form fields, or query string parameters were being used as an action flag. If the view, update, add, delete are different actions, then the user will be required to have a valid login before the action will even be executed. Pete Jeff Trent wrote: No, I can write a form locaally and have the action run on your server... - Original Message - From: Peter Alfors [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 1:56 PM Subject: Re: Potential Security Flaw in Struts MVC Wouldn't the hacker have to get the new form class into the classpath of the server since all of the code runs server side? Jeff Trent wrote: 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
Re: Potential Security Flaw in Struts MVC
I think I must be missing something... I don't see how a user/hacker is going to gain access to the system if one is using security. hackers arent always from the outside, you also have to protect yourself from legitimate users, who could try to force the system. Not every secure user is trust worthy user... Casey Kochmer [EMAIL PROTECTED] _ Get your FREE download of MSN Explorer at http://explorer.msn.com
Re: Potential Security Flaw in Struts MVC
Yes I think that's a problem; interesting that you would do it that way,
I never saw it from that perspective. But I believe the intent of Struts
(e.g. the examples, etc) is that your ActionForms are really just forms --
conduits for moving field values between HTML forms and Java primitives.
They shouldn't really involve themselves with your model at all. Keep your
model interactions in your Action perform()'s.
Other comments I've seen in this vein are with regards to validation. In
your ActionForms' validate methods, you should validate the data for basic
type-correctness (e.g. did the user really enter a date in the date field?).
But for business-model validation, save it for the Action class (e.g. did
the user enter a date not already booked?). This is sort of a two-phase validation
approach which separates basic validation logic from business model logic.
Bryan
Jeff Trent wrote:
018501c0d739$fa597bd0$6401a8c0@PROVIDENCE">
Ah, this maybe a problem in the way I've
adapted Struts. I reflect all UserForm method calls directly into the contained
User object owned by the UserForm. So for instance, I have
public class UserForm extends ActionsForm
{
protected User user;
...
public String getName()
{
return user.getName();
}
public void setName(String name)
{
user.setName(name);
}
...
}
Now can you begin to see my original concern?
Maybe I need to separate the model from the form a little more than what
I have.
- jeff
- Original Message -
From:
BryanField-Elliot
To:
[EMAIL PROTECTED]
Sent: Monday, May 07, 2001 4:38 PM
Subject: Re: Potential Security Flaw in Struts MVC
Either you are misunderstanding Struts, or I ammisunderstanding you.
Struts will populate your UserForm for you, priorto your UserAction being
called. However, it is your responsibility to, withinUserAction, copy
the values from UserForm toUser.
Bryan
Jeff Trent wrote:
00bd01c0d728$40864960$6401a8c0@PROVIDENCE" type="cite">
Bryan,
This is good advice. However, I thought
the beans are populated off of the request outside of the control of
my Action class derivation. Therefore, copyProperties() doesn't
pertain.
- jeff
-Original Message -
From:
BryanField-Elliot
To:
[EMAIL PROTECTED]
Sent:Monday, May 07, 2001 1:14 PM
Subject: Re: Potential Security Flaw in Struts MVC
There is a security risk here as you describe, if (and onlyif) you
are using a generic introspection-based function (like Struts'PropertyUtils.copyBean)
to copy the values from the UserForm object to theUser object. There
are several ways to avoid this --
1. Don't putan admin flag "setter" method in your User class.
2. In UserAction,don't use the generic bean copy utility -- instead,
manually copy thevalues, excluding the admin flag.
3. As a smarter alternative to #2,don't use a generic bean copy utility
-- instead, write an intelligentcopy function in the User class,
which "knows" that it's copying FROM aUserForm, TO a User, and therefore,
skip the copying of the Adminflag.
Bryan
Jeff Trent wrote:
002501c0d70b$9df009a0$6401a8c0@PROVIDENCE" type="cite">
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 s
RE: Potential Security Flaw in Struts MVC
It's
fine to nest a JavaBean in an ActionForm if that bean is just a transport object
that is passed to EJBs but it probably isn't a good idea to nest your model
objects directly in the form.
If you
are going to nest a javabean in a form you don't need the getName()/setName()
methods, you can just have a getUser()/setUser() and reference the properties of
the nested bean by labeling the field in your jsp as
"user.name".
Hal
-Original Message-From: Jeff Trent
[mailto:[EMAIL PROTECTED]]Sent: Monday, May 07, 2001 5:09
PMTo: [EMAIL PROTECTED]Subject: Re:
Potential Security Flaw in Struts MVC
Ah, this maybe a problem in the way I've adapted
Struts. I reflect all UserForm method calls directly into the contained
User object owned by the UserForm. So for instance, I have
public class UserForm extends
ActionsForm
{
protected User
user;
...
public String
getName()
{
return
user.getName();
}
public void setName(String
name)
{
user.setName(name);
}
...
}
Now can you begin to see my original
concern? Maybe I need to separate the model from the form a little more
than what I have.
- jeff
- Original Message -
From:
Bryan
Field-Elliot
To: [EMAIL PROTECTED]
Sent: Monday, May 07, 2001 4:38
PM
Subject: Re: Potential Security Flaw in
Struts MVC
Either you are misunderstanding Struts, or I am
misunderstanding you.Struts will populate your UserForm for you,
prior to your UserAction being called. However, it is your responsibility
to, within UserAction, copy the values from UserForm to
User.BryanJeff Trent wrote:
00bd01c0d728$40864960$6401a8c0@PROVIDENCE">
Bryan,
This is good advice. However, I thought
the beans are populated off of the request outside of the control of my
Action class derivation. Therefore, copyProperties() doesn't
pertain.
- jeff
-
Original Message -
From:
Bryan Field-Elliot
To:
[EMAIL PROTECTED]
Sent:
Monday, May 07, 2001 1:14 PM
Subject:
Re: Potential Security Flaw in Struts MVC
There is a security risk here as you describe, if (and
only if) you are using a generic introspection-based function (like
Struts' PropertyUtils.copyBean) to copy the values from the UserForm
object to the User object. There are several ways to avoid this
--1. Don't put an admin flag "setter" method in your User
class.2. In UserAction, don't use the generic bean copy utility --
instead, manually copy the values, excluding the admin flag.3. As a
smarter alternative to #2, don't use a generic bean copy utility --
instead, write an intelligent copy function in the User class, which
"knows" that it's copying FROM a UserForm, TO a User, and therefore,
skip the copying of the Admin flag.BryanJeff
Trent wrote:
002501c0d70b$9df009a0$6401a8c0@PROVIDENCE">
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. Unl
RE: Potential Security Flaw in Struts MVC
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
Re: Potential Security Flaw in Struts MVC
Feel free. If you would like to document it, I'd be happy to find a place for it in the users guide. Calvin Yu wrote: I think that this potential exploit should probably be thoroughly documented, along with potential workarounds. Last thing we want is to have Struts being tagged as being unsecure.
Re: Potential Security Flaw in Struts MVC
This is open source. Anyone is welcome to jump in and join the management by submitting code. Jeff Trent wrote: Therefore, if I haven't reached my quota today, I'd like to suggest to management that there is a bean property (or something) that results in form fields being propogated accross multiple pages of my request/form and are managed using hidden variables alone. This would be an alternative to using session scope but would accomplish the same thing. Again, all comments are welcome...
Re: Potential Security Flaw in Struts MVC
Feel free to submit some code. Jeff Trent wrote: I like it! I second this request totally!
Re: Potential Security Flaw in Struts MVC
Ted, I wish I had time. Now that I have three kids I can't spend any spare cycle(s) on anything but changing diapers! - Original Message - From: Ted Husted [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 7:46 PM Subject: Re: Potential Security Flaw in Struts MVC This is open source. Anyone is welcome to jump in and join the management by submitting code. Jeff Trent wrote: Therefore, if I haven't reached my quota today, I'd like to suggest to management that there is a bean property (or something) that results in form fields being propogated accross multiple pages of my request/form and are managed using hidden variables alone. This would be an alternative to using session scope but would accomplish the same thing. Again, all comments are welcome...
RE: Potential Security Flaw in Struts MVC
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
Re: Potential Security Flaw in Struts MVC
If you use something like one of the mod_ldap implementations for apache the admin would have his password in the ldap directory. I also am pretty sure that there is a auth module for apache that uses a database like MySQL. In that case the admins id and password would be in the database. So when he changes his password he does not have to restart the application. The apache modules would respect the fact that he authenticated to either the directory or the database and authorize access to the application. In either case the authorization and access control for individual URL's for the web server (and your application) would be regulated by the apache module and not by your application. In my estimation, building security mechanisms into Struts will be a slippery slope downhill. It is something that is best suited for the existing apache authorization and access modules or other external security mechanisms. I can see that it would be a good thing for creating a project to extend some of the existing apache auth and access modules to incorporate protecting servlets and EJB's. A number of them already can control authorization and access control for web servers and individual URLs. If you go to the Apache module registry and do a search on auth, ldap or I think access you will find quite a few modules that can probably suit your needs. There is one particular mod_ldap that I think is better than the others but there are quite a few to choose from and I think that many would fulfill most peoples needs. If you are using either a database or a directory you can also use them to supply user and group attributes to control the access to different functions in your application by checking the attributes for the user or group and displaying or not displaying something like a button or menu selection in the page. You could use the LDAP or DB taglibs for doing things like this in conjunction with the external security mechanism that would be protecting the access to the URLs. But the actual protection of the URLs should be external to the app. I would say look elsewhere for security for your applications and do not in build it into the Struts framework. . - Original Message - From: Manabendra Sarkar [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: 'Martin Duffy' [EMAIL PROTECTED] Sent: Tuesday, May 08, 2001 8:08 AM Subject: RE: Potential Security Flaw in Struts MVC 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
