On Feb 3, 2008 10:03 AM, Reinoud Elhorst <[EMAIL PROTECTED]> wrote: > (Pehaps the reply is a bit off topic, since it might not actually solve > the > issue discussed here) > > On 2/1/08, Kevin Brown <[EMAIL PROTECTED]> wrote: > > > > [...] > > > > You can *never* inject an arbitrary file into an iframe either. It's > like > > standardizing a XSS attack (especially problematic for type=url > support). > > > > I have to admit that I don't have a good enough idea on how type=url > should > work, still I don't agree with your statement that we shouldn't inject > arbitrary js. > > Say we have the gadget: http://www.example.com/gadget.xml. The > iframe src here is (skipped some urlencoding for the sake of > readability) (url1) > > http://myshindigserver.com/gadgets/ifr?url=http://www.example.com/gadget.xml > . > > Now the container wants to add the file > http://www.mycontainer.com/mycontainer.js > to the gadget. It could do this in two ways >
There are certainly more than two ways to do this. The easiest approach (which is also secure) is probably to just do a variation of what iGoogle does today (this method has been vetted for several years and has proven itself effective, so I don't see much value in reinventing it). 1. When generating an iframe, a parameter is passed that contains an identifier (url prefix is fine) for the container. Something like: http://example.org/gadgets/ifr?url=http://example2.org/foo.xml#container=example.org 2. The iframe has a whitelist of supported containers with mappings for various configuration data (location of ifpc relay file, supported views, etc.) something like: var containers = {"example.org": {"views":{"default":false, "canvas":true}, "ifpc_relay":"http://example.org/ifpc_relay"}, " myfacebo5.com": {...}}; If the container parameter is in the query string, you simply have this config server side and only emit the configuration appropriate to the container you're working with. 3. For open social, one of the container data members could be the location of the open social javascript on the parent container, or alternatively an endpoint url for their back end that will get proxied through via gadgets.io.makeRequest (the latter approach is more difficult because it requires a semi standard rpc mechanism to be implemented by the supported containers. This doesn't give a solution for "open" sites (allow any container to use it without pre-registering with the host), but I'm not really convinced that this is important. gmodules.com, for example, could support this model by having this data be configured through a container registration service. If a gadgets server deployment really wants to allow any arbitrary site to be able to inject javascript (thereby bypassing any whitelisting, locked domain, or other security considerations), they're free to do so, but I don't think we should promote this bad security practice in shindig itself. You could possibly trust an arbitrary ifpc relay url, since it only ever winds up in an iframe anyway (although type=url gadgets still wouldn't work with this model; you'd have to "proxy" the ifpc relay calls to the gadget server domain, or possibly have the gadgets themselves whitelist trusted sites). You'd then have to shuttle all of the data over ifpc (or a theoretical "better ifpc" that would be implemented in gadgets.rpc). This is pretty limiting and slow, though it would be a potentially viable solution for sites that want to allow this.
