[whatwg] <object> behavior

[Ben Laurie]

On Sun, Oct 18, 2009 at 5:37 AM, Ian Hickson <ian at hixie.ch> wrote:
> 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.

Perhaps I am failing to understand, but if I embed anything from an
untrusted site, then it can choose what type it is - so how would I
prevent it running Flash?

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

I am worried about security, and I recommend using Caja - but Caja
still has to output valid HTML/CSS/JS...

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

You just said it could, above.

>
>
> 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.   `._.-(,_..'--(,_..'`-.;.'
>