[
https://issues.apache.org/jira/browse/WW-5838?focusedWorklogId=1052745&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1052745
]
ASF GitHub Bot logged work on WW-5838:
--------------------------------------
Author: ASF GitHub Bot
Created on: 05/Nov/26 14:22
Start Date: 05/Nov/26 14:22
Worklog Time Spent: 10m
Work Description: lukaszlenart opened a new pull request, #2111:
URL: https://github.com/apache/struts/pull/2111
Fixes [WW-5838](https://issues.apache.org/jira/browse/WW-5838)
`SecurityMemberAccess` compares the declaring class and the target class of
each member an OGNL expression resolves against `struts.excludedClasses` and
`struts.excludedPackageNames`. The shipped lists did not name `java.beans`.
`java.beans.Expression` and `java.beans.Statement` perform the call they
describe inside the JDK, so the inner call is never presented as a member and
neither the excluded-class check nor the static-method check sees it. On this
line the allowlist (on by default) rejects the constructor; the package
exclusion closes the same path where the allowlist has been disabled.
`java.lang.reflect` and `java.lang.invoke` are reachable from an expression
only through a static call or a `Class` object, both already rejected, and are
excluded in the same pass. The package rule also covers
`java.beans.beancontext`. An application that needs expression access to a
class in one of these packages can re-allow it with
`struts.excludedPackageExemptClasses`.
## Changes
- `struts-excluded-classes.xml`: the three packages added to
`struts.excludedPackageNames` and `struts.devMode.excludedPackageNames`
- `StrutsExcludedClassesTest`: loads the shipped file with the allowlist
disabled and pins that member access on `Expression`, `Statement`, `Method` and
`MethodHandle` is denied (declaring-class and target-class branches), that the
dev-mode list carries the same entries (production list overridden to a single
entry so only the dev-mode list can deny), that the
`struts.excludedPackageNames` setting replaces the shipped list, and that an
`Expression` constructed inside an OGNL expression is rejected at its
constructor. All six tests fail without the XML change.
Full `core` test suite: 3644 tests, 0 failures. The 6.x counterpart is a
separate PR against `support/struts-6-x-x`.
Reported by Yu Deshui (于得水, @qiushui_sky) and by Daniel Owens.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1052745)
Remaining Estimate: 0h
Time Spent: 10m
> Exclude java.beans, java.lang.reflect and java.lang.invoke from OGNL member
> access by default
> ---------------------------------------------------------------------------------------------
>
> Key: WW-5838
> URL: https://issues.apache.org/jira/browse/WW-5838
> Project: Struts 2
> Issue Type: Improvement
> Components: Core
> Reporter: Lukasz Lenart
> Assignee: Lukasz Lenart
> Priority: Major
> Fix For: 6.13.0, 7.5.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> SecurityMemberAccess checks the declaring class and the target class of every
> member an OGNL expression resolves against {{struts.excludedClasses}} and
> {{struts.excludedPackageNames}}. The shipped lists in
> {{struts-excluded-classes.xml}} name the usual JDK entry points
> ({{java.lang.Runtime}}, {{java.lang.ProcessBuilder}}, {{java.lang.Class}},
> {{java.lang.ClassLoader}}, {{java.io}}, {{java.net}}, {{javax}},
> {{sun.reflect}}, ...) but not {{java.beans}}.
> {{java.beans.Expression}} and {{java.beans.Statement}} perform the method
> call they describe inside the JDK. An expression that constructs one and
> calls {{getValue()}} therefore has the inner call made on its behalf, and
> that call never appears as a member for SecurityMemberAccess to check, so
> neither the excluded-class check nor the static-method check applies to it.
> On 7.x the allowlist ({{struts.allowlist.enable=true}} by default) rejects
> the {{java.beans.Expression}} constructor, so the gap is reachable only where
> the allowlist has been disabled. On 6.x the allowlist is off by default and
> the exclusion lists are the only layer.
> Change, on both lines:
> * add {{java.beans}}, {{java.lang.reflect}} and {{java.lang.invoke}} to
> {{struts.excludedPackageNames}} and {{struts.devMode.excludedPackageNames}}
> in {{struts-excluded-classes.xml}}
> * a regression test that evaluates such an expression against the shipped
> configuration with the allowlist disabled
> {{java.lang.reflect}} and {{java.lang.invoke}} are reachable from an
> expression today only through a static call or a {{Class}} object, both of
> which are already rejected; they are added in the same pass for the same
> reason. The package rule also covers {{java.beans.beancontext}}. An
> application that needs expression access to a class in one of these packages
> can re-allow it with {{struts.excludedPackageExemptClasses}}.
> Reported by Yu Deshui (于得水, @qiushui\_sky) and by Daniel Owens.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
