[
https://issues.apache.org/jira/browse/WW-5713?focusedWorklogId=1039566&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1039566
]
ASF GitHub Bot logged work on WW-5713:
--------------------------------------
Author: ASF GitHub Bot
Created on: 04/Sep/26 05:16
Start Date: 04/Sep/26 05:16
Worklog Time Spent: 10m
Work Description: kuranikaran commented on PR #1890:
URL: https://github.com/apache/struts/pull/1890#issuecomment-5536043362
Thanks for the detailed review. Your shared-classloader concerns make sense,
especially the possibility of one application’s Dispatcher lifecycle or legacy
setting affecting another application. I agree that the current
DispatcherListener wiring should be removed.
Before rewriting it, I propose this approach:
- Restore StrutsTilesListener and the normal Tiles bootstrap lifecycle to
their existing main-branch behavior, with no DispatcherListener registration.
- Keep OGNL: registered with a lazy gating evaluator.
- At evaluation time, derive the ServletContext from the current Tiles
Request/ApplicationContext and resolve only that context’s Dispatcher.
- If its struts.tiles.ognl.legacy.enabled value is absent or false, throw
EvaluationException before constructing the raw evaluator or changing the
global Request property accessor.
- If it is explicitly true, construct/cache the legacy evaluator and emit
the migration warning once.
- Continue checking the flag against the current request’s ServletContext so
another webapp cannot opt this one into legacy behavior.
- If no Dispatcher exists, fail closed by default.
- Make the explicit boolean constructors public for applications using their
own StrutsTilesInitializer or StrutsTilesContainerFactory, including direct
Tiles setups without a Dispatcher.
This should preserve the original bootstrap behavior, remove the static
cross-application lifecycle dependency, and ensure raw OGNL construction
remains reachable only through an explicit application-local opt-in.
Would this direction address your concerns before I revise the patch?
I’m also happy to prepare the support/struts-6-x-x backport as a separate PR
after we settle and merge the main-line design, using plain @Deprecated as
noted.
Issue Time Tracking
-------------------
Worklog Id: (was: 1039566)
Time Spent: 0.5h (was: 20m)
> Fail closed for legacy Tiles OGNL evaluation
> --------------------------------------------
>
> Key: WW-5713
> URL: https://issues.apache.org/jira/browse/WW-5713
> Project: Struts 2
> Issue Type: Improvement
> Components: Plugin - Tiles
> Reporter: Karan Kurani
> Priority: Major
> Fix For: 7.4.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The Struts Tiles plugin registers separate {{S2:}} and legacy {{OGNL:}}
> attribute-expression evaluators.
> The {{S2:}} evaluator processes ValueStack expressions through the Struts
> OGNL facilities. The legacy {{OGNL:}} evaluator evaluates against the Tiles
> {{Request}} and does not use the Struts OGNL security controls used by
> {{{}S2:{}}}.
> This hardening change keeps {{OGNL:}} registered but makes it fail closed by
> default. Evaluation throws Tiles {{EvaluationException}} with migration
> guidance directing users to {{{}S2:{}}}.
> Applications that temporarily require the existing raw behavior may
> explicitly set:
> {{struts.tiles.ognl.legacy.enabled=true}}
> The compatibility flag defaults to {{false}} and is targeted for removal in
> Struts 8.0.0.
> The raw evaluator and its global {{OgnlRuntime}} {{Request}}
> property-accessor setup are constructed only when legacy mode is explicitly
> enabled. This avoids mutating the shared OGNL runtime for applications using
> the secure default.
> When legacy mode is enabled, the existing raw behavior is preserved and a
> clear startup migration warning is emitted.
> {{{}S2:{}}}, {{{}I18N:{}}}, and {{EL:}} remain unchanged.
> Tests cover:
> * default fail-closed behavior;
> * exact migration guidance;
> * non-evaluation of expression markers;
> * construction gating;
> * absence of global accessor initialization under the default;
> * explicit legacy compatibility behavior;
> * startup warning behavior; and
> * real servlet-backed {{S2:}} evaluation.
> This is defense-in-depth hardening. No attacker-controlled expression source
> or concrete vulnerability impact has been demonstrated, and no security
> advisory is proposed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
