I don't think it would be a global fix for all forms, but one way to fix the
problem would be to use an interceptor that would make your user object
available to your view using a context parameter rather than an action
attribute. I.e. something like:
public class UserInterceptor extends AbstractInterceptor {
/**
* Intercept the Action and Inject the User if it's available
*
* @param invocation The Action Invocation
* @return The Action Result name
*/
@Override
public String intercept (ActionInvocation invocation) throws Exception {
User user = (User)ses.get("user");
if(user != null) {
invocation.getStack().getContext().put("user",user);
}
return invocation.invoke();
} //intercept
} //*UserInterceptor
this makes the user available to your JSP (or freemarker or velocity) as
<s:property value="%{#user.email}"/> but prevents it from being accessed
through form parameters.
(*Chris*)
On Wed, Dec 15, 2010 at 8:39 AM, Altenhof, David Aron <[email protected]>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/[email protected]
>
> ... and it works. The email will become [email protected]
>
> 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: [email protected]
> For additional commands, e-mail: [email protected]
>
>
