[
https://issues.apache.org/jira/browse/WW-5756?focusedWorklogId=1045595&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1045595
]
ASF GitHub Bot logged work on WW-5756:
--------------------------------------
Author: ASF GitHub Bot
Created on: 04/Oct/26 17:04
Start Date: 04/Oct/26 17:04
Worklog Time Spent: 10m
Work Description: lukaszlenart commented on PR #1986:
URL: https://github.com/apache/struts/pull/1986#issuecomment-5982375763
Thanks for the PR and the thorough tests.
We're going to close this one. The `href`/`value` of `<s:a>` is chosen by
the template author. When a template sends request-derived data into a URL
attribute, checking what that data contains is the application's job. The
framework doesn't add context-specific encoding or validation on top of what
the template asks for (see `THREAT_MODEL.md` ยง9).
Turning this on by default would also break working pages. The scheme list
would quietly rewrite links like our own showcase's
`href="javascript:history.back();"` (`apps/showcase/.../actionPrefix/*.ftl`),
as well as `ftp:`, `sms:`, custom app schemes and `blob:`/`data:` downloads.
They would all become `#` with nothing logged. And because the check sits in
`DefaultUrlHelper.buildUrl`, it would also affect `<s:url>`, `<s:form action>`
and `URLBean`, not just `<s:a>`.
For applications that render user-supplied links, the recommended approach
is to check the value where it comes in: validate it in the action, or
allowlist its scheme with a validator. Alternatively, build the link from
`action`/`namespace` rather than passing a raw `href`.
Closing as working as intended. Thanks again for the effort.
Issue Time Tracking
-------------------
Worklog Id: (was: 1045595)
Time Spent: 20m (was: 10m)
> Reject javascript:/vbscript:/data: schemes in <s:a> href values
> ---------------------------------------------------------------
>
> Key: WW-5756
> URL: https://issues.apache.org/jira/browse/WW-5756
> Project: Struts 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.11.0, 7.3.0, 7.4.0
> Reporter: Gouri Sankar A
> Priority: Major
> Fix For: 7.5.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> <s:a> builds its href attribute by neutralizing a literal quote (the href=
> attribute, via
> ensureAttributeSafelyNotEscaped) or blocking a literal "<script" substring
> (the value= attribute, via
> DefaultUrlHelper.buildUrl -- a check that appears to date back to
> S2-002/CVE-2008-6682, WW-2427, based
> on an exact symptom match with that historical ticket). Neither stops the
> value itself from naming an
> executable scheme: javascript:alert(1) needs no quote or <script substring to
> run once the link is
> activated.
> Reproduced on main (7.5.0-SNAPSHOT) and confirmed the same vulnerable code is
> present unchanged in
> 6.11.0, 7.3.0 and 7.4.0. Tested with embedded Tomcat 10.1.34, stock
> struts-default, one
> @StrutsParameter-bound action property named q, set to
> javascript:alert(document.cookie), bound through
> the documented tag-attribute pattern. Binding that property to the href
> attribute renders
> href="javascript:alert(document.cookie)". Binding the same property to the
> value attribute instead
> renders the same unescaped href="javascript:alert(document.cookie)". Binding
> it to the anchor attribute
> is safe: the payload lands as a URL fragment and is inert.
> Also confirmed vulnerable before a fix: case variation such as JaVaScRiPt
> instead of javascript, an
> embedded tab or newline inside the scheme (a browser's own URL parser strips
> these before reading the
> scheme, per the WHATWG URL spec, so a filter that simply checks whether the
> value starts with the text
> javascript followed by a colon would miss them), and a leading space or NUL
> character.
> Proposed fix (patch available): a new allowlist-based check (http, https,
> mailto, tel), applied before
> the existing quote and script-substring checks, with the same WHATWG-style
> normalization so the
> tab/newline-split variant is still caught. I have a patch with regression
> tests ready and will open a PR
> referencing this ticket.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
