[
https://issues.apache.org/jira/browse/WW-5624?focusedWorklogId=1013941&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1013941
]
ASF GitHub Bot logged work on WW-5624:
--------------------------------------
Author: ASF GitHub Bot
Created on: 08/Apr/26 09:07
Start Date: 08/Apr/26 09:07
Worklog Time Spent: 10m
Work Description: lukaszlenart commented on PR #1651:
URL: https://github.com/apache/struts/pull/1651#issuecomment-4205109223
Thanks for reporting this. The issue in the JSON plugin looks valid:
`JSONPopulator.populateObject()` 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 `JSONPopulator` recursively populates nested beans,
collections, arrays, and maps. Requiring `@StrutsParameter` on every nested
setter would be stricter than current Struts semantics, where authorization is
based on the exposed root member and the permitted depth. That could break
valid nested binding scenarios while still not aligning fully with the core
parameter-binding contract.
I think the right direction is to align the JSON 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: 1013941)
Remaining Estimate: 0h
Time Spent: 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: 10m
> 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)
