Without CDATA you have to encode script bodies properly. With CDATA you have to encode script bodies properly. What problem did CDATA solve?
On Sep 28, 2016 8:03 PM, "Alexander Jones" <[email protected]> wrote: > They do solve the problem. You encode your entire JS *before* pasting it, > encoding `]]>` and nothing more, and the XML document's text node contains > the unadulterated text, which the JS parser also sees. It's perfect layer > isolation. Ye olde HTML can't do that because there is no escaping > mechanism for `</script>` that actually allows the JS parser to see the > text (code) content unmodified. > > Viva la `<xhtml:revolución />` ;) > > On Wednesday, 28 September 2016, Mike Samuel <[email protected]> wrote: > >> I agree it's subideal which is why I work to address problems like this >> in template systems but ad-hoc string concatenation happens and embeddable >> sub-languages provide defense-in-depth without sacrificing correctness. >> >> CDATA sections solve no problems because they cannot contain any string >> that has "]]>" as a substring so you still have to s/\]\]>/]]>]]<!CDATA>/g. >> >> On Sep 28, 2016 2:32 PM, "Alexander Jones" <[email protected]> wrote: >> >>> 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. >>> >>> 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. >>> >>> Alex >>> >>> On Wednesday, 28 September 2016, Michał Wadas <[email protected]> >>> wrote: >>> >>>> Idea: require implementations to stringify "</script>" as >>>> "<\uxxxxscript>". >>>> >>>> Benefits: remove XSS vulnerability when injecting JSON as content of >>>> <script> tag (quite common antipattern). >>>> >>>> Backward compatible: yes, unless binary equality is required and this >>>> string is used. >>>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>>
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
