- From: Paul Libbrecht <paul@hoplahup.net>
- Date: Tue, 4 Jan 2011 09:06:25 +0100
- To: robert@ocallahan.org
- Cc: "Hallvord R. M. Steen" <hallvord@opera.com>, public-webapps@w3.org
Oh boy... indeed it's a crab's nest! I think it's rather a good idea to whitelist and blacklist and get it richer as the browser makers' awareness grows into a catalog of tags, attributes, and properties that need to be sanitized out or may be kept. I'd rather suggest to start smallishly so that the feature itself is kept (and not "disabled for security reasons by upgrade beta+0.003"; I believe this is what happened to MSIE's Clipboard APIs) and let it grow as the catalog grows. paul On 4 janv. 2011, at 03:01, Robert O'Callahan wrote: > I specifically avoided the issue of whether to whitelist or blacklist :-). > > Whitelisting is preferably for security, but it turns that the obvious whitelists break things. For example, some HTML editors expect to be able to get pasted HTML from Microsoft Word containing -mso styles, which they will then process into something else. So a CSS whitelist would need to include at least some -mso stuff, and who knows what else On 4 janv. 2011, at 06:51, Robert O'Callahan wrote: > Probably not. One problem is that if some implementation supports CSS-triggered scripts via some CSS extension, then ideally other implementations would ensure that those extensions are stripped. E.g. Opera doesn't support IE's expression() CSS extension, but if an Opera user pastes untrusted HTML into a Web site, IE users may become vulnerable. > Maybe your spec should just mention that something needs to be done here and move on. This is a rather tough issue and it wouldn't be fair to make you responsible for solving it :-).
Received on Tuesday, 4 January 2011 08:07:48 UTC