[
https://issues.apache.org/jira/browse/WW-5756?focusedWorklogId=1045594&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1045594
]
ASF GitHub Bot logged work on WW-5756:
--------------------------------------
Author: ASF GitHub Bot
Created on: 04/Oct/26 16:47
Start Date: 04/Oct/26 16:47
Worklog Time Spent: 10m
Work Description: g0w6y opened a new pull request, #1986:
URL: https://github.com/apache/struts/pull/1986
Fixes [WW-5756](https://issues.apache.org/jira/browse/WW-5756)
`<s:a>` built its `href` attribute by neutralizing a literal quote (the
`href=` attribute) 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). 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.
Adds `SafeUriUtil.rejectUnsafeScheme`, an allowlist (`http`, `https`,
`mailto`, `tel`) applied before the existing checks, rather than a blocklist of
the schemes that happen to be known. The value is normalized the way a
browser's own URL parser normalizes it before reading the scheme (strip a
leading C0 control/space, remove embedded tab/newline/CR), so a scheme split
across those characters is still caught.
Relative, query-only and fragment-only hrefs, and the
`http`/`https`/`mailto`/`tel` schemes, are unaffected.
Three regression tests fail without the change: `SafeUriUtilTest`, two new
cases in `DefaultUrlHelperTest`, and a new golden-file case in `AnchorTest`.
Issue Time Tracking
-------------------
Worklog Id: (was: 1045594)
Remaining Estimate: 0h
Time Spent: 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
> Time Spent: 10m
> 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 q (the documented tag-attribute
> pattern):
> <s:a href="%\{q}"> q=javascript:alert(document.cookie) -> <a
> href="javascript:alert(...)">
> <s:a value="%\{q}"> q=javascript:alert(document.cookie) -> <a
> href="javascript:alert(...)">
> <s:a anchor="%\{q}"> q=javascript:alert(document.cookie) -> lands as a
> URL fragment, inert (safe)
> Also confirmed vulnerable before a fix: case variation (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 naive startsWith("javascript:") filter would miss them), and a leading
> space or NUL.
> Proposed fix (patch available): a new allowlist-based check (http, https,
> mailto, tel), applied before
> the existing quote/<script 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)
