This is a personal blog. My other stuff: book | home page | Twitter | prepping | CNC robotics | electronics

March 06, 2011

Warning: OBJECT and EMBED are inherently unsafe

Let's say that you maintain an online discussion forum. Assuming that you explicitly specify the type= parameter in your <object> or <embed> markup, what are the security consequences of allowing users to embed third-party Flash movies in their posts when you enforce the appropriate security restrictions on your end (allowScriptAccess, allowNetworking, allowFullScreen all set to none)? Or, to make things simpler, how about permitting a straightforward video file, with type=video/x-ms-wmv?

If you think this is safe, you may want to know that the HTML5 spec has a different view. The specification effectively takes away the ability for any single party to decide how a particular plugin document should be handled by the browser. Under the new algorithm, instead of your funny cat video, you may accidentally end up embedding Java, which has unconditional access to the DOM of the embedding page through DOMService. Whoops, looks like you are owned now.

According to the spec, if your visitor's browser has, say, a Windows Media Player plugin that recognizes the type=video/x-ms-wmv value on your webpage, that plugin will be used regardless of Content-Type. This part is intuitive. Alas, if the plugin is not found, the specification compels the software to look at Content-Type next, giving the hosting party an opportunity to override the intent specified on your end.

To further complicate the picture, in some circumstances, browsers may also ignore both type= and Content-Type values: for example, Internet Explorer and WebKit browsers will play Flash videos served with Content-Type: pants/whatever and loaded with type=certainly/not-flash just because a stray .swf file extension is spotted somewhere in the URL. The file name signal is problematic, as it can usually be tampered with by whoever provides the URL. This strategy brings a yet another player into the picture, and each party can sabotage the security assurances sought by the rest.

It would be more reasonable to keep the behavior of <object> and <embed> consistent with that of other type-specific subresource tags (e.g., <applet>, <img>, or <script>), and give control over how the document is rendered to whoever authored the markup. This approach is still not without peril, because it makes it impossible for some sites to indicate that a particular text/plain or image/jpeg response is not meant to be interpreted as a malicious applet. But that last problem can be fixed by requiring Content-Type and type= to match, perhaps through an opt-in mechanism controlled with a new HTTP header. And in any case, the proposed logic does not help.

In the end, the currently specified behavior seems highly counterintuitive, and undoes all the work plugin that vendors such as Adobe or Microsoft put into adding security controls to ensure that their plugin content is reasonably safe to embed across domains that do not fully trust each other.

Test cases here. Joshua Stein also reports that they confuse Flash-blocking tools.


  1. Whose bug is it? Where do we work to get it fixed?

  2. It's hard to tell. There is a disconnect between the (somewhat sucky) behavior of ignoring Content-Type on subresources, and the implied role of type= in that setting; and the current and proposed handling of OBJECT or EMBED.

    Fixing it requires first agreeing on what is the right approach. There are three sane options, it would seem:

    1) Give the control fully to the embedding party, which is how people understand type=. This has benefits for the embedding party, and poses some risk to the hosting party (vide GIFAR -

    2) Give the control fully to the hosting party, and get rid of type=. This rules out certain types of content embedding, and also means that many of the security mechanisms in Flash, Silverlight, etc, are unnecessary.

    3) Require the two values to match, requiring both parties to agree. This is the safest option, but it will probably break stuff.

    If an agreement can be reached, it's probably a matter of specifying it as a part of a standard, and then waiting 5+ years for all browsers to catch up.

  3. This is really bad, a lot of sites are affected.

    The only mitigation factor here is that usually people have flash installed.. Anyway, gov agencies sometimes forbid their employees to have flash because of "security", I just hope they also disallow java, acrobat reader, etc..

  4. Yes, I suspect that the set of people who browse with Java but no Flash is pretty small - Flash has a 99% market share reportedly.

    It's a bit more problematic with other multimedia types. WMP, PDF, QuickTime, etc, are closer to 60%. But such embeds are not nearly as common as Flash.