Re: [Content Security Policy] Proposal to move the debate forward

> You've lost me there. Why could it not be made compatible with XML?
> All you need is a start and end it doesn't matter the format, once a start
> and end is defined the parser would start looking for the tokens first and
> any invalid injections inside could be removed or prevented from overlapping
> with other markers.

Ugh, we're hijacking Adam's thread again. I suggest changing subject
if we want to continue this discussion. What people discussed before
is something along the lines of:

<span security=XXXX>
   user_content_which_should_behave_like_cdata_and_not_have_html_tags_interpreted_so_that_xss_here_is_not_possible
</span security=XXXX>

...or:

<start_untrusted_section security=XXXX />
user_content_which_should_behave_like_cdata_and_not_have_html_tags_interpreted_so_that_xss_here_is_not_possible
<end_untrusted_section security=XXXX />

...both of these approaches require changes to XML parsers to add a
new CDATA-like mode to make it impossible to escape this block - which
seems like a big deal.

Perhaps a more compatible approach would be:

<securityXXXX> // With secret token in tag name
 user_content_here
</securityXXXX>

...but it's also unlikely to fly with purists.

Maybe there are other, more compatible ways to contain arbitrary user
input in a document, or at least a subset of such content, though.

/mz

Received on Thursday, 27 January 2011 22:57:03 UTC