Wow, your quick (:
I'm a little bit confused, I'm trying to think of a security bridge that allows
gadgets to read and write to each other, but I can't think of any such way.
Suppose the following page is a user profile page on my social network that
resides on www.social-network.com
<html>
<head>
</head>
<body>
<iframe id="frmGadget_A"
src="http://gadget-server.social-network.com/GetGadget.php?Gadget=A";>
<!--
How can this gadget's code (the html and javascript returnd by the
gadget server)
can access the content of frmGadget_B ?
-->
</iframe>
<iframe id="frmGadget_B"
src="http://gadget-server.social-network.com/GetGadget.php?Gadget=B";>
</iframe>
</body>
</html>
How can the gadget's as you said can read and write to each other at will?
Cheers
Yaron
-----Original Message-----
From: Kevin Brown [mailto:[EMAIL PROTECTED]
Sent: ד 02 יולי 2008 20:07
To: [email protected]
Subject: Re: Caja
On Wed, Jul 2, 2008 at 12:01 PM, Yaron Avital <[EMAIL PROTECTED]>
wrote:
> Hi Kevin.
> 10x for your response.
> I'll be happy if you can elaborate on one of your sayings
>
> "To be truly secure, you need to use unique subdomains for every gadget,
> which means lots of DNS traffic."
>
> Why do I need unique sub domain for each gadget? I think two is enough
> For my understanding in order for iframes (gadgets) to accessing each
> other, first they need to get reference to the top document. But because the
> top document is in a different domain then they can't (the browsers
> prohibits it). So it's okay that all iframes have the same domain.
> Am I wrong?
Yes. If gadget A and gadget B both render on the same domain, they can read
(and write) to each other at will. At minimum, you want to make sure that
all gadgets currently being rendered for a given user are on a unique domain
(0-x.foogadgets.com should work). Even better is to use the locked-domain
feature and force a globally unique domain for every gadget that's rendered,
though that's something you need to consider very carefully.
>
>
> Cheers
>
> Yaron Avital
> DiffDoof.com
>
>
>
> -----Original Message-----
> From: Kevin Brown [mailto:[EMAIL PROTECTED]
> Sent: ד 02 יולי 2008 18:54
> To: [email protected]
> Cc: ☻Mike Samuel
> Subject: Re: Caja
>
> On Wed, Jul 2, 2008 at 8:40 AM, Yaron Avital <[EMAIL PROTECTED]>
> wrote:
>
> > Hi All,
> >
> >
> >
> > What are the benefits of using "Caja" in an open-social container?
> >
> > Obviously it's a code sanitizer that help removing "malicious" code that
> > was
> > written by someone I don't fully trust.
> >
> >
> >
> > But since "Open Social'' security architecture based on the browsers
> cross
> > domain protection, the malicious code does not have access to the
> container
> > and other applications (IFrame on domain www.my-Apps-Server.com can't
> > access the document that contains them on www.my-social-network.com)
> >
> >
> >
> > So, Why should I be worried about the stuff the applications developers
> > code
> > does? What attacks can it possibly performs? What am I missing?
>
>
> Using an iframe mostly works, but it also severely limits what you can do.
> Caja gives the container site full control at a highly granular level.
>
> A simple example of why iframe security isn't that great is found by
> looking
> at gadgets.rpc. If we had caja, we wouldn't need to do any of this stuff.
>
> iframes also have significant performance overhead. To be truly secure, you
> need to use unique subdomains for every gadget, which means lots of DNS
> traffic.
>
> Lastly, iframes aren't completely secure. They can't prevent modifying the
> iframe url to go to a malicious site, which opens the door for phishing.
> This is the main reason why we still see containers having to rely on white
> lists of "trusted" apps.
>
> Of coure, Caja isn't really ready for use in gadgets yet, so you don't have
> any choice but iframes.
>
>
> >
> > I would appreciate a well explained answer on this one
> >
> >
> >
> > Thanks
> >
> > Yaron Avital,
> >
> > DiffDoof.com
> >
> >
> >
> >
> >
> >
> >
> >
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 8.0.101 / Virus Database: 270.4.3/1529 - Release Date: 7/1/2008
> 7:23 PM
>
>
No virus found in this incoming message.
Checked by AVG.
Version: 8.0.101 / Virus Database: 270.4.3/1529 - Release Date: 7/1/2008 7:23 PM
