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

Michal Zalewski lcamtuf at coredump.cx
Mon Mar 7 12:11:03 PST 2011

Hi folks,

The HTML4 spec said that on <object> and <embed> tags, Content-Type
overrides type=. All browser vendors implemented a different behavior,
however, where type= almost always overrides Content-Type.

Plugin vendors, in turn, missed that "almost" part, built extensive
security mechanisms, and promoted use cases where one site can embed
Flash movies, PDF documents, simple multimedia, and so on, from
another, untrusted source without suffering substantial security
consequences. For example, Flash exposes allowScriptAccess,
allowNetworking, and allowFullScreen parameters that can be used to
sandbox the loaded content:

<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">

People embraced this approach in web discussion forums, on online blogs, etc.

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.

While it can be argued that it's the websites and plugin vendors that
are doing it wrong, the issues with HTML4 spec and actual browser
behavior contributed to it, and it may be prudent to fix the mess.

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.

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.



More information about the whatwg mailing list