[whatwg] updateWithSanitizedHTML (was Re: innerStaticHTML)

[Adam Barth]

2009/12/1 Kornel Lesiński <kornel at geekhood.net>:
>>> 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.
>
> I think it is quite important for privacy. Otherwise "web bugs" can be
> placed and used to track every use of content in every mashup.
>
> Most often I'd like formatted text in applications to be just text,
> _completely_ passive.

I agree that it's a nice benefit of some designs, but, in my opinion,
it's not nearly as important as addressing the security issues.

More concretely, suppose you want to let folks include hyperlinks in
sanitized HTML, which I suspect many people will want to do.  You've
already lost the battle against web bugs because of DNS prefetch.

>>> "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)?
>
> On a second thought clickjacking is probably not the right term for what I
> have in mind, although it's a similar issue.
>
> The problem is that content added in DOM could use styles to overlay web
> application's "chrome" and steal data with forms or redirect standard
> links/buttons to phising site, e.g. <form action=evil style="position:fixed;
> top:0; right:0"> that's positioned on top of website's standard login form.
>
> Position:fixed escapes elements with "position:relative;overflow:hidden", so
> AFAIK this cannot be prevented without removal of all position:fixed styles
> from untrusted content.
>
> Such hack has been used on auction site allegro.pl, where auctions'
> descriptions are allowed to use CSS. In that particular case content should
> have been filtered server-side, but I imagine webmails, web-based feed
> readers and all kinds of mashups dynamically loading untrusted content could
> face similar problems, and having <iframe> for every bit of content is
> sometimes problematic.

I agree that this is a threat worth addressing.  That's one reason why
an API that blocks only script is insufficient for inline use cases.
Notice that my proposal does mitigate this threat.

Adam