(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 (url2) http://myshindigserver.com/gadgets/ifr?url=http://www.example.com/gadget.xml&extrafile=http://www.mycontainer.com/mycontainer.js or it could (either manually or automatically) copy the gadgets.xml, insert <script src=http://www.mycontainer.com/mycontainer.js";> to the content section of the gadget, and rehost it on it's only url. Then it uses that new gadget url as the gadget xml url: (url3) http://myshindigserver.com/gadgets/ifr?url=http://www.myhost.com/gadget.xml >From a security point of view, there are only two differences between the first and the second method. Since the hostname of the shindig-server should be dependent on the gadget-xml-url, (url2) should not be allowed to render on the same hostname as (url1). The hostname should in this case be dependent on both the url and the extrafile parameter For the secure phone home feature, it's not enough to securely send back just the gadget url, but also the extrafile url.
