Re: CSP XML Data with tokens

> <span sandboxstart="{$nonce}" />
> <div class="untrusted-content-output-as-it-is">...</div>
> <span sandboxend="{$nonce} />
>
> Ugliness (and possibly parser complexity) aside, what's wrong with this?
> It doesn't work in HTML.  HTML doesn't support self-closing tags.
Of course, the self-closing thing is just a detail to mask further ugliness in 
XML serialization.

<span sandboxstart="{$nonce}"></span>
<div class="untrusted-content-output-as-it-is">...</div>
<span sandboxend="{$nonce}></span>


Are there more serious objections  (ugliness aside)?
--  G

Adam Barth wrote, On 30/01/2011 19.37:
> On Sun, Jan 30, 2011 at 1:20 AM, Giorgio Maone<g.maone@informaction.com>  wrote:
>> Stupid question of mine, maybe, especially if I missed something in the
>> thread.
>>
>>> I think there is a substantial advantage of being able to output small
>>> chunks of untrusted data as-is - note that this is the problem this
>>> sub-thread started with - and simply mark the relevant section of the
>>> page as restricted in some way (no HTML parsing at all, no scripting,
>>> no external subresources, etc).
>>> That said, this is sort of moot, because through the years, nobody
>>> could propose a broadly acceptable way to do this without
>>> substantially changing HTML / XML.
>> What about using self-closing siblings, rather than the parent, as
>> delimiters?
>> This way you could include the nonce in the end delimiter without having to
>> introduce an attribute in a closing tag, like
>>
>> <span sandboxstart="{$nonce}" />
>> <div class="untrusted-content-output-as-it-is">...</div>
>> <span sandboxend="{$nonce} />
>>
>> Ugliness (and possibly parser complexity) aside, what's wrong with this?
> It doesn't work in HTML.  HTML doesn't support self-closing tags.
>
> Adam
>
>
>> Of course I'm very well aware that a problem probably bigger than syntax is
>> implementing restrictions in the middle of a document, rather than at the
>> document-container level, that is likely the true reason why a sort of an
>> agreement could be found on iframes only.
>>
>> Michal Zalewski wrote, On 30/01/2011 6.43:
>>>> Anyways, I digress.. the conclusion, from my point of view is that we
>>>> don't need XML data tokens if we have sandboxed iframes with srcdoc.
>>> I think there is a substantial advantage of being able to output small
>>> chunks of untrusted data as-is - note that this is the problem this
>>> sub-thread started with - and simply mark the relevant section of the
>>> page as restricted in some way (no HTML parsing at all, no scripting,
>>> no external subresources, etc).
>>>
>>> I sort of suspect that making this possible would be the single most
>>> effective way to put a dent in XSS; certainly more convenient than any
>>> restrictive, page-wide script policies.
>>>
>>> I think that sandboxed frames do not solve this problem, because:
>>>
>>> 1) Their performance / memory usage impact will probably render them
>>> largely impractical to put several dozen or hundred of them on a
>>> single page - and this is how many bits of untrusted text you may have
>>> on a page of a typical discussion forum or a mail client. Sandboxed
>>> frames solve the problem of untrusted gadgets, third-party documents,
>>> and some other cases like this, but not that of your typical
>>> discussion forum or so.
>>>
>>> [ Because of this, I am actually wondering if the combination of
>>> sandbox + seamless is going to be that useful. ]
>>>
>>> 2) For simple text-only output, the need to apply a specific transform
>>> to the payload (and do it well) is arguably comparable with the
>>> difficulty of avoiding XSS in the same scenario.
>>>
>>> That said, this is sort of moot, because through the years, nobody
>>> could propose a broadly acceptable way to do this without
>>> substantially changing HTML / XML.
>>>
>>> /mz
>>>
>>

Received on Sunday, 30 January 2011 18:52:00 UTC