[whatwg] <object> behavior

[Ian Hickson]

On Fri, 16 Oct 2009, Ben Laurie wrote:
> > On Thu, 6 Aug 2009, Andrew Oakley wrote:
> >>
> >> - Should the type attribute take precedence over the Content-Type 
> >> header?
> >
> > No, I believe what the spec says here is the preferred behaviour. 
> > Unless this is incompatible with legacy content, we should try to move 
> > towards this behaviour.
> 
> I realise this is only one of dozens of ways that HTML is unfriendly to 
> security, but, well, this seems like a bad idea - if the page thinks it 
> is embedding, say, some flash, it seems like a pretty bad idea to allow 
> the (possibly untrusted) site providing the "flash" to run whatever it 
> wants in its place.

If the site is untrusted, yet you are letting it run flash, then you've 
lost already. Flash can inject arbitrary JS into your page.

If you are worried about security, I recommend using <iframe>. The new 
sandbox="" feature will help even more, once implemented.


On Fri, 16 Oct 2009, Boris Zbarsky wrote:
>
> This cuts both ways.  If a site allows me to upload images and I upload 
> an HTML file with some script in it and tell it it's a GIF (e.g. via the 
> name) an then put an <object type="text/html" 
> data="http://this.other.site/my.gif"> on my site...  then I just 
> injected script into a different domain if we let @type override the 
> server-provided header.
> 
> This is, imo, a much bigger problem than that of people embedding 
> content from an untrusted site and getting content X instead of content 
> Y, especially because content X can't actually access the page that 
> contains it, right?

Indeed.


On Fri, 16 Oct 2009, Ben Laurie wrote:
> 
> The point is that if I think I'm sourcing something safe but it can be 
> overridden by the MIME type, then I have a problem.

If you know it's Flash, use <embed>. If you know it's an image, use <img>. 
If you know it's HTML, use <iframe>. That way you can't get caught like 
this.


On Fri, 16 Oct 2009, Boris Zbarsky wrote:
> 
> Perhaps we need an attribute on <object> that says to only render the 
> data if the server provided type and @type match?  That way you can 
> address your use case by setting that attribute and we don't enable 
> attacks on random servers by allowing @type to override the 
> server-provided type?

Just use one of the more appropriate elements. That way it's safe in older 
UAs also.


On Sat, 17 Oct 2009, Michael A. Puls II wrote:
> On Fri, 16 Oct 2009 05:28:46 -0400, Ian Hickson <ian at hixie.ch> wrote:
> > On Sun, 20 Sep 2009, Michael A. Puls II wrote:
> > > 
> > > O.K., so put simply, HTML5 should explicitly mention that the css 
> > > display property for <object>, <embed> (and <applet> in the handling 
> > > section) has absolutely no effect on plug-in instantiation and 
> > > destroying and has absolutely no effect on @src and @data resource 
> > > fetching.
> > > 
> > > HTML5 could also be extra clear by example that display: none 
> > > doesn't destroy, or prevent the creation of, the plug-in instance 
> > > and that changing the display value doesn't destroy the instance.
> > > 
> > > Lastly, HTML5 could briefly mention that what the plug-in does when 
> > > its window/area is not displayed because of display: none, is 
> > > plug-in and plug-in API dependent.
> > 
> > I've added a note to this effect.
>
> I see the note in the object element section, but don't see it in the 
> embed element section and the applet element section.

Fixed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'