<div dir="ltr">Hi Michał<div><br></div><div>Embedding a JSON literal into HTML involves first encoding to JSON then encoding that into HTML. Two stages which must not be confused. The 'encoding into HTML' part is best done in XHTML with CDATA, and the encoding method is taken care of by whichever XML-generating library you're using. If you hint it to use CDATA for such a text node, or if for any other reason it chooses to use CDATA, rather than merely converting every `<` to `&lt;`, etc., then it will (or should) "escape" `]]>` as `]]]]><![CDATA[>` or whatever equivalent. See <a href="https://en.wikipedia.org/wiki/CDATA#Nesting">https://en.wikipedia.org/wiki/CDATA#Nesting</a> for more info. Crucially, this works for encoding ANY text data into a text node in an XML document, not just JSON.<div><br></div><div>Having the specified JSON algorithm in ECMAScript deal with concerns of embedding into legacy, non XML-based HTML (oh yes, I totally went there! ;) ) is a classic layer violation, which I would guarantee offends 99 out of 100 experienced programmers' sensibilities. :)</div><div><br></div><div>Aside, I'll repeat again that this would be largely ineffective - a lot of JSON that might be dumbly pasted into a text stream of HTML would be generated by implementations other than that specified by ECMAScript.</div><div><br></div><div>Hope this clears it up</div></div><div><br></div><div>Alex</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 28 September 2016 at 19:41, Michał Wadas <span dir="ltr"><<a href="mailto:michalwadas@gmail.com" target="_blank">michalwadas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Actually CDATA suffer the same issue - for string "]]>". Mike Samuel has a very strong point here. </p>
<p dir="ltr">And by saying "it's antipattern, don't do this" we will not make old vulnerable code go away. And we have a very good way to stop people from shooting their own feet - for free. </p><div class="HOEnZb"><div class="h5">
<div class="gmail_extra"><br><div class="gmail_quote">On 28 Sep 2016 8:31 p.m., "Alexander Jones" <<a href="mailto:alex@weej.com" target="_blank">alex@weej.com</a>> wrote:<br type="attribution"><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That's awful. As you say, it's an antipattern, no further effort should be spent on this. JSON produced by JavaScript has far more general uses than slapping directly into a script tag unencoded, so no-one else should have to see this. Also, there are many other producers of JSON than JavaScript.<div><br></div><div>Instead, use XHTML and CDATA (which has a straightforward encoding mechanism that doesn't ruin the parseability of the code or affect it in any way) if you really want to pull stunts like this.</div><div><br></div><div>Alex<div><span></span><br><div><br>On Wednesday, 28 September 2016, Michał Wadas <<a href="mailto:michalwadas@gmail.com" target="_blank">michalwadas@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Idea: require implementations to stringify "</script>" as "<\uxxxxscript>". </p>
<p dir="ltr">Benefits: remove XSS vulnerability when injecting JSON as content of <script> tag (quite common antipattern). </p>
<p dir="ltr">Backward compatible: yes, unless binary equality is required and this string is used. </p>
</blockquote></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>