Skip to content

WW-5623 fix(core): HTML-encode form action in PostbackResult to prevent XSS#1701

Merged
lukaszlenart merged 1 commit into
support/struts-6-x-xfrom
WW-5623-postback-result-xss-6x
May 25, 2026
Merged

WW-5623 fix(core): HTML-encode form action in PostbackResult to prevent XSS#1701
lukaszlenart merged 1 commit into
support/struts-6-x-xfrom
WW-5623-postback-result-xss-6x

Conversation

@lukaszlenart

Copy link
Copy Markdown
Member

Backports #1653 to the 6.x line.

PostbackResult.doExecute() embeds finalLocation into a <form action=""> attribute via raw string concatenation. Wrap it with StringEscapeUtils.escapeHtml4(), consistent with the encoding approach used in DefaultActionProxy, Property, and TextProviderHelper.

See #1653 for the full analysis.

Adds three regression tests covering the XSS payload, all special characters, and the clean-URL regression case.

Fixes WW-5623.

…nt XSS

PostbackResult.doExecute() embeds finalLocation into a <form action="">
attribute via raw string concatenation. A double quote in the location
breaks out of the attribute, enabling reflected XSS. The response
Content-Type is text/html.

Form field names and values elsewhere in the same class are properly
URL-encoded via URLEncoder.encode(); the action attribute was not
encoded at all.

Wrap finalLocation with StringEscapeUtils.escapeHtml4() before embedding
it in the form tag, consistent with the encoding approach used in
DefaultActionProxy, Property, and TextProviderHelper.

Adds three regression tests in PostbackResultTest:
- testFormActionHtmlEscaping: XSS payload with attribute breakout
- testFormActionEscapesAllHtmlSpecialChars: covers ", &, <, >
- testFormActionCleanLocationUnchanged: regression for clean URLs
@sonarqubecloud

Copy link
Copy Markdown

@lukaszlenart lukaszlenart merged commit aaf286a into support/struts-6-x-x May 25, 2026
10 checks passed
@lukaszlenart lukaszlenart deleted the WW-5623-postback-result-xss-6x branch May 25, 2026 14:38
@lukaszlenart

Copy link
Copy Markdown
Member Author

Just one important remark

This PR doesn't address a vulnerability, it's pure framework hardening. The potential attack vector assumes a developer uses a raw user input in OGNL expression evaluation which is against our guideline:
https://struts.apache.org/security/#do-not-use-incoming-untrusted-user-input-in-forced-expression-evaluation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant