[
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 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.
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}" 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.
> 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 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)
