- From: Ben Laurie <benl@google.com>
- Date: Sun, 18 Oct 2009 17:30:31 -0400
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