Re: CSP XML Data with tokens

> 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).
We already have that (<plaintext>), you can intercept the last
plaintext tag in the document, and apply it's contents inside a
seamless sandboxed iframe, and you get the same advantages..

Anyways, there's not need to argue about this.. you can actually
create a javascript snippet of code that automatically transforms all
occurrences of:

<sandbox start="$nonce">
$user_content
<sandbox end="$nonce">

into

<iframe sandbox seamless srcdoc="$usercontent">

Greetings!!
-- Eduardo




On Sun, Jan 30, 2011 at 12:47 PM, Giorgio Maone
<g.maone@informaction.com> wrote:
>> <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 19:08:00 UTC