>Right, but from reading the shindig code, you might come to other >conclusions. Is there anyone involved with the locked domain code that is >still on this list?
I didn't write any of the Shindig locked-domain code, but I have worked with it for our internal Shindig 2.x based deployment and will be working with it again with Shindig 3.x for our Rave deployment. More comments inline below. >From: Christiaan Hees <[email protected]> >To: [email protected], >Date: 09/21/2011 04:53 AM >Subject: Re: Locked domains and spoof protection in shindig > > > >When you have a page with 2 gadgets on it and those gadgets both have >the same domain, those gadgets can affect eachother. One gadget could >insert code or change the look of the other for example. >So it's important to render each gadget on a seperate subdomain when >you allow 3rd party gadgets. > > >On Wed, Sep 21, 2011 at 12:32 AM, Dan Dumont <[email protected]> >wrote: >> I'm trying to understand a bit more about the locked domain feature >> implementation in shindig, if someone familiar with the process could >take >> some time to answer these questions, I'd appreciate it. >> >> Most of the checking seems to happen around 2 classes, an enum defined >in >> UriStatus and the implementation of DefaultIframeUriManager. >> validateRenderingUri. What I'm not finding is anything keying off of >the >> status to ensure that statuses of INVALID_DOMAINare not allowed to >render. >> Seems like the status request is mostly used for caching based on >> versioning or lack of versioning. When I search for references for >> INVALID_DOMAINthe only thing that really uses it to prevent activity is >> ProxyUriBase.translateStatusRefresh and that happens much later after >the >> render. >> >> So here are my questions: >> >> What are we really trying to protect against with locked domains? I think the what is as Christiaan pointed out -- preventing gadget code in gadget A from accessing/manipulating gadget B or the parent container page. There are also cookies to keep in mind here as well -- like SSO cookies that might be set for *.yourdomain.com -- you wouldn't want untrusted gadgets running on some.yourdomain.com and snatching up your SSO session tokens. >> Is there a concern in allowing a gadget to render on the domain of >another >> locked-domain gadget? (the check is there in shindig right now but I >can't >> find anything that's enforcing the status that's returned for render >> calls) >> Is the render an important thing to protect, or is it mostly for >requests >> through the proxy? I think it's important to protect both cases. If we don't ensure that a render request has arrived on the right locked domain for the gadget being rendered then there is nothing stopping gadget A from immediately changing its location onload to the locked domain of gadget B -- and at that point gadget A can do whatever it wants with gadget B. I think it's also important to protect the various proxy mechanisms because I believe (have heard mentioned, but I haven't thought through the implications myself) that if you can get a resource loaded (like a JS file) from another gadgets domain then you could also potentially start to access the other gadgets contents. Shindig 2.x protects against both cases -- if I try to render or hit one of the proxies on the wrong locked domain I immediately get back an HTTP 400 with "Invalid domain" in the response. If this is no longer the case with Shindig 3.x then it sounds like a bug that we need to resolve. I haven't done any locked domain work with Shindig 3.x yet but will be soon(ish) -- if this isn't resolved by the time I get to it I'd be happy to look into it further.
