[
https://issues.apache.org/jira/browse/WW-5710?focusedWorklogId=1041216&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1041216
]
ASF GitHub Bot logged work on WW-5710:
--------------------------------------
Author: ASF GitHub Bot
Created on: 13/Sep/26 16:43
Start Date: 13/Sep/26 16:43
Worklog Time Spent: 10m
Work Description: lukaszlenart opened a new pull request, #1932:
URL: https://github.com/apache/struts/pull/1932
Fixes [WW-5710](https://issues.apache.org/jira/browse/WW-5710)
Both OGNL channels (`ParametersInterceptor`, `CookieInterceptor`) resolve
the binding target once and use it for the authorization check and the
allowlist priming alike. For a `ModelDriven` action that target is the model —
but since WW-5698 the authorizer may grant a parameter on a member declared on
the **action** itself. `OgnlParameterAllowlister` was still handed the model
only, found no annotation there and primed nothing. With
`struts.allowlist.enable=true` (the default) a correctly annotated nested
property on the action's own class — `@StrutsParameter(depth = 1) getAddress()`
— was authorized and then refused by `SecurityMemberAccess`, with nothing in
the logs pointing at the allowlist.
### Change
- `ParameterAllowlister` gains a `default primeAllowlistForPath(name,
target, action)` that primes the resolved target and, when it differs, the
action too. The interface stays a SAM; custom implementations inherit it. Each
priming is a no-op unless *that* object annotates the root property at
sufficient depth, so the second priming cannot allowlist anything the developer
did not declare — a ModelDriven action now gets exactly what a plain action
always got.
- Both call sites use the three-argument form.
- The allowlister's debug line no longer claims "nested traversal may be
blocked" for one object when another may still prime the path; it names the
object that primed nothing.
### Tests
-
`StrutsParameterAnnotationTest.modelDrivenAction_annotatedNestedPropertyOnAction_allowlisted`
— parameter accepted **and** the nested type lands in `ThreadAllowlist` (RED
on `main`: accepted, allowlist empty).
-
`ParametersInterceptorTest.testModelDrivenAnnotatedNestedPropertyOnActionIsAllowlisted`
— end-to-end through the real OGNL stack with the allowlist enabled; the
action class and model class are seeded the way configuration loading and
`ModelDrivenInterceptor` do, so the nested type is allowlisted by nothing but
the priming under test. RED on `main` with `SecurityMemberAccess` refusing
`Address.setCity` while the model property binds.
-
`CookieInterceptorTest.testNestedCookieOnModelDrivenActionMemberPrimesAllowlist`
— same through the cookie channel, with the real authorizer and allowlister
from the container (RED with the cookie-channel change reverted).
Full `core` suite passes.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1041216)
Remaining Estimate: 0h
Time Spent: 10m
> Allowlist priming targets the ModelDriven model even when the parameter was
> authorised on the action
> ----------------------------------------------------------------------------------------------------
>
> Key: WW-5710
> URL: https://issues.apache.org/jira/browse/WW-5710
> Project: Struts 2
> Issue Type: Task
> Components: Core
> Reporter: Lukasz Lenart
> Priority: Major
> Fix For: 7.4.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{ParametersInterceptor.isParameterAnnotatedAndAllowlist}} resolves the
> binding target once and uses it for both steps:
> Object target = parameterAuthorizer.resolveTarget(action);
> if (!parameterAuthorizer.isAuthorized(name, target, action)) {
> return false;
> }
> parameterAllowlister.primeAllowlistForPath(name, target);
> For a ModelDriven action, {{resolveTarget}} returns the model. Since WW-5698,
> {{isAuthorized}} may authorise a parameter against a member declared on the
> *action* rather than on the model — that is the whole point of scoping the
> exemption. The subsequent {{primeAllowlistForPath}} call still primes against
> the model, so for such a parameter the classes along the path are never added
> to the {{ThreadAllowlist}}.
> With {{struts.allowlist.enable=true}}, the effect is that a correctly
> {{@StrutsParameter}}-annotated nested property on a ModelDriven action's own
> class is authorised and then dropped by the allowlist. It fails closed, so
> this is a functional bug rather than a security issue, but it is confusing to
> diagnose: the annotation is present and correct, and nothing in the logs
> points at the allowlist.
> h3. Suggested fix
> Prime against the object the authorisation was actually granted on — either
> by having {{ParameterAuthorizer.isAuthorized}} report which object it
> authorised against, or by priming against both the model and the action on
> the ModelDriven path.
> Found while reviewing WW-5698 / PR
> [#1872|https://github.com/apache/struts/pull/1872].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
