Re: CSP XML Data with tokens

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?

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.

-- G


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 09:24:57 UTC