Hi All, adding just one note to what Marcus already said, will You be able to update your whitelist every time User class (or any other viewable) gains new field? And again *ViewAction is for view only - it should be technically impossible to change viewed object state. One simple way to do it is loading this object in execute method.
Best greetings, Paweł Wielgus. 2010/12/18 Marcus Bond <mar...@marcusbond.me.uk>: > David, didn't your original post say that this is an action that loads an > object to display it rather than to modify it? In which case I'm not sure > why you even need to use Preparable (as I'm guessing it's during prepare > that the instance is initialised which makes it available for struts to > populate during the second params setting). At a guess you're setting an id > in the initial params phase which then is used to load the instance? Why not > just load it during execute (or whatever other method is being called by the > action mapping) so it isn't there for any params to be applied earlier? > > Regards, > Marcus > > On 17/12/2010 20:02, Altenhof, David Aron wrote: >> >> One approach I've through of is to create an interceptor that would parse >> through your -validation.xml (assuming one uses them) and then only allow >> parameters that have an associated validator. This would actually serve two >> goals: 1) Preventing parameter fiddling 2) Mandating the wise practice of >> validating all incoming data. >> >> Now if I could only find a few spare cycles to work on it... >> >> -David >> >> -----Original Message----- >> From: Chris Pratt [mailto:thechrispr...@gmail.com] >> Sent: Friday, December 17, 2010 1:08 PM >> To: Struts Users Mailing List >> Subject: Re: Parameter manipulation >> >> Maybe if the OP moves the bean creation out of the prepare() method (so >> the bean isn't available during parameter injection) and then retrieves it >> at the start of validate() or execute() that might solve the problem. >> (*Chris*) >> >> On Fri, Dec 17, 2010 at 10:05 AM, Chris >> Pratt<thechrispr...@gmail.com>wrote: >> >>> If the bean already exists, struts doesn't have to set it. It just >>> has to modify the retrieved bean. >>> (*Chris*) >>> >>> >>> On Fri, Dec 17, 2010 at 9:48 AM,<stanl...@gmail.com> wrote: >>> >>>> I agree S2 will create the bean (if null) but it can't set a property >>>> that is private and has no accessible setter method. >>>> >>>> P.S. What am I missing here? >>>> >>>> Scott >>>> >>>> On Fri, Dec 17, 2010 at 11:45 AM, Maurizio Cucchiara< >>>> maurizio.cucchi...@gmail.com> wrote: >>>> >>>>> This happens because bean is null, otherwise struts will populate. >>>>> >>>>> 2010/12/17<stanl...@gmail.com>: >>>>>> >>>>>> Guys -- >>>>>> >>>>>> If the action has no setter and the property is private, S2 will >>>>>> not populate it. >>>>>> >>>>>> Scott >>>>>> >>>>>> On Fri, Dec 17, 2010 at 11:10 AM, Maurizio Cucchiara< >>>>>> maurizio.cucchi...@gmail.com> wrote: >>>>>> >>>>>>> David, >>>>>>> I get your point. >>>>>>> >>>>>>> Scott is right, you could overwrite PI or maybe write your >>>>>>> custom interceptor (though I think you should consider to file >>>>>>> an issue on JIRA). >>>>>>> Maybe it would use java annotations to hide/expose fields, or >>>>>>> alternately it could behave as you supposed (expose only field >>>>>>> with write accessors). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2010/12/17 Altenhof, David Aron<dalte...@iupui.edu>: >>>>>>>> >>>>>>>> The model objects are initialized in prepare() ... other >>>>>>>> techniques >>>>> >>>>> just >>>>>>> >>>>>>> aren't as practical for our application. >>>>>>>> >>>>>>>> I'm just going to keep doing lots of whitelisting with >>>>>>> >>>>>>> ParameterNameAware... >>>>>>>> >>>>>>>> -David >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Steven Yang [mailto:kenshin...@gmail.com] >>>>>>>> Sent: Friday, December 17, 2010 1:10 AM >>>>>>>> To: Struts Users Mailing List >>>>>>>> Subject: Re: Parameter manipulation >>>>>>>> >>>>>>>> is your user object initialized when the param interceptor is run? >>>>>>>> >>>>>>>> here i might be wrong, but what i know is if your object is >>>>> >>>>> initialized >>>>>>> >>>>>>> then Struts or OGNL will call getUser().setEmail(...) otherwise >>>> >>>> create a >>>>> >>>>> new >>>>>>> >>>>>>> User then setEmail then setUser then the second case should fail >>>>>>> for >>>> >>>> you >>>>>>>> >>>>>>>> again, i might be wrong on the behavior >>>>>>>> >>>>>>>> On Thu, Dec 16, 2010 at 12:39 AM, Altenhof, David Aron >>>>>>>> <dalte...@iupui.edu>wrote: >>>>>>>> >>>>>>>>> I've been getting more and more concerned about the >>>>>>>>> possibility of parameter manipulation attacks with Struts2. >>>>>>>>> I've started doing >>>>> >>>>> strict >>>>>>>>> >>>>>>>>> whitelists using the ParameterNameAware interface on all of >>>>>>>>> my >>>> >>>> forms >>>>>>> >>>>>>> pages. >>>>>>>>> >>>>>>>>> However, today I tried to code a "display-only" page that >>>>>>>>> shows information about a particular user. I thought that by >>>>>>>>> simply >>>>> >>>>> creating >>>>>>>>> >>>>>>>>> a getter and no setter, it would be impossible to inject >>>> >>>> parameters. >>>>>>>>> >>>>>>>>> For example, my action only contains the following getter for >>>>>>>>> a >>>> >>>> JPA >>>>>>> >>>>>>> model object: >>>>>>>>> >>>>>>>>> public User getUser() { >>>>>>>>> return user; >>>>>>>>> } >>>>>>>>> >>>>>>>>> However, by sending a simple query parameter, it is *still* >>>> >>>> possible >>>>>>>>> >>>>>>>>> to change values in user. For example, you can send: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>> http://localhost:8080/MySite/userdisplay.action?user.email=newemail >>>>> @ad >>>>>>>>> >>>>>>>>> dress.com >>>>>>>>> >>>>>>>>> ... and it works. The email will become newem...@address.com >>>>>>>>> >>>>>>>>> Is there any way to shut this down other than whitelisting >>>>>>>>> every single action in your site using ParameterNameAware? >>>>>>>>> (Or simply >>>> >>>> never >>>>>>>>> >>>>>>>>> put model objects on your stack?) This is getting frustrating! >>>>>>>>> >>>>>>>>> -David >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>> --------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >>>>>>>>> For additional commands, e-mail: user-h...@struts.apache.org >>>>>>>>> >>>>>>>>> >>>>>>>> >>>> --------------------------------------------------------------------- >>>>>>>> >>>>>>>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >>>>>>>> For additional commands, e-mail: user-h...@struts.apache.org >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Maurizio Cucchiara >>>>>>> >>>>>>> ---------------------------------------------------------------- >>>>>>> ----- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >>>>>>> For additional commands, e-mail: user-h...@struts.apache.org >>>>>>> >>>>>>> >>>>> >>>>> >>>>> -- >>>>> Maurizio Cucchiara >>>>> >>>>> ------------------------------------------------------------------- >>>>> -- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >>>>> For additional commands, e-mail: user-h...@struts.apache.org >>>>> >>>>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >> For additional commands, e-mail: user-h...@struts.apache.org >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
