W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2011

[whatwg] Revising the content handling logic of <object> and <embed>

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 14 Jun 2011 02:07:24 +0000 (UTC)
Message-ID: <Pine.LNX.4.64.1106140050100.19153@ps20323.dreamhostps.com>
On Mon, 7 Mar 2011, Michal Zalewski wrote:
> 
> <object data="http://somewhere_funny/" type="application/x-shockwave-flash">
> <param name="allowScriptAccess" value="never">
> <param name="allowNetworking" value="never">
> <param name="allowFullScreen" value="never">
> </object>
> 
> Unfortunately, there is the "almost" part: in some originally 
> undocumented cases, browsers permit the attacker to override explicit 
> type= based on URL file extensions, content sniffing, or Content-Type. 
> This makes the aforementioned popular use case dangerous, because any 
> site that wishes to embed a security-restricted Flash movie may end up 
> embedding a Java applet instead, and Java has unconditional access to 
> the DOM of the embedding page via DOMService.

Yes. Do not embed content you do not trust. It's the same problem as 
embedding remote scripts with <script>.

 
> HTML5 spec makes an attempt to explicitly sanction the current behavior, 
> where neither the embedding nor the hosting party have control over how 
> the content will be displayed, in the specification for the <object> 
> element. Given the aforementioned situation, I think this is harmful and 
> needs to be revised.

Not much we can do to change it by default, it's required for Web 
compatibility.


> In my opinion, the preferred outcome would be to make type= 
> authoritative when specified, or provide an alternative way of ensuring 
> specific routing of the retrieved content on markup level. In addition, 
> to resolve existing problems with non-plugin content being interpreted 
> as plugin data (e.g. 
> http://xs-sniper.com/blog/2008/12/17/sun-fixes-gifars/), it would also 
> be prudent to provide servers a way to demand rendering only if 
> Content-Type provided by the server, and type= in the markup, match.

We can't allow the author to always control the type, because of the 
reverse problem: the embedding author might be an attacker who has managed 
to get a text file onto the remote (victim) server, which would, if 
interpreted as HTML, be an XSS attack.


On Mon, 7 Mar 2011, Boris Zbarsky wrote:
> 
> For what it's worth, I would be _very_ much in favor of having a way for 
> markup to specify "render this <object> only if the Content-Type matches 
> this type" (e.g. a boolean "forceStrictTypeMatch" attribute or 
> whatever).

I've added a "typemustmatch" attribute that does this. Feedback welcome.

Because using this attribute without testing will cause sites to break 
when it is implemented, I both encourage user agent vendors to implement 
it quickly, and urge everyone else to not speak of it loudly until 
browsers have shipped with support for this attribute.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 13 June 2011 19:07:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:06 UTC