[
https://issues.apache.org/jira/browse/WW-5624?focusedWorklogId=1014608&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1014608
]
ASF GitHub Bot logged work on WW-5624:
--------------------------------------
Author: ASF GitHub Bot
Created on: 10/Apr/26 19:20
Start Date: 10/Apr/26 19:20
Worklog Time Spent: 10m
Work Description: lukaszlenart commented on PR #1657:
URL: https://github.com/apache/struts/pull/1657#issuecomment-4226192630
Thanks, this is clearly closer to the intended direction and it addresses
several of the earlier concerns. I still see one blocking parity gap with
`ParametersInterceptor`: collection/indexed paths.
In core, authorization depth is based on the full parameter path, e.g.
`publicPojoListDepthOne[0].key` must be rejected while
`publicPojoListDepthTwo[0].key` is accepted. The updated JSON list recursion
appears to reuse the same prefix for list items instead of synthesizing an
indexed path, which undercounts nesting and can make list element binding more
permissive than `ParametersInterceptor`.
I also still have the same concern for the REST side where `Collection` /
`Map` / arrays are copied as-is, and for the fallback path that does direct
deserialization followed by top-level scrubbing only. Those paths still do not
look fully equivalent to the core nested authorization model.
Issue Time Tracking
-------------------
Worklog Id: (was: 1014608)
Time Spent: 2h (was: 1h 50m)
> 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: 2h
> 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)
