W3C home > Mailing lists > Public > public-web-security@w3.org > January 2011

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

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Thu, 27 Jan 2011 14:56:10 -0800
Message-ID: <AANLkTi=Sp6r8zjxzCW5i284rO-c7PTBuK8cUCFJ3MkUr@mail.gmail.com>
To: gaz Heyes <gazheyes@gmail.com>
Cc: Devdatta Akhawe <dev.akhawe@gmail.com>, Brandon Sterne <bsterne@mozilla.com>, public-web-security@w3.org
> 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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 27 January 2011 22:57:05 GMT