Gouri Sankar A created WW-5756:
----------------------------------
Summary: 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: 7.3.0, 6.11.0, 7.4.0
Reporter: Gouri Sankar A
<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}"> same payload -> <a
href="javascript:alert(...)">
<s:a anchor="%\{q}"> same payload -> 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)
