----- Original Message ----- From: "Michal Mosiewicz" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, February 24, 2004 11:02 PM Subject: Re: [OS-webwork] Security again
> > ----- Original Message ----- > From: "Patrick Lightbody" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, February 24, 2004 1:06 AM > Subject: RE: [OS-webwork] Security again > > > > Well, I'm not sure if you know, but method calls are disabled during > > ParametersInterceptor, so I think that went a long way. > > I've seen that. But it doesn't solve all issues. The simplest case: I've got > some Actions to work with "Account" beans. Account bean have some updatable > properties, but also there are are properties that cannot be changed unless > special condition is met like for example "balance" property. So the problem > is that I have to put some restrictions on what properties can be set. It's > so practical to attach this bean to action. But becouse of this security > issues I don't use webwork's own ParametersInterceptor, and I created my own > that is able to filter properties. > I agree that it would be very useful to have a way of controlling what properties can be set on the beans. I have been thinking about a solution similar to the regexp you describe. But like you, I do not feel very comfortable with it and at the moment I just implement NoParameters when security is important and then set the allowed parameters manually in the code. > > I like your idea of utilizing AbstractUITag to help figure out what are > > "acceptable" names. We could, in the future, intimately tie the two > > together to do this dynamically I suppose (though that would alienate > > people not using the UI tag library). > > Of course - that would be configurable. In fact - even I don't use UI tags > all the time. But that's just would be a useful feature. Currently I'm doing > something very similiar but at design stage - to make sure that I configured > my parameter firewall correctly, I use ant script to parse forms and find > what names they contain. However it doesn't work nicely if names are > generated at runtime. So - it's tempting to patch something.... > The UI tag sounds good, and if/when you do not use the ui tags we could add another tag to be used for the purpose of registering/outputting the parameter name. For example ww:pname or ww:field. I think there are some problems that need to be solved though: 1. Do we need special handling for pages with multiple forms on them? The tag should perhaps be used inside the scope of a form tag so that the names are linked together in some way. 2. Where should the allowed parameter names be stored? In the session perhaps? But that may "burden" the session with much updates and data. But if we store them in some application context we loose the failover ability of the session that some applications want/need. Perhaps it should be configurable where to store the parameters. Another option could perhaps be to store the parameters in the form as a hidden field with a md5 MAC so that they cannot be modified without WW noticing. This could also be used to handle unmodifiable hidden values so we would get that functionality for free if this solution was chosen. 3. The parameter registration must be possible for links as well. Perhaps the url tag should have an attribute for this. 4. When do we clear stored parameters? When they are used of course, but what about when we have several forms and only one is submitted? What about when we have many links, where each link have added parameters? A link could launch a popup window with new forms and links, while the original window remains, so we should not delete the parameters then. We could also the case where there are several frames where links remain for a long time. How do we solve this in a good way? Any thoughts on this? I have a vague memory of Rickard Öberg suggesting a solution they used in his CMS were all generated links were stored "somewhere", when we discussed the token implementation about a year ago. I guess similar issues must be handled then. Do you have any ideas about this Rickard? Best regards, Dick Zetterberg ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
