Jesse, The proposal that I had to end up making with our IT department was for someone on the dev team to download the spec, vet it, and host it locally.
Pros: Avoids domain squatting attacks, avoids unanticipated version changes Cons: As Kevin mentioned on another thread, this could run into issues with regard to copyright, especially if the spec is changed by us, it also requires resources to vet the spec, and each version update (and really, how are you going to be informed of the version update?), lastly, gadgets are slow to be deployed, which runs counter to the entire concept of gadgets. While the application I'm working on doesn't have sensitive information, it does reside on a local network that does have sensitive info and shares the DB with them. So, they wanted a pretty restrictive process... Another alternative that I've thought about is to overload the concept of SecurityToken. Basically, have internal gadgets tag on additional parameters, and have privileged services check for the additional parameters in the SecurityToken Pros: You avoid all the cons of the above, and keep the pros Cons: Additional security development, but since I'm going to have to implement a Shibboleth based auth anyways, it may not be that much extra. Internal Gadgets will need to be invisible from the outside web, and that may pose a problem, John mentioned some cons as well as some potential attacks in his reply. Jeff -----Original Message----- From: Jesse Ciancetta [mailto:jcian2...@gmail.com] Sent: Wednesday, July 01, 2009 10:59 AM To: shindig-dev@incubator.apache.org Subject: Shindig Proxies Hi, I've got a Shindig deployment on my internal network that I'm using to render both internally and externally developed/hosted gadgets. I need to put some security measures in place to ensure that an external gadget can't do something like makeRequest an internal resource and then push it out to some external server. However, internal gadgets should still be allowed to access internal resources. It looks like there are three endpoints I need to be concerned with -- ProxyServlet, MakeRequestServlet and ConcatProxyServlet. I am thinking the easiest way for me to add this security is to write a Servlet filter to run in front of each of these services which will look at the http referrer, pull out the gadget spec URL, check to see if it's an internal or external gadget, and then decide whether or not to allow the request to proceed or just return an HTTP 403. Does that sound like a reasonable approach? I missing any other places where I might need to put these restrictions in place? Thanks! --Jesse
