[
https://issues.apache.org/jira/browse/WW-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13731891#comment-13731891
]
Rene Gielen commented on WW-4171:
---------------------------------
It only makes sense to sanitize before setting the value, since the annotation
information will be lost when the passed as parameter to an API call.
Thus, there are basically two options:
1. make Sanitizing a delegate call in ParametersInterceptor
2. break up steps to separate concerns
Regarding 2, combined with an earlier (less elaborate) idea: a possible
workflow, each step implemented by interceptors, could look like this
1. prepare naked parameter map, mapping request key-value-pairs to simple Map
2. sanitize parameter keys, as strict as we do now in ParametersInterceptor;
replace map / map keys / entries from step one so that paramter map now only
contains sanitized key values
3. sanitize parameter values based on evaluating keys against the stack,
introspect candidate properties; if a candidate property (or its class!)
contains the @Sanitize annotation, sanitize value based on this directive;
replace map / map values / entries from step two so that paramter map now only
contains sanitized keys and values. Important: only the map is sanitized, no
model property in the stack is touched yet!
4. set parameters on the model, based on the sanitized map. Basically this is a
more lightweight version of nowadays ParametersInterceptor
Point 4 is interesting, since now ParametersInterceptor would only serve a
single concern. Also, paramPrepareParam would get more lightweight since the
already sanitized parameter map would be used for both ParametersInterceptor
calls. No need to sanitize two times then
> getText methods are not documented as evaluating OGNL
> -----------------------------------------------------
>
> Key: WW-4171
> URL: https://issues.apache.org/jira/browse/WW-4171
> Project: Struts 2
> Issue Type: Improvement
> Components: Documentation
> Affects Versions: 2.3.15.1
> Reporter: Coverity Security Research Laboratory
> Assignee: Lukasz Lenart
> Priority: Minor
> Labels: security
> Fix For: 2.3.16
>
>
> The methods below evaluate OGNL as their first parameter. However they are
> not documented as evaluating OGNL. We have observed this occurring in one
> project and are contacting the affected vendors.
> com.opensymphony.xwork2.TextProviderSupport.getText(String, String[])
> com.opensymphony.xwork2.TextProviderSupport.getText(String, List<?>)
> com.opensymphony.xwork2.TextProviderSupport.getText(String)
> These methods are then used by ActionSupport (via its getText methods). None
> of these methods are documented as evaluating OGNL either.
> This issue is recommending that all of these methods are documented as
> evaluating OGNL since this may come as a surprise to some developers.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
