struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lukasz Lenart (JIRA)" <>
Subject [jira] [Commented] (WW-4486) Default parameter exclusions blocking legitimate values
Date Wed, 08 Apr 2015 12:10:12 GMT


Lukasz Lenart commented on WW-4486:

It was introduced here
as a part of those changes

Basically there are places in Struts where value can be double-evaluated - when it's passed
to a Struts based app (evaluated and set) and when the app is using the value to display it
on UI (re-evaluated again and displayed). It cannot be resolved in other way than blocking
such values or by re-writing those parts of the Struts framework which won't happen before

> Default parameter exclusions blocking legitimate values
> -------------------------------------------------------
>                 Key: WW-4486
>                 URL:
>             Project: Struts 2
>          Issue Type: Bug
>          Components: Core Interceptors
>    Affects Versions: 2.3.20
>            Reporter: Jasper Rosenberg
>            Priority: Critical
>             Fix For: 2.5
> In ParametersInterceptor.setParameters(), when building acceptableParameters(), it applies
the check isAcceptableValue not just just to the parameter name, but also to the parameter
value.  This is a huge problem because the default excludedPatterns include phrases that will
come up in normal user form submissions.  
> For example, the way I discovered this is that one pattern is "(.*\.|^|.*|\[('|"))\bclass(\.|('|")]|\[).*"
> We are a car site, so when a user tried to post a message about a Mercedes M class: "That's
M class. You asked for G class, different beast!"
> The "class." at the end of the first sentence was rejected and so their post failed.
> What is the reason for applying the exclusion patterns wholesale to the parameter value?
 Is it even necessary at all, or is there some kind of escape character that normally tells
ognl to evaluate an expression in the value, in which case we could check for exclusion pattern
matches just within those?
> As it is though, the current solution is going to cause some occasional very peculiar
behavior for developers.  Not sure if this should actually be a blocker bug since the only
reasonable workaround seems to be to hack the ParametersInterceptor locally (since one shouldn't
remove the exclusion patterns in general).

This message was sent by Atlassian JIRA

View raw message