Re: [whatwg] object behavior

2009-10-18 Thread Ben Laurie 
On Sun, Oct 18, 2009 at 5:37 AM, Ian Hickson i...@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 i...@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.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] object behavior

2009-10-18 Thread Ben Laurie 
On Sun, Oct 18, 2009 at 3:47 PM, Ian Hickson i...@hixie.ch wrote:
 On Sun, 18 Oct 2009, Ben Laurie wrote:
 On Sun, Oct 18, 2009 at 5:37 AM, Ian Hickson i...@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.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] object behavior

2009-10-17 Thread Ben Laurie 
On Fri, Oct 16, 2009 at 9:55 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 10/16/09 8:21 PM, 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.

 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?

That would work.

Re: [whatwg] object behavior

2009-10-16 Thread Ben Laurie 
On Fri, Oct 16, 2009 at 5:48 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 10/16/09 4:12 PM, Ben Laurie wrote:

 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.

 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?

Flash can, for example.


 -Boris

Re: [whatwg] object behavior

2009-10-16 Thread Ben Laurie 
On Fri, Oct 16, 2009 at 6:04 PM, Mike Shaver mike.sha...@gmail.com wrote:
 On Fri, Oct 16, 2009 at 5:56 PM, Ben Laurie b...@google.com wrote:
 On Fri, Oct 16, 2009 at 5:48 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 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?

 Flash can, for example.

 If Flash can do bad things, then sourcing Flash from an untrusted site
 and getting malicious Flash with the expected MIME type doesn't seem
 like it's any better than getting malicious Quicktime or Java or
 whatever via a switched MIME type.  Is there something I'm missing?

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.


 Mike