Security Hardening

The Config Browser plugin (struts2-config-browser-plugin) publishes the action configuration of the running application: namespaces, classes, interceptors, results and properties. The guide says it must be used only in development, and that a production site that must keep it should restrict it with Basic Authentication or another security mechanism. Adding the plugin to the scratch WAR also added struts2-velocity-plugin 7.4.0 (a transitive dependency, seen in the WAR listing). Without a constraint, anyone can read the configuration:

With a security-constraint on /config-browser/* and a Basic login configuration in web.xml, the same request without credentials is refused by the container before the Struts filter runs:

The better rule is not to ship the plugin in a production artifact at all: a Maven profile for development, or a separate dependency scope, removes the question. Basic authentication also needs TLS to be acceptable; the constraint is a last resort, not a design. The plugin and the other development-only plugins are described in the Other Plugins page of this section.

Source: Apache Struts — Security, Restrict access to the Config Browser Plugin

Source: Apache Struts — Config Browser plugin

See also other plugins.

A container constraint is a URL pattern, and a Struts action is a URL. The guide therefore asks for one namespace per security level, so that one pattern describes one level. In the scratch WAR the admin action lives in the namespace /secure, the constraint covers /secure/*, and a request without credentials is refused with 401 (a challenge, because the WAR has a Basic login configuration; a deployment with the same constraints and no login-config answered 403 for both /secure/admin and /direct.jsp):

The second request is the same action in the deployment without the constraint: the framework itself does not know what "admin" means. The related risk is a second path to the same action. With the Struts 6 defaults for the two namespace constants (struts.mapper.alwaysSelectFullNamespace=false and struts.actionConfig.fallbackToEmptyNamespace=true), an action reaches through URLs that name a namespace that does not exist; the 7.x defaults require the exact namespace:

A URL-pattern constraint that protects /secure/* is useless when the same action can also be requested under another prefix; this is the reason the migration guide lists the two constants first. The namespaces and the packages that carry them are the subject of the Packages and Namespaces page of this section.

Source: Apache Struts — Security, Don’t mix different access levels in the same namespace

See also packages and namespaces.

A JSP is a servlet that can run without an action, and a JSP that uses Struts tags without an action runs without the framework’s protections (no value stack of the action, no parameter filtering). The guide’s rule is to hide every JSP behind an action by placing the files under WEB-INF, and to add a *.jsp constraint with a role that nobody has, "the best approach is to use both". In the scratch WAR the views are under WEB-INF/views, and one JSP, direct.jsp, was placed in the root on purpose. Without any constraint:

WEB-INF is never served, but the JSP in the root ran, evaluated %{1+1} and printed 2. The Struts log shows what 7.2.0 added: since that release the framework warns when a tag is rendered outside an action.

With the second protection from the guide in web.xml, the container refuses the direct request, while the action that forwards to a JSP under WEB-INF still works, because a forward is not a client request and constraints do not apply to it:

Even a request for a file under WEB-INF answers 401 in this deployment, because the *.jsp pattern matches first (observed); that is harmless, and the constraint is what protects a JSP that someone later moves out of WEB-INF. The JSP-side view of the same topic (the Default Servlet, uploads, Tomcat hardening) is in the JSP security page.

Source: Apache Struts — Security, Never expose JSP files directly

struts.devMode turns on friendly development behaviour. The default is false and the guide says to make sure that no struts.xml of the application sets it to true for production. The price of a forgotten true is shown by the g12secharddev deployment, which has the secure defaults for everything else. The debugging interceptor is in the default stack and reacts to a debug parameter when devMode is on:

With devMode on, anyone can dump the value stack and the action context as XML, open the OGNL console page, and have the server evaluate an expression: debug=command answered 2. The expression still passes through the member-access rules and the allowlist (the dev deployment has both on), which is why the evaluation of harmless arithmetic is the strongest thing shown here: the point is that the endpoint exists, and what an expression can then reach is limited only by the member-access rules. With the default false the same request is an ordinary request for /books and the parameter is ignored. devMode has a second face: an unmapped exception or an unknown action answers HTTP 200 with the "Struts Problem Report", a page with the message and the whole stack trace (observed in the weak deployment on /crud-purge). The debugging page of this section covers devMode for development; for production the rule is a single line in struts.xml or struts.properties:

Source: Apache Struts — Security, Disable devMode

Source: Apache Struts — Development Mode

Source: Apache Struts — Debugging Interceptor

The guide asks to reduce framework logging from DEBUG to INFO or WARN, because the framework writes many entries and because the DEBUG output of the parameter and OGNL machinery repeats request values. Its example logs the two prefixes at WARN. The scratch log4j2.xml follows the same idea, with one deliberate exception for the parameter interceptor so that the decisions on this page can be read:

Two details deserve attention. The guide’s example also lists com.opensymphony.xwork2 at WARN; since 7.0 that package no longer exists (the 7.4.0 jar has no com/opensymphony entry, and the migration guide renames it to org.apache.struts2), so that line configures a logger that nothing writes to and org.apache.struts2 is the only name that matters. And WARN is the level at which every defence on this page reports: the SecurityMemberAccess blocks, the StrutsOgnlGuard blocks, the rejected Fetch Metadata requests and the startup warnings. Dropping the framework to ERROR, or to OFF to quiet a noisy log, switches off the only evidence that an attack was attempted. The pattern shown here keeps the framework at WARN and raises a single logger to DEBUG when a parameter disappears; the debugging and logging page of this section covers the Log4j 2 configuration for development and production.

Source: Apache Struts — Security, Reduce logging level

The guide asks for UTF-8 everywhere and adds contentType="text/html; charset=UTF-8" to each JSP. The framework default is struts.i18n.encoding=UTF-8 (7.4.0 default.properties), and the scratch JSPs also carry the page directive. The effect that matters for security is that the request decoder, the response encoder and the page agree, because a mismatch between what a filter inspects and what the browser decodes is a classic way around an escaping rule:

The character-encoding page of the JSP part of this guide covers the directive, request.setCharacterEncoding and the filter.

Source: Apache Struts — Security, Use UTF-8 encoding

See also character encoding.

Since 6.4 as an option and by default since 7.0, a request parameter reaches an action only through a member annotated with @StrutsParameter. The guide’s rules, which this section reproduces as checks rather than text: annotate the setter that is meant to receive a request value; to fill a DTO, define a getter returning it and annotate the getter with depth = 1 (more for nested objects, "do not set this depth field to a value greater than the minimum required"); annotated getters should return only DTOs or collections of DTOs; never annotate a method that returns live Hibernate objects, container or Spring beans, or an object with setters used for anything other than form values; keep database DTOs apart from form DTOs. The scratch action has one member of each kind:

The two unannotated setters were ignored and so was the nested account.role, while filter and the DTO properties arrived. The log of StrutsParameterAuthorizer explains each decision at DEBUG:

The annotation has a second job that is easy to overlook: a parameter that matches an annotated member also puts the member’s type on the allowlist for that request (the section on the allowlist shows it). For an upgrade from 6.x, the guide offers struts.parameters.requireAnnotations.transitionMode=true: only nested parameters (DTOs and collections behind public getters) need annotations while public setters stay exposed, and the allowlist keeps working, so an application can switch on the allowlist before it has annotated every setter. It is a migration aid, not a destination. The complete binding decision (name length, patterns, ParameterNameAware, value patterns), ModelDriven and JSON/REST bodies are in parameter injection and @StrutsParameter; this page only records the rule as a checklist line.

Source: Apache Struts — Security, Defining and annotating your Action parameters

Source: Apache Struts — StrutsParameter Annotation

The guide’s rule for applications that do not require annotations is to design actions without public setters and getters that nothing needs, because an action’s setter can receive an untrusted value, and because some results populate their own parameters from values on the value stack, so an incoming value can be evaluated as an expression during that process. The admin setter above is the example: it exists for a test and nobody remembers it. In the g12sechardweak deployment (annotations off, the Struts 6 behaviour) the same requests as above do this:

The request set a privilege flag (admin=true) and changed the role of a domain object that the form never mentioned (account.role=admin), without any exploit, only by naming members. This is parameter injection at its simplest and the reason the annotation requirement exists. The rule outlives the annotation: with annotations on, a setter that exists without being needed is still an attack surface for anything that is not a request parameter (a static parameter, a wildcard value, a JSON body in the REST plugin). Delete setters that nothing calls, and keep domain objects out of the action’s public API.

Source: Apache Struts — Security, Do not define setters when not needed

Every getText(...) method of a TextProvider (for instance in ActionSupport) evaluates the parameters that a message contains. The guide’s example is an action with a message property that does message = getText(getMessage()): the key is a request value, and when no bundle defines the key, the default text, which is the key itself, is evaluated as an expression. The scratch GreetAction has the unsafe form and the safe form, with a harmless expression as the payload:

The request carried the text %{1+1}. The unsafe action answered 2: a request value was evaluated as OGNL, and this happens on a hardened deployment too, because @StrutsParameter correctly allowed message (it is annotated) and the allowlist and exclusion lists only restrict what the expression may touch. The safe action answered the literal text. The unsafe request also leaves a trace in the log, which is the way to find this class of bug:

An attacker’s expression would be a longer one, and the defences of the next chapter (member access, allowlist, expression limit) are what keep it from reaching anything dangerous; they are the second line, not an excuse for the first. The %{...} evaluation of message texts is useful (it is how a bundle message can read action properties) and is exactly why the key must never come from a request.

Source: Apache Struts — Security, Do not use incoming values as an input for localisation logic

See also localization and i18n.

Most tag attributes of the Struts tag library accept the %{...} syntax, which forces the attribute to be evaluated as an expression. The guide: "Never use forced expression evaluation if you didn’t verify the input or it can be passed in by a user", and "never use the value of an incoming request parameter as input for forced expression evaluation". Two questions decide whether a use is safe: where does the text inside the braces come from, and does a tag then use the evaluated result as another expression? The scratch page forced.jsp binds the request value userInput and uses it in four ways:

Lines A and B are safe: the attribute is an expression, userInput is a property, and its value is printed (the text %{1+1} is printed as text, and s:property escapes HTML by default). Line D is the dangerous shape: the name attribute is evaluated to the request value, and then a textfield uses its name as an expression to find the value to display, so a request value became an expression. The second request shows that the lookup really happens (the field name book.title is read from the stack; it printed an empty value because Book is not allowlisted in this deployment). The framework refuses the dangerous variants on its own in two places, both visible in the log: the arithmetic text of the first request is refused by the accepted-pattern check that components apply to such expressions, and the property read of the second is refused by the allowlist:

That the framework blocks these particular probes is not a licence: pattern checks and exclusion lists are defences in depth, and every one of the historical Struts OGNL injections (the bulletins in the upgrade section) was a double evaluation that the defences of its day did not anticipate. The rule for code review is simple: a value that comes from a request, a cookie, a header or a database column written by a user never appears inside %{...}, in name, value, label, key, action, namespace or a link target, and never in getText. The 7.4.0 Version Notes record, among the rejected requests (WW-3338), that String-valued attributes are parsed for the %{} notation by design, so the burden is on the author of the JSP.

Source: Apache Struts — Security, Do not use incoming, untrusted user input in forced expression evaluation

Source: Apache Struts — Tag Syntax

See also tags overview and generic tags.

JSP EL does not escape: the guide says never to use a raw ${} expression on incoming values, and that the safest option is a Struts tag. The Struts request wrapper makes value-stack properties visible to EL, which makes the mistake easy. echo.jsp prints the same value four ways, with the payload <b>hi</b> (harmless markup):

The two EL lines are printed as markup, and with a script element in place of b they would be stored or reflected cross-site scripting. The tag escaped the value, and escapeHtml="false" turned the escaping off, so a code search for that attribute is a review item. Struts tags escape for HTML text; inside a JavaScript block or an attribute that holds a URL or a CSS value another encoder is needed (the OWASP Java Encoder and the escaping rules of each context are in the JSP security page, and the same idea is explained for another view technology in Thymeleaf template security and XSS).

Source: Apache Struts — Security, Use Struts tags instead of raw EL expressions

Source: Apache Struts — property tag

The guide’s reference is S2-006: by default XWork did not escape action names in generated error pages, and with Dynamic Method Invocation the action name is built from request parameters, so an attacker could put script into an error page (that bulletin is CVE-2011-1772, fixed in 2.2.3). The guide’s two remedies are to disable DMI and to define your own error pages. The second is also the answer to a less dramatic problem, information disclosure. The scratch BoomAction throws an exception whose message names an internal database host. In the default package a global exception mapping catches it, and in the package /raw no mapping exists:

The mapped path shows a generic page and nothing else. The unmapped path ended in Tomcat’s default error page, with HTTP 500, the exception message and the stack of the request (dozens of frames that name every interceptor of the stack and the Struts and Tomcat classes, even with devMode off). The fix has two parts: map exceptions in Struts so that a user sees a short page, and set error-page elements in web.xml (or the showReport option of Tomcat’s ErrorReportValve) so that the container’s default page never leaks a trace for what Struts did not catch. The guide’s other remedy, disabling DMI, is the default of 7.4.0 (see strict method invocation below). The exception mappings and global results are described in exception handling and global results.

Source: Apache Struts — Security, Define custom error pages

Source: Apache Struts — Security Bulletin S2-006

Source: CVE-2011-1772

The guide warns of actions with a deep class hierarchy that reuse one method name (WW-4405): its example is a RealAction whose save() calls the save() of BaseAction, which calls a protected save(Double) in AbstractAction, and it says OGNL cannot decide which method to call; the remedy is to rename the action method (saveAction()) and keep the URL by annotation. The scratch WAR has exactly that hierarchy, mapped twice (a method attribute on the action, with no annotation):

On 7.4.0 both mappings work: the ticket quoted by the guide is closed as fixed in 2.5, the invocation goes through OgnlUtil.callMethod and the overloaded save resolved correctly. The guide’s advice is still reasonable for an application that must run on old versions, and a method name that is unique in the hierarchy costs nothing, but it should not be a reason to rewrite a working 7.x action (recorded as an inconsistency of the guide at the end of this page). The configuration of action methods is in actions.

Source: Apache Struts — Security, Ambiguous Action Methods

Since 2.3.20 the framework has two interfaces, AcceptedPatternsChecker and ExcludedPatternsChecker, with default implementations (DefaultAcceptedPatternsChecker, DefaultExcludedPatternsChecker), used by the Parameters Interceptor and the Cookie Interceptor to accept or refuse parameter and cookie names; applications that used excludeParams should compare their patterns with the defaults. The decisions are logged at DEBUG, and a request with five hostile names shows the defaults in action:

All five requests answered HTTP 200 and nothing was bound. The excluded pattern covers the context roots (session, request, parameters, _memberAccess…​), top, the class property and the three error collections; the accepted pattern allows property paths, numeric indexes and quoted keys but no operators or parentheses with names. A rule worth remembering from the parameter-injection page is that a parameter name that is rejected is not an error, it is dropped, so a monitoring rule needs the DEBUG log or a WARN-level custom ParameterNameAware to notice a probe. And an excludeParams setting on the params interceptor replaces the default exclusion list entirely (verified on the parameter-injection page), so do not use it as a way to add one pattern.

Source: Apache Struts — Security, Accepted / Excluded Patterns

Source: Apache Struts — Parameters Interceptor

Strict Method Invocation (SMI) controls which methods of an action a request may reach, particularly through the bang (!) of Dynamic Method Invocation. The guide dates it to 2.5 ("introduced in version 2.5"), while the Core Developer Guide’s action configuration page dates it to 2.3; either way, the mechanism is on by default today: an action mapped with method="list" can run only list unless its allowed-methods says otherwise. The scratch CrudAction has three public methods and four mappings; purge is the destructive one:

The results on the hardened deployment, where DMI is off, and on the weak one, where struts.enable.DynamicMethodInvocation=true (the allowed-methods element must come after the result elements, or the filter fails to start, as the wildcard page records):

Three conclusions follow. With the 7.x defaults a wildcard method whose name is not in allowed-methods is not reachable (crud-purge is refused on both deployments, a 404 on the hardened one; the request crud-delete, whose method is listed, printed done=delete on the hardened deployment). With DMI on, the bang works only for methods that allowed-methods lists, so strict invocation protects even a deployment that turned DMI on. And the package attribute strict-method-invocation="false" brings back the Struts 2.0 behaviour in that package (the last row: a request for /legacy/crud!purge ran the destructive method), which is the reason the attribute is a code review item. The same mechanism restricts a wildcard that puts the method in {1}: the default regular expression of 7.4.0 for such methods is ([A-Za-z0-9_$]*), configurable with struts.strictMethodInvocation.methodRegex (the wildcard page has the details). Also keep struts.mapper.action.prefix.enabled=false (the default): when on, the action: prefix lets a request choose another action, and struts.mapper.action.prefix.crossNamespaces=false (also the default) keeps that choice inside the current namespace. All of this is described and tested in wildcard mappings and method invocation.

Source: Apache Struts — Security, Strict Method Invocation

Source: Apache Struts — Action Configuration, Strict Method Invocation

Fetch Metadata is a browser feature: every request carries Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest and Sec-Fetch-User, which tell the server whether the request was started by the same origin, a same-site page or another site, and why. The fetchMetadata interceptor implements a Resource Isolation Policy against them, as a mitigation against cross-site request forgery and cross-site leaks; the guide dates it to Struts 6.0.0. In 7.4.0 it is part of defaultStack (struts-default.xml) with disabled=false, and it adds a Vary header to every response. The scratch requests send the headers by hand:

The cross-site request is rejected, the same-origin one passes, and a request without the headers (an old browser, curl) passes. The last line is a property of the policy, not a bug: Fetch Metadata is a defence for browsers, and server-to-server calls need other protections. The log says Fetch metadata rejected cross-origin request to: /g12sechard. The trap is how the rejection is reported. The interceptor returns the result code 403; the action needs a result with that name. In the first attempt, without a 403 result, the same cross-site request answered HTTP 200 with the application’s error page in the package with a global exception mapping, and HTTP 404 ("No result defined for action") in a package without one; the httpheader global result shown in the error-page section above turned both into a real 403. The interceptor parameters (disabled, exemptedPaths for endpoints that serve cross-site clients, such as a public API) and the response headers Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy-Report-Only seen above are the subject of the security headers page of this section, which also covers Content Security Policy.

Source: Apache Struts — Security, Resource Isolation Using Fetch Metadata

Source: Apache Struts — Fetch Metadata Interceptor

The Cross-Origin Opener Policy lets a document ask for a separate browsing context group, and the Cross-Origin Embedder Policy prevents loading cross-origin resources that do not grant permission. They are independent; set together they allow powerful features (SharedArrayBuffer, performance.measureMemory()) to be used safely. The guide’s recommended values are Cross-Origin-Embedder-Policy: require-corp; and Cross-Origin-Opener-Policy: same-origin;, implemented by the CoopInterceptor and the CoepInterceptor (since 6.0.0). The defaultStack of 7.4.0 contains both: coop with mode=same-origin and coep with enforcingMode=false, which is why the response above has the COOP header and the report-only form of the COEP header. The csp interceptor is in the same stack with enforcingMode=false; the response of the scratch application carried no Content-Security-Policy header, so a policy has to be configured before there is anything to enforce or to report. Enforcing COEP breaks any page that embeds images or scripts from another origin without Cross-Origin-Resource-Policy, so the guide’s advice to "test and deploy separately" is literal. The details, the Content Security Policy interceptor and CORS interplay (CORS) are in the security headers page of this section.

Source: Apache Struts — Security, Cross Origin Isolation with COOP and COEP

Source: Apache Struts — COOP Interceptor

Source: Apache Struts — COEP Interceptor

The guide: add -Dognl.security.manager to the JVM arguments and OGNL runs expressions (and therefore actions) inside a Java Security Manager sandbox with no permissions, affecting only OGNL execution, and "this feature does not work with JDK 21 and above". Tested on this machine, the second half is a simplification, and the first half is a dead end:

(Sm.java is a one-line program that calls System.setSecurityManager(new SecurityManager()).) On JDK 21 a Security Manager can still be installed when the command line allows it, with warnings; on JDK 24 and later (JEP 486, tested on 25) it cannot be enabled at all. The result of this check is limited to the JDK facts: this page did not run OGNL under a Security Manager. The practical conclusion is that the sandbox is a mechanism of old JVMs: Struts 7 requires Java 17, a 17 or 21 runtime is the only place where it could still apply, and no new design should depend on it. The other layers of this chapter do not depend on the JVM version.

Source: Apache Struts — Security, Run OGNL expressions inside sandbox

The ActionContext is shared throughout the framework and reaches parameters, the value stack, the request, the response, the session, the servlet context and, through them, more. An expression can use it with the # operator (#session, #request) or indirectly: when an expression finds no value on the value stack, OgnlValueStack falls back to a lookup in the context. The exclusion lists block the known harmful members, but "the myriad of changing objects" on the context makes that unreliable; the allowlist is stronger; and the strongest protection is to forbid the access, with two constants from the guide. Note the guide’s warning that as of 6.4.0 the Set, Iterator and Action components require ActionContext access from OGNL, so test the pages that use them:

The guard setting forbids the syntax node of #name; the fallback constant turns off the indirect lookup. On the /g12sechardguard deployment (the Bookshelf allowlist package plus the two constants above, set in struts.properties) the probe lines 9 and 10 became empty, and the log has the Guard’s decision:

Without the two constants lines 9 and 10 printed {} (an empty map: the expressions were allowed to read the context). Before switching them on, search the views for # and for #attr, #session, #parameters, and run every page; the migration of the iterator and s:set tags is where an application usually finds a dependency it forgot.

Source: Apache Struts — Security, Restricting access to the Struts Context (ActionContext)

See also the value stack, the ActionContext and OGNL.

struts.ognl.expressionMaxLength (default 256 in 7.4.0) makes OGNL refuse to evaluate any expression longer than the value; the guide says to choose a value large enough for all valid expressions and that values above the 200 to 400 range have diminishing value ("really only a style guard"). longexpr.jsp has a short expression ("a"+"b") and one of 323 characters made of the same pieces (80 additions), evaluated on the default deployment and on a deployment with 400:

The log is at ERROR level here (the other layers use WARN), with the expression in the message; so expression text that reached the log is itself user-influenced input and should not be fed to a log viewer that renders markup. A legitimate page that hits the limit, usually a long validation rule in an XML validator file, should move the logic into Java; raising the constant is the last resort, and each increase hands attackers room for a longer payload.

Source: Apache Struts — Security, Apply a maximum allowed length on OGNL expressions

The SecurityMemberAccess bean (declared in struts-beans.xml with the name struts and prototype scope) is consulted for every member of every object that an expression touches, by target class and by member class: parameters, JSP expressions, validators, results. Its protected checks, as listed by javap on the 7.4.0 class, are checkAllowlist, checkExclusionList, checkDefaultPackageAccess, checkProxyObjectAccess, checkProxyMemberAccess, checkStaticMethodAccess, checkStaticFieldAccess and checkPublicMemberAccess; static method access is refused in every deployment of this page, including the weak one. The guide lists four options for the exclusion lists, and 7.4.0 ships values for two of them in struts-excluded-classes.xml:

With devMode on, Struts reads the parallel constants struts.devMode.excludedClasses and struts.devMode.excludedPackageNames instead (the startup WARN "DevMode enabled, using DevMode excluded classes" says so); in the 7.4.0 jar the dev-mode class list is the same as the normal one except that it lacks org.apache.struts2.ActionContext, which is one more reason not to run production with devMode. The guide shows the log line for a blocked expression; the observed lines on the 7.4.0 scratch deployments are:

Lines 3 and 5 of the table are blocked in every deployment, as the guide states for static methods and as the exclusion of java.lang.Object (the declaring class of getClass()) implies. new Book() (line 2) produced an empty value everywhere, and with the allowlist off it logged nothing at WARN, whereas the guide shows a WARN for the example new MyBean(); the expression is blocked either way and the guide’s text on the reason (the target of a constructor call is java.lang.Class, which is excluded) is consistent with the empty result. The guide’s advice for the lists: redefine them in struts.xml if you must, "but avoid reducing the list, instead extending the list with other known dangerous classes or packages in your application". A constant set in struts.properties replaces the list as a whole, so an extension restates the defaults. /g12sechardexclpkg does it: the allowlist off, the 29 default package names and org.example.vendor; line 7 of the probe, which printed Acme Press with the allowlist off, became empty, with the log line

(the identity hash is not significant). The 7.4.0 Version Notes also record a breaking change for code that customises the mechanism: five dev-mode configuration setters were removed from SecurityMemberAccess and the eleven remaining use* setters are deprecated in favour of SecurityMemberAccessConfig (WW-5675, removal planned in WW-5682).

Source: Apache Struts — Security, OGNL Member Access

Source: Apache Struts 7.4.0 Javadoc — SecurityMemberAccess

Source: Apache Struts — default.properties

The guide recommends five more options, "enabled by default in 7.0". Their 7.4.0 values come from default.properties, and the first one was exercised with the weak deployment:

struts.disallowProxyMemberAccess also exists in 7.4.0 (a class listing of StrutsConstants shows it) and is not mentioned in the guide. When the proxy rule is disabled, the migration guide says the allowlist keeps working with an exemption for Hibernate proxies (and for Spring proxies since 7.1), so an application with proxied beans can still get the allowlist.

Source: Apache Struts — Security, Additional Options

The strongest OGNL protection is to invert the question: not "is this class dangerous?" but "is this class known to the application?". With struts.allowlist.enable=true (the default since 7.0, optional since 6.4), a class involved in an expression must be allowlisted in addition to passing the exclusion lists. The allowlist contains the Struts classes that the framework needs, the action classes (and other classes) defined in the packages of struts.xml, the types of annotated parameters (when a matching parameter arrives), and what the application adds with struts.allowlist.classes (exact names) and struts.allowlist.packageNames (startsWith, sub-packages included). The guide’s advice is to monitor the logs for blocked classes and add them, and that "depending on the functionality of your application, you may not need to manually allowlist any classes". The probe shows the four cases that decide whether a class needs an entry:

Four observations follow from it. First, a class in the application’s own package is not automatically allowlisted: Book is a plain bean in the package of the actions, and book.title was blocked until the package or the class was added, which is what an upgrade from 6.x trips over first (the getting-started page of this section records the same effect on the official Hello World). Second, the allowlist is the outermost OGNL gate: it stood in front of the Imprint class in a package that no deployment had configured. Third, an annotated getter allowlists its return type only for a request in which a parameter matched it: with exposed.name=Zed in the query, line 8 printed Zed, and line 7, an unrelated read of an Imprint through an unannotated getter, also worked in the same request because the class was by then allowlisted for the duration of that request; without the parameter, both lines were empty. A reviewer should read that as: the allowlist is per class and per request, not per property. Fourth, the guide’s recommendation to turn on the parameter annotation capability "to ensure any necessary parameter injection types are allowlisted" is how most applications get by without listing anything. The declaration in struts.xml is as short as

and the 6.x to 7.x guide’s procedure for choosing entries is practical: start the application with the allowlist on, view pages and submit forms, and read the WARN lines. A wildcard action whose class is chosen only by a pattern variable (class="actions.{1}") is not allowlisted for the same reason, and its package must be listed (see the wildcard page).

Source: Apache Struts — Security, Allowlist Capability

Source: Apache Struts — Struts 6.x.x to 7.x.x migration, OGNL allowlist capability

Since 6.4 the member access mechanism is extensible: the guide names the extension point struts.securityMemberAccess for defining your own rules for blocking OGNL evaluations, with the warning to be vigilant "as not to reduce protections offered by the default implementation". In 7.4.0 the default is the bean org.apache.struts2.ognl.SecurityMemberAccess (declared in struts-beans.xml as <bean name="struts" class="...SecurityMemberAccess" scope="prototype"/>), and the configuration holder is SecurityMemberAccessConfig. A class that extends SecurityMemberAccess and overrides one of its protected checks (checkAllowlist, checkExclusionList, isClassExcluded, checkStaticFieldAccess and so on, all present in the 7.4.0 class) and calls super first keeps the defaults. This page did not build a custom member access class: the Version Notes mention that the setter methods that configuration code used are deprecated in 7.4.0, so any custom subclass should be written against SecurityMemberAccessConfig, and the extension of the sibling mechanism below is the one that was verified.

Source: Apache Struts — Security, Extensibility

The Guard (since 6.4) forbids OGNL features outright. It is off by default and configured with a list of node types in struts.ognl.excludedNodeTypes. The guide’s advice is to disable every feature that the application does not use: for example, an application that never adds inside an expression can list ognl.ASTAdd, "which will mitigate against a host of String concatenation attacks". Its list of 30 node types is a starting point for applications with minimal use of Struts features, and "this list WILL break certain Struts features": it contains ASTAdd, ASTAssign, ASTCtor, ASTEval, ASTList, ASTMap, ASTProject, ASTSelect, ASTStaticField, ASTStaticMethod, ASTThisVarRef, ASTVarRef and the arithmetic and bit operators. The /g12sechardguard deployment blocked the + of the earlier longexpr page with the shortest possible list:

Both expressions were blocked, including the short one, because they use addition, and every view that concatenates with + inside an OGNL attribute would stop working; this is the cost model of the Guard, and its reward is that a whole class of payloads (those built from concatenation) cannot be parsed. Roll out a list by adding the node types the audit of the views proves unused, one at a time, with the WARN lines in front of you.

The Guard is extensible: the extension point struts.ognlGuard accepts a bean of type org.apache.struts2.ognl.OgnlGuard (an interface with two abstract methods, isRawExpressionBlocked(String) and isParsedTreeBlocked(Object)), and the guide says one may override the default implementation (StrutsOgnlGuard, the bean named struts) or implement the interface directly. The scratch WAR registers a subclass that keeps the default node rules and refuses any expression that reads a property called title:

The same page with the same allowlist package printed Dune without the custom guard and an empty value with it, so the extension point works as documented. It is a blunt instrument: a guard that rejects by substring also rejects legitimate expressions, and a custom guard must be at least as strict as the default, hence the super call.

Source: Apache Struts — Security, Struts OGNL Guard

Source: Apache Struts 7.4.0 Javadoc — OgnlGuard

Source: Apache Struts 7.4.0 Javadoc — StrutsOgnlGuard