[
https://issues.apache.org/jira/browse/SLING-8879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989011#comment-16989011
]
Ilguiz Latypov edited comment on SLING-8879 at 12/5/19 5:40 PM:
----------------------------------------------------------------
I see SLING-6679 replaced JSONObject with Johnzon in year 2017 which has a
simple serializer that does not reuse the "for javascript" encoder. On the
other hand, Johnzon would not protect against the closing script tag injection
or the open comment tag injection in cases where the javascript string literal
is embedded with the HTML response.
I see Johnzon substitutes the double quotes, as required by JSON and by the
need to protect against the attack where malicious payload drops out of the
javascript string literal context in a Javascript embedded in HTML. Of course.
It would be nice if Johnzon replaced the open angle bracket {{raw <}} with
an ASCII presentation of the respective Unicode, {{raw \u003C}}, which is
also compatible with both JSON and Javascript.
https://github.com/apache/johnzon/blob/master/johnzon-core/src/main/java/org/apache/johnzon/core/Strings.java#L64
XSSAPI encodeForJSString() could reuse Johnzon's above serialization. (I guess
this would require accessing Johnzon via Sling's service provider interface to
an abstract JSON implementation).
Our older AEM code still uses the older JSONObject, but I guess there would not
be a security (built-in XSS protection against abuse of javascript code with
string literals embedded in HTML) or stability (strict javascript engine
failing to parse the backslash-forwardslash encoding I observed in
JSONObject#toString) update to that version of Sling.
was (Author: ilatypov):
I see SLING-6679 replaced JSONObject with Johnzon in year 2017 which has a
simple serializer that does not reuse the "for javascript" encoder. On the
other hand, Johnzon would not protect against the closing script tag injection
or the open comment tag injection in cases where the javascript string literal
is embedded with the HTML response.
I see Johnzon substitutes the double quotes, as required by JSON and by the
need to protect against the attack by dropping out of the javascript string
literal context in a Javascript embedded in HTML. Of course.
It would be nice if Johnzon replaced the open angle bracket {{raw <}} with
an ASCII presentation of the respective Unicode, {{raw \u003C}}, which is
also compatible with both JSON and Javascript.
https://github.com/apache/johnzon/blob/master/johnzon-core/src/main/java/org/apache/johnzon/core/Strings.java#L64
XSSAPI encodeForJSString() could reuse Johnzon's above serialization. (I guess
this would require accessing Johnzon via Sling's service provider interface to
an abstract JSON implementation).
Our older AEM code still uses the older JSONObject, but I guess there would not
be a security (built-in XSS protection against abuse of javascript code with
string literals embedded in HTML) or stability (string javascript engine
failing to parse the backslash-forwardslash encoding I observed in
JSONObject#toString) update to that version of Sling.
> Make JSONObject#toString and XSSAPI#encodeForJSString both safe and correct
> for pasting into a javascript string literal
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: SLING-8879
> URL: https://issues.apache.org/jira/browse/SLING-8879
> Project: Sling
> Issue Type: Bug
> Components: XSS Protection API
> Reporter: Ilguiz Latypov
> Priority: Minor
>
> The current implementation risks exceptions in strict javascript engines.
> |return source == null ? null :
> Encode.forJavaScript(source).replace("\\-", "\\u002D");|
> Substitutes on top of the encoder's result with the intent to correct the
> encoder are near-sighted (i.e. suffer from the context-free approach). If
> {{source}} had a backslash followed by a dash, i.e. {{raw \-}}, the
> {{forJavaScript}} call would properly change the backslash into 2 backslashes
> {{raw \\-}} (this would result in the javascript engine
> turning the string literal back to {{raw \-}}). But the subsequent
> {{replace}} call will destroy the context of the second backslash, turning
> the string into {{raw \\u002D}} which would turn to {{raw
> \u002D}} in the javascript engine's variable.
> I argue for dropping the {{.replace()}} call (aiming at disabling malicious
> comment injection) here and encoding the opening angle bracket {{raw <}} as
> {{raw \u003C}} in the {{Encode.forJavaScript}} implementation. This will
> protect against both the malicious comment injection and the injection of
> closing script tags {{raw <\script>}} forcing the javascript
> interpreter to drop out of the string literal context and drop out of the
> script context.
> The existing prefixing of forward slashes with a backslash agrees with JSON
> but not with Javascript. It should be removed in favour of replacing just the
> opening angle bracket.
> {noformat}
> SingleEscapeCharacter :: one of
> ' " \ b f n r t v
> {noformat}
> [https://www.ecma-international.org/ecma-262/6.0/#sec-literals-string-literals]
> [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String#Escape_notation]
> I noticed that JSONObject#toString suffers from the same idea of a
> non-universal protection of the forward slash. I guess both XSSAPI and
> JSONObject#toString reuse the same code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
