W3C home > Mailing lists > Public > public-web-security@w3.org > January 2011

Re: CSP XML Data with tokens

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Sun, 30 Jan 2011 12:54:08 -0800
Message-ID: <AANLkTinfzScU2Eiszq3ddoN13Y=Q8R8MevMgkD6ZgAmL@mail.gmail.com>
To: Aryeh Gregor <Simetrical+w3c@gmail.com>
Cc: Adam Barth <w3c@adambarth.com>, "public-web-security@w3.org" <public-web-security@w3.org>
>> 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.
>
> Is this conceivably avoidable if you want to allow full HTML markup in
> the untrusted snippets?

I'm not a browser developer, but I suspect that there are certain
types of restrictions you can easily impose without having to have a
completely separate DOM / JS context. And some you can't.

>> 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.
>
> If it's text-only, simple HTML escaping is the way to do it.  It's
> error-prone, but I don't see any clear advantage to other methods.

The whole discussion here started with a discussion over a variety of
"simple XSS" prevention mechanisms (and I'm not entirely sure why we
drifted toward sandboxed frames, which I think aren't a very good
fit). The implicit assumption here - backed with empirical data, by
the way - is that people can't get "simple" HTML escaping right
(especially since it gets progressively less simple in cases such as
JS in inline on* handlers).

/mz
Received on Sunday, 30 January 2011 20:55:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 30 January 2011 20:55:03 GMT