- From: Ben Laurie <benl@google.com>
- Date: Sun, 18 Oct 2009 08:21:56 -0400
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. ? `._.-(,_..'--(,_..'`-.;.' >
Received on Sunday, 18 October 2009 05:21:56 UTC