W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: <iframe doc="">

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 25 Jan 2010 02:16:54 -0800
Cc: "public-html@w3.org WG" <public-html@w3.org>
Message-id: <3BA0310E-EE0A-42E1-8040-E2AAABAD3FA3@apple.com>
To: Lars Gunther <gunther@keryx.se>

On Jan 25, 2010, at 2:03 AM, Lars Gunther wrote:

> 2010-01-24 18:14, Tab Atkins Jr. skrev:
>> Indeed, there are nearly as many html-sanitizers as there are CMSes.
>> And they're pretty uniformly bad.  Most of them are built on fragile
>> regexps, if you're lucky.  They might just be a handful of string
>> replaces that address whatever problems the CMS author could think of
>> at the time.  The best of them address *currently known attack
>> vectors* decently enough, but are usually weak to*new*  attacks.
> 
> There are white list approaches as well that one can use and indeed that are being used. I know of and have written a few myself.
> 
> Using XHTML syntax and XML tools makes this stuff easier to implement, in the absence of a "full HTML parser/tokenizer"!
> 
> I am unconvinced about the usefulness on MOVING security to the browser. First of all it can not be relied on, since we do not know for sure that all user agents implement it correctly. And it will take many years until 99 % of all agents support this and in the meantime we have to continue to do server side checks anyway.
> 
> This thing could work if seen as an extra layer of security. Defence in depth is always a good thing! But if it is marketed as something you'll do INSTEAD of servers side checks, it will actually be harmful to security on the web.

The goal for sandboxed <iframe> is to promote and deploy it for defense in depth.  It is not intended to be used as the sole security mechanism, since it will take years until browsers that do not support it are gone.

> Besides, you will probably want to stop a lot of other things as well, like target="_blank" and <div style="display: none">Lots of links I use for black hat SEO here</div> even if it is inside an iframe, sandboxed or not.

Sandboxed iframes will help you with targeted links. Check out the "sandboxed navigation browsing context flag" here: <http://dev.w3.org/html5/spec/Overview.html#attr-iframe-sandbox>. It will not help you strip out "display: none" content, but search engines will be able to make their own judgment based on the fact that it is sandboxed.

> Summary: If this technology is about "offloading" security to the browser, it will be harmful to web security! If it is about adding an extra layer, and will be marketed only as such, it is OK.

My understanding is that the purposes is solely defense in depth, at least until it is widely enough deployed that it can be relied on. Even then, it's probably best to combine it with a whitelist filter. Certainly the security experts I've talked to would promote its use as an additional mechanism, and if anyone asked me for advice on deploying sandboxed iframes, I would tell them the same.

(To clarify relation to the thread topic, this doesn't necessarily depend on doc/srcdoc, just on sandboxed iframes in general. As far as I'm aware, srcdoc is just there to make sandboxed iframes easier to use, it is not required to get the security benefits.) 

Regards,
Maciej
Received on Monday, 25 January 2010 10:17:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:00 GMT