[
https://issues.apache.org/jira/browse/WW-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gouri Sankar A updated WW-5756:
-------------------------------
Description:
<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}" with q=javascript:alert(document.cookie) renders
href="javascript:alert(...)"
s:a value="%{q}" with q=javascript:alert(document.cookie) renders
href="javascript:alert(...)"
s:a anchor="%{q}" with q=javascript:alert(document.cookie) renders as a
URL fragment, inert, safe
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.
was:
<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.
> 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}" with q=javascript:alert(document.cookie) renders
> href="javascript:alert(...)"
> s:a value="%{q}" with q=javascript:alert(document.cookie) renders
> href="javascript:alert(...)"
> s:a anchor="%{q}" with q=javascript:alert(document.cookie) renders as a
> URL fragment, inert, safe
> 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)
