Re: CSP XML Data with tokens

By the way, the JS snippet would obviously require that the user
content is htmlescaped :)

-- Eduardo




On Sun, Jan 30, 2011 at 1:07 PM, sird@rckc.at <sird@rckc.at> wrote:
>> 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:11:01 UTC