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 <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=newem...@address.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
>
>

Reply via email to