Re: CSP XML Data with tokens

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:38:28 UTC