sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ilguiz Latypov (Jira)" <>
Subject [jira] [Commented] (SLING-8879) Make JSONObject#toString and XSSAPI#encodeForJSString both safe and correct for pasting into a javascript string literal
Date Thu, 05 Dec 2019 17:55:00 GMT


Ilguiz Latypov commented on SLING-8879:

I also see a suggestion to fool-proof more characters serialized as JSON strings in case these
strings are embedded into a javascript embedded in HTML.

This suggests to encode 
* the opening angle bracket {{raw &#x3C;}} against closing the script tag or opening a
comment tag, 
* the closing angle bracket {{raw &#x3E;}} against closing a possible CDATA wrapper around
the javascript text embedded in XHTML (and HTML?),
* {{U+2028}} and {{U+2029}} allowed in JSON but not in Javascript against disrupting the javascript
* the ampersand {{raw &#x26;}} without a specific concern.

> Make JSONObject#toString and XSSAPI#encodeForJSString both safe and correct for pasting
into a javascript string literal
> ------------------------------------------------------------------------------------------------------------------------
>                 Key: SLING-8879
>                 URL:
>             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("&#x5C;&#x5C;-",
> 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 &#x5C;&#x2D;}}, the {{forJavaScript}} call would properly change
the backslash into 2 backslashes {{raw &#x5C;&#x5C;&#x2D;}} (this would result
in the javascript engine turning the string literal back to {{raw &#x5C;&#x2D;}}).
But the subsequent {{replace}} call will destroy the context of the second backslash, turning
the string into {{raw &#x5C;&#x5C;u002D}} which would turn to {{raw &#x5C;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 &#x5C;u003C}} in the
{{Encode.forJavaScript}} implementation. This will protect against both the malicious comment
injection and the injection of closing script tags {{raw &#x3C;&#x5C;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}
> []
> []
> 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

View raw message