[
https://issues.apache.org/jira/browse/WW-5624?focusedWorklogId=1013942&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1013942
]
ASF GitHub Bot logged work on WW-5624:
--------------------------------------
Author: ASF GitHub Bot
Created on: 08/Apr/26 09:08
Start Date: 08/Apr/26 09:08
Worklog Time Spent: 10m
Work Description: lukaszlenart commented on PR #1652:
URL: https://github.com/apache/struts/pull/1652#issuecomment-4205113127
Thanks for reporting this. The issue in the REST plugin looks valid:
`JacksonJsonHandler.toObject()` currently bypasses the `ParametersInterceptor`
checks for `@StrutsParameter`.
That said, I don't think this fix is sufficient as-is. In Struts,
`@StrutsParameter` support is not only a check for an annotated setter. The
core `ParametersInterceptor` logic also enforces nesting depth and related
authorization semantics. This change currently adds only a setter-level
annotation check, so it does not fully match existing Struts behavior.
My main concern is that once an annotated top-level setter is accepted,
`mapper.convertValue(...)` can still populate the full nested subtree of a
complex object without enforcing Struts depth rules. So this still looks too
permissive for nested binding cases. It also changes the current Jackson update
path, which may affect existing merge/deserialization behavior beyond the
security fix itself.
I think the right direction is to align the REST plugin with the shared
parameter-binding authorization rules used by `ParametersInterceptor`, instead
of implementing a local setter-only check.
Issue Time Tracking
-------------------
Worklog Id: (was: 1013942)
Time Spent: 20m (was: 10m)
> Request body population bypasses @StrutsParameter contract outside
> ParametersInterceptor
> ----------------------------------------------------------------------------------------
>
> Key: WW-5624
> URL: https://issues.apache.org/jira/browse/WW-5624
> Project: Struts 2
> Issue Type: Bug
> Components: Plugin - JSON, Plugin - REST
> Affects Versions: 7.1.1
> Reporter: Tran Quac
> Priority: Major
> Fix For: 7.2.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h2. Summary
> {{@StrutsParameter}} enforcement is currently implemented in
> {{ParametersInterceptor}} for standard request parameter binding, but
> request-body based binders in some plugins bypass that authorization model
> and populate action/model objects directly.
> This creates inconsistent behavior between URL/form parameters and JSON/XML
> request bodies, and may allow mass assignment of properties that would
> normally be rejected by {{ParametersInterceptor}}.
> h2. Affected areas currently identified
> * JSON plugin:
> {{JSONPopulator.populateObject()}} sets properties via direct reflection and
> does not follow the full {{@StrutsParameter}} authorization rules.
> * REST plugin:
> {{JacksonJsonHandler.toObject()}} updates target objects directly via Jackson
> and does not follow the full {{@StrutsParameter}} authorization rules.
> h2. Problem scope
> The issue is broader than checking whether a setter is annotated. The current
> core contract in {{ParametersInterceptor}} also includes:
> * permitted nesting depth
> * authorization based on the exposed root member
> * ModelDriven handling
> * transition mode semantics
> * related allowlisting behavior
> Any request-body binding implementation should align with that same contract,
> otherwise Struts applies different security rules depending on how input
> reaches the action/model.
> h2. Expected direction
> Instead of implementing separate partial checks in each plugin, Struts should
> reuse or extract the shared parameter-binding authorization logic from
> {{ParametersInterceptor}} and apply it consistently across request-body
> binders.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
