[whatwg] <object> behavior

[Ben Laurie]

On Sun, Oct 18, 2009 at 3:47 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Sun, 18 Oct 2009, Ben Laurie wrote:
>> 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?
>
> You can't exclude one type and allow others,

Sure, and that's fine.

> but if you want a very
> specific type used for a plugin, you can use <embed>.

So what's the difference between <embed> and <object>?

> If you just want to
> allow the untrusted site to do anything, but in their own security context
> so it can't harm your site, use <iframe>.

iframe is insufficient to prevent untrusted content from doing harm.
It also makes it painful to communicate with the untrusted content.

>
>
>> > 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...
>
> I don't understand the problem.
>
>
>> > 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.
>
> The example Boris mentioned was HTML. Embedded HTML is always
> origin-blocked. The example I mentioned earlier was Flash. Flash runs in
> the context of the embedder page.
>
> HTH,
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'