W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2009

[whatwg] updateWithSanitizedHTML (was Re: innerStaticHTML)

From: Adam Barth <whatwg@adambarth.com>
Date: Tue, 1 Dec 2009 07:05:13 -0800
Message-ID: <7789133a0912010705h5895b205p7fc1e8c4c44ab01c@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:54 UTC