W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2009

[whatwg] <object> behavior

From: Ben Laurie <benl@google.com>
Date: Sun, 18 Oct 2009 17:30:31 -0400
Message-ID: <1b587cab0910181430y31af46b6k6864162310bc45d2@mail.gmail.com>
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. ? `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 18 October 2009 14:30:31 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:18 UTC