- From: Michal Zalewski <lcamtuf@coredump.cx>
- Date: Sun, 30 Jan 2011 12:54:08 -0800
- 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 UTC