Re: [whatwg] behavior
On Sun, Oct 18, 2009 at 3:47 PM, Ian Hickson wrote: > On Sun, 18 Oct 2009, Ben Laurie wrote: >> On Sun, Oct 18, 2009 at 5:37 AM, Ian Hickson 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 . So what's the difference between and ? > 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 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 . 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 > >> 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] behavior
On Sun, Oct 18, 2009 at 5:37 AM, Ian Hickson 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 . 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 > 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 . If you know it's an image, use . > If you know it's HTML, use . That way you can't get caught like > this. > > > On Fri, 16 Oct 2009, Boris Zbarsky wrote: >> >> Perhaps we need an attribute on 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 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 , (and 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] behavior
On Fri, Oct 16, 2009 at 9:55 PM, Boris Zbarsky 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 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] behavior
On Fri, Oct 16, 2009 at 6:04 PM, Mike Shaver wrote: > On Fri, Oct 16, 2009 at 5:56 PM, Ben Laurie wrote: >> On Fri, Oct 16, 2009 at 5:48 PM, Boris Zbarsky 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 >
Re: [whatwg] behavior
On Fri, Oct 16, 2009 at 5:48 PM, Boris Zbarsky 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 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] behavior
On Thu, Aug 13, 2009 at 10:05 PM, Ian Hickson wrote: > On Thu, 6 Aug 2009, Andrew Oakley wrote: >> >> The rules in the HTML5 spec for which plugin to load for an do >> not seem to be followed by any browser, and in some cases are different >> to behavior that is common to Opera, Webkit and Gecko (I haven't tested >> with IE due to its lack of nsplugin support). >> >> Most notably HTML5 says that the Content-Type header is used in >> preference to the type attribute, whereas the browsers seem to honour >> the attribute in preference to the header. (If the spec is changed to >> match the browsers behaviour then the conditions on when to load a new >> plugin also need to be changed.) HTML5 also seems to prefer the type >> attribute on
