- From: Adam Barth <whatwg@adambarth.com>
- Date: Tue, 1 Dec 2009 07:05:13 -0800
2009/12/1 Kornel Lesi?ski <kornel at geekhood.net>: >> The WebKit community is considering taking up such an experimental >> implementation. ?Here's my current proposal for how this might work: >> >> >> http://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTJzbTY1cWJrNA&hl=en >> >> I would appreciate any feedback on the design. > > Whitelist requires developers to know about potential risks of each > element/property, and that's not obvious to everyone: e.g. one might want to > allow object/embed (for harmless YouTube videos) without realizing that it > enables XSS. That's true. It would be interesting to know how often developers screw this up with Ruby-on-Rails' version of the API. > It's also non-obvious that style attribute is XSS risk (via behavior > property). Higher-level filtering option could allow style attribute, and > only filter out that property. Current proposal would need another whitelist > for CSS properties. Script-in-CSS is subtle enough that it's explicitly blocked (like javascript URLs). > And even whitelist for CSS properties couldn't be used to implement "No > external access" policy (allow images with data: urls, allow http: links, > but not http: images). This would be useful for webmails and other places > where website doesn't want to allow 3rd parties tracking views. I don't think an no external access policy is worth supporting explicitly. If it falls out of a general design, that's great, but I don't think the use case is compelling enough to accept the design constraints required to support it. > "No clickjacking" option might be useful as well. I don't have a clear idea how this would work. Did you have something different in mind than X-Frame-Options (already supported by WebKit)? Adam
Received on Tuesday, 1 December 2009 07:05:13 UTC